暗示的

暗示的承諾型 (OAuth)

仕様書

承諾フロー

[2] 暗示的承諾 (implicit grant) は、 JavaScript などのスクリプト言語ブラウザー上で実装されたクライアントのような、 クライアント型公開であり特定のリダイレクトURL を使うとわかっているクライアントに最適化された、 単純化されたフローです >>1, >>8

[11] クライアントは、まず資源所有者 (の利用者エージェント) を認可エンドポイントリダイレクトします。 この時クライアントは、クライアント識別子 (client_id)、 適用範囲 (scope)、 局所状態 (state)、 リダイレクトURL (redirect_uri) を指定します。 >>8

[12] 認可エンドポイント資源所有者認証し、 クライアントのアクセス要求を承認するか拒絶するかを確認します >>8。 承認するなら、アクセストークン素片識別子に添えてリダイレクトURL へとクライアントリダイレクトします >>8

[13] 資源所有者利用者エージェントリダイレクトに従いクライアント資源要求しますが、 この時 HTTP要求には素片識別子は含まれません。 クライアントWebページ (通常はスクリプトが埋め込まれた HTML文書) を返します。 Webページスクリプト素片識別子からアクセストークンその他の引数を取り出し、 クライアントへと渡します。 >>8

[3] リダイレクトURLで示されていた資源自体はアクセストークンその他を受け取りません。 素片識別子に含まれるアクセストークンを処理する JavaScript アプリケーションを提供するだけです。
R
資源所有者
C
クライアント
S
認可鯖
R -> C
OAuth の処理の開始指示
C -> R
認可エンドポイントへの要求にリダイレクト
R -> S
認可エンドポイントへの要求 (return_type=token)
S -> R
アクセス要求の承認の確認
R -> S
アクセス要求の承認
S -> R
リダイレクトURLへのリダイレクト (アクセストークン付き)
R -> C
リダイレクトURLへの要求 (アクセストークンなし)
C -> R
リダイレクトURLからの応答
#R#
アクセストークンの取得
R -> C
アクセストークンの送信
[4] このように、クライアントは (認可符号を経ずに) アクセストークンを直接得ることができます >>1, >>8認可符号のような中間の credentials を使わないので、 暗示的 (implicit) 承諾型と呼ばれています >>1
[10] リダイレクトを使っているので、 クライアント資源所有者利用者エージェント (通常は Webブラウザー) と対話できるもので、リダイレクトにより認可鯖から要求を受信できるものである必要があります >>8

[5] 認可鯖クライアント認証を行いません >>1, >>8 (クライアントから認可鯖への直接のアクセスが無いので、その機会もありません)。 資源所有者が存在していることと、リダイレクトURL が登録されていることに依拠しています >>8

[6] アクセストークンリダイレクトURLに指定されることとなるため、 資源所有者や、資源所有者と同じ装置にある他の応用に晒されるかもしれません >>1, >>8

[7] 暗示的承諾を使うと認証符号を使う場合のようなアクセストークンを得るまでの往復を節減でき、 効率的ではありますが、便利さのために若干のセキュリティーを犠牲にしています >>1

[9] 暗示的承諾型では、更新トークンは発行されません >>8

セキュリティー

[18] 暗示的承諾型を用いている場合、 (悪意のある、または悪意のある者に誘導された) 資源所有者は他のクライアントから取得したアクセストークン認可鯖からの応答であるかのように見せかけてクライアントに渡すことができてしまいます。 つまり、クライアントを利用する本来の資源所有者と、クライアントアクセストークンによって資源鯖に対して要求を行う操作上の資源所有者が異なる状態を作れてしまいます。

[19] クライアント上の本来の資源所有者のデータが (クライアントの正規の動作により) 資源鯖に送信されるとアクセストークン資源所有者はそのデータを盗むことができてしまいます。

[20] また暗示的承諾型フローの後に資源鯖から資源所有者アカウント電子メールアドレス等を取得して自サービス上のアカウントとする、いわゆるOAuthログインを使うクライアントがあると、他のクライアントにおいて取得したアクセストークンを使ってそのクライアントにも「ログイン」できてしまいます >>22

[21] 認可符号フローでは、認可符号を盗んで他のクライアントに注入したとしても、トークンエンドポイントアクセス時にクライアント認証が行われればこのような攻撃は防げます (クライアント認証が行われなければ防げません)。 OAuth 1.0 でも同様です。

[25] Google は「TokenInfo validation」と称して、素片識別子から得たアクセストークンGoogleに送信してその情報を取得し、 適切なクライアントアクセストークンであるか確認することを求めています >>24

[23] Final: OpenID Connect Core 1.0 incorporating errata set 1 ( 版) <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>