仕様書

認可符号

[2] 認可符号authorization codeは、資源所有者による認可を鯖からクライアントに知らせ、 クライアントが鯖からアクセストークンを得るための符号です。

[18] 認可符号は、クライアント識別子およびリダイレクトURLに束縛されています >>15。

認可エンドポイントで発行される時に指定されていた値を保存する必要があります。 トークンエンドポイントでアクセストークンを発行する際にクライアントが指定した値と照合することになります。

[21] 認可符号は、 code 引数の構文上の制約より、 1つ以上の印字可能ASCII文字の文字列である必要があります。

[22] 認可符号の長さは OAuth 仕様としては定義されていません。 クライアントは長さに仮定を置くべきではありません。 認可鯖は発行する認可符号の長さを明文化するべきです。 >>15

[31] 認可鯖は、認可符号を推測できないものとしなければなりません >>32。 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです >>32。

[16] 認可符号は、漏洩の危険を減らすため、発行して間もなく満期としなければなりません >>15, >>26。 寿命は最大でも10分とするべきです >>15。

[27] 認可符号の転送は、保安通信路で行うべきです >>26, >>30。 クライアントは、ネットワークの資源を識別するリダイレクトURL を用いる場合は、 TLS の利用を求めるべきです >>26。 クライアントが資源所有者を認証するために認可符号に依存するのであれば、 TLS の利用を求めなければなりません >>26。

[41] べきにとどまっているのは OAuth 2.0 制定当時の世間がそのような状況だったためと思われます。 現在ではそうしなければならないと解釈するべきです。 現在の基準では、 TLS を使用しない通信が認められるべき状況はおよそ考えられません。[28] 認可符号はリダイレクトによって授受されますから、 利用者エージェントの履歴や Referrer のヘッダーを通して漏れる可能性があります >>26。

[17] クライアントは認可符号を複数回使ってはなりません。 認可鯖は複数回使われたら要求を拒絶しなければならず >>15, >>26、 その認可符号により以前に発行されたすべてのトークンを (できれば) 取り消し (revoke) するべきです >>15, >>26。

[29] 認可鯖はクライアント認証が可能であれば、 認可符号が同じクライアントに発行されたものか確認しなければなりません >>26。

[38] 異なるクライアントの認可符号を使える場合、攻撃対象のクライアントがいわゆるOAuthログインを実装している場合において、攻撃者の有するクライアントに攻撃対象の資源所有者を誘導して認可符号を取得し、その認可符号を攻撃対象のクライアントに与えることで、攻撃者が攻撃対象クライアントにおける攻撃対象資源所有者になりすましてログインできてしまいます >>37。

[39] これを防ぐためにOAuthログインを使うクライアントはクライアント型を機密にし、トークンエンドポイントアクセス時にクライアント認証を行う必要があります。 トークンエンドポイント

[36] 攻撃者が認可鯖に認可符号を発行させる操作を大量に実行して認可符号を枯渇させるようなDoS攻撃があり得ますから、 利用者ごとに発行数を制限するなど、対策を講じるべきです >>35。

認可符号承諾フロー

[3] 認可符号承諾フローでは、クライアントは、 資源所有者に直接認可を求めるのではなく、 まず認可鯖の認可エンドポイントへと資源所有者をリダイレクトします >>1, >>12。クライアントはこの時クライアント識別子 (client_id)、 適用範囲 (scope)、 局所状態 (state)、リダイレクトURL (redirect_uri) を指定します >>12。

[4] 認可鯖の認可エンドポイントは、 資源所有者を認証し、 クライアントによるアクセスの認可を資源所有者から得てから、 資源所有者をクライアントのリダイレクトエンドポイントへと認可符号や局所状態 (state) を添えてリダイレクトして戻します。 >>1, >>12

[5] クライアントのリダイレクトエンドポイントは、 指定された認可符号を使って (code) 認可鯖のトークンエンドポイントに要求することで、 アクセストークンを得ることができます。この時クライアントは >>3 のリダイレクトに使った URL を指定し (redirect_uri)、 認可鯖はそれが認可符号を発行した URL と一致しているか確認します。 認可鯖はアクセストークンと共に更新トークンを発行することもできます。 >>12

R
資源所有者
C
クライアント
S
認可鯖
R -> C
OAuth 処理開始の要求
C -> R
認可エンドポイントへのリダイレクト
R -> S
認可エンドポイントへの要求 (response_type=code)
S -> R
クライアントによるアクセスを認可するか確認
R -> S
クライアントによるアクセスの認可
S -> R
リダイレクトエンドポイントへのリダイレクト (認可符号つき)
R -> C
リダイレクトエンドポイントへの要求
C -> S
トークンエンドポイントへの要求
S -> C
アクセストークンの発行
C -> R
OAuth 処理完了の応答

[13] 本承諾型はリダイレクトを用いますから、必然的にクライアントは資源所有者の利用者エージェント (通常は Webブラウザー) と対話できることと共に、リダイレクトによって認可鯖からやってくる要求を受信することができる必要があります >>12。

[6] OAuth 2.0 仕様書は、“認可鯖をクライアントと資源所有者の間の中間器intermediaryとして使う” >>1 と表現しています。 (HTTP における中間器 (≒ 串) とは意味が異なります。)[7] 本承諾型では資源所有者は認可鯖に対してのみ認証しますから、 資源所有者の credentials をクライアントが知る必要はありません >>1。

[8] 本承諾型では (認可符号からのアクセストークン取得時に) 認可鯖がクライアントを認証することができます >>1 (client_id 参照)。 本承諾型はクライアント型が機密の場合に最適化されています >>12。

[9] 本承諾型では資源所有者や第三者に晒さず直接クライアントにアクセストークンを渡すことができます >>1。 Webブラウザー上で動作するスクリプトや Webブラウザーの脆弱性、 中間者攻撃、悪意ある資源所有者などによる漏洩を防ぐことができます。[14] 本承諾型は OAuth 1.0 に最も近い形をとっていますが、 OAuth 1.0 の一時credentials要求に相当するものが不要になっています。

response_type=code

[11] OAuth 2.0 認可エンドポイントの response_type 引数の値 code は、 認可符号を求めていることを表します >>10。

grant_type=authorization_code

[24] 認可鯖のトークンエンドポイントの grant_type 引数の値 authorization_code >>23 は、 認可符号からアクセストークンを得ることをクライアントが求めていることを表します。

code 引数

[19] クライアントのリダイレクトエンドポイントの code 引数は、認可鯖が発行した認可符号を表します。

[34] この引数の値は、1文字以上の印字可能ASCII文字の列です >>33。

[20] 認可鯖が認可符号承諾フローでリダイレクトエンドポイントにリダイレクトする時は、 リダイレクトURLに code 引数を追加しなければなりません >>15。

[25] 認可鯖のトークンエンドポイントの code 引数には、リダイレクトエンドポイントの code 引数によって受信した認可符号を指定しなければなりません >>23。

メモ

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