一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
OAuthSwift ではてなの OAuth を使うときに二重URLエンコードされないようにする正しい方法は?
OAuthSwift を使ってはてなの OAuth 認証を使おうとしています。OAuth の仕様に詳しい方に、この変更が正しいのか伺いたく思います。 サンプルプロジェクト (GitHub) を作って試したところ、最後のアクセストークンを取得するところで 401 で oauth_problem=token_rejected が返ってきてしまうエラーに悩まされていましたが、 OAuthSwift のソースを追いかけてみると、 OauthSwifthClient.swift の makeRequest() の中で最後の request.headers で oauth_token=\"hogehoge%253D%253D\" となっており、oauth_verifier も同様に %253D が含まれていました。 本来は hogehoge%3D%3D という文字列が post されなければならないの
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
Covert Redirect Vulnerability with OAuth 2
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
OAuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も
OpenSSLの脆弱性「Heartbleed」に続き、人気のオープンソースセキュリティソフトウェアでまた1つ大きな脆弱性が見つかった。今回、脆弱性が見つかったのはログインツールの「OAuth」と「OpenID」で、これらのツールは多数のウェブサイトと、Google、Facebook、Microsoft、LinkedInといったテクノロジ大手に使われている。 シンガポールにあるNanyang Technological University（南洋理工大学）で学ぶ博士課程の学生Wang Jing氏は、「Covert Redirect」という深刻な脆弱性によって、影響を受けるサイトのドメイン上でログイン用ポップアップ画面を偽装できることを発見した。Covert Redirectは、既知のエクスプロイトパラメータに基づいている。 たとえば、悪意あるフィッシングリンクをクリックすると、Faceboo
Googleがログイン認証を強化、OAuth 2.0の採用促す
米Googleは4月23日、2014年下半期以降にユーザーがWebブラウザやデバイス、アプリケーションからGoogleにログインする際のセキュリティチェックを段階的に強化すると発表した。 Googleではユーザーレベルで2段階認証などのセキュリティ強化策を提供するとともに、開発者向けには「Google Sign-In」などのツールを提供し、Google APIで認証プロトコルの「OAuth 2.0」をサポートしている。 今回のセキュリティチェックの強化は、本来のユーザーしかアカウントにログインできないことを確実にするのが目的。ユーザー名とパスワードをGoogleに送信しているアプリケーションでは、認証にOAuth 2.0を採用するよう開発者に促した。 Googleは、「OAuth 2.0を使わなければ、ユーザーがそのアプリケーションにアクセスするために、追加の手順を要求されるようになる」と
What Are Refresh Tokens and How to Use Them Securely
This post will explore the concept of refresh tokens as defined by OAuth 2.0. We will learn how they compare to other token types and how they let us balance security, usability, and privacy. You can follow the text in this post, or if you prefer learning from presentations, you can watch this article’s companion video: What Is A Token?Tokens are pieces of data that carry just enough information t
OAuth for Platform API in Public Beta
In May, we launched the beta Heroku Platform API - making it possible to automate, extend and combine the Heroku platform with other services in a programmatic, self-service way. As of today, OAuth 2.0 support for the Platform API is available in public beta. With OAuth support, developers building integrations and services that use the Heroku API can provide a much better experience to their user
(メモ) Rails+OmniAuthによるTwitterログイン - m-kawato@hatena_diary
Ruby/Rails向けの認証連携フレームワークの定番らしいOmniAuthを使って、OAuth経由でTwitterに投稿するサンプルRailsアプリを作ってみました。 参考にしたサイト: http://ja.asciicasts.com/episodes/241-simple-omniauth arunagw/omniauth-twitter - GitHub 「簡単なOmniAuth」に詳細な使い方が説明されていますが、現在のOmniAuth 1.1と合っていない箇所があるので、適宜公式ドキュメントを参照しています。 動作環境: Ubuntu 12.10 Desktop (32ビット版) on VMware Player Ruby 1.9.3-p362 Rails 3.2.10 omniauth 1.1.1 omniauth-twitter 0.0.14 twitter 4.4.2 (
OAuth2.0のclient_secretって本当に秘密鍵ですか？ - ブログなんだよもん
OAuthをしているサービスをAndroid + PhoneGap経由で使いたくて調べて見ました。 そして、色々調べたり考えたりした結果、 client_secret ってそもそも秘密鍵にする必要なくね？ という天啓を得たので、つらつらと書いてみます。secretって名前なのに秘密である必要がないなんて、わけがわからないよ。 間違ってる気がしてならないので、誰か指摘をしてください。マジで。 とりあえず、前提として自分のサービスの認証替わりに使いたいわけじゃなくて、純粋にそのサービスを使うのが目的。OAuthなサービスはサーバサイドで使ったことは何度かあるんだけど、クライアントサイドで使うという事で、扱いが困るのがclient_secret。名前の通り、秘密鍵として扱う必要があると思ってたんだけど、正直安全にクライアント側で管理する方法が無い。 公開している通常のソースからは外してビルド時に
GTMOAuthでTwitterなどのOAuthを行う方法 - Awaresoft
facebookやTwitter、GoogleDataAPIなど、APIを公開しているサービスを利用するときに、OAuthを使うことが多くなってきました。OAuthをきちんと理解して使うのは結構たいへんな印象ですが、ライブラリを使うと手軽に利用できてしまいます。 ライブラリにもいろいろありますが、私が試した中では、かなりきちんとOAuthを理解していないと使うのが難しいようなライブラリもあるなかで、Google Toolbox for Mac - OAuth Controllers (GTMOAuth)は使い方が非常に簡単で、ほんの数行のコードを追加するだけで、自分のアプリケーションでOAuth認証が必要なサービスを利用することができます。 ただ、いくつか注意しなければならないことがあったので、使い方をメモしておきます。 ０．利用したいサービスにアプリケーション登録 あらかじめ、利用したい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
API with only HTTP scheme into callback URL