authorization_code

認可符号 (OAuth)

仕様書

認可符号

[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

[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]承諾型では資源所有者や第三者に晒さず直接クライアントアクセストークンを渡すことができます >>1Webブラウザー上で動作するスクリプト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] 認可鯖認可符号承諾フローリダイレクトエンドポイントリダイレクトする時は、 リダイレクトURLcode 引数を追加しなければなりません >>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