トークンエンドポイントへの要求

[36] クライアントがトークンエンドポイントの位置を知る方法は OAuth の仕様の範囲外とされていますが、普通はサービスのドキュメントで示されます >>34。

[38] トークンエンドポイントは TLS を使わなければなりません >>34, >>89。 アクセストークン、更新トークンを転送する場合は HTTPS鯖認証を使わなければなりません >>89。 クライアントは RFC 6125 により認可鯖のTLS証明書を検証し鯖の identity を認証しなければなりません >>89。

[37] トークンエンドポイントの URL は application/x-www-form-urlencoded 形式の query を含んでも構いません。素片識別子を含んではなりません。 query が含まれる場合、引数を追加するときにはそのまま残さなければなりません。 >>34

[199] feedly は Content-Type: application/json を指定することで JSON payload body によって引数を指定することを認めています >>197。

[48] クライアントは、認可符号からアクセストークンを得るためにトークンエンドポイントに要求を送信する場合、 application/x-www-form-urlencoded payload body により次の引数を指定します >>52。

[120] Azure は resource 引数を追加しています >>119。

[150] Salesforce は code_verifier, format を追加しています >>149。

[50] クライアントは、資源所有者の credentials からアクセストークンを得るため (資源所有者合言葉credentialsフロー) にトークンエンドポイントに要求を送信する場合、 application/x-www-form-urlencoded payload body により次の引数を指定します >>61。

[66] クライアントは、クライアントcredentials からアクセストークンを得るため (クライアントcredentialsフロー) にトークンエンドポイントに要求を送信する場合、 application/x-www-form-urlencoded payload body により次の引数を指定します >>65。

[125] Azure は resource 引数を追加しています >>124。

[146] reddit は場合によって grant_type=https://oauth.reddit.com/grants/installed_client を使います。また device_id 引数を追加しています。 >>145

[2] クライアントは、更新トークン からアクセストークンを得るためにトークンエンドポイントに要求を送信する場合、 application/x-www-form-urlencoded payload body により次の引数を指定します >>1。

[122] Azure は resource 引数を追加しています >>119。

[158] Salesfoce は format 引数を追加しています >>157。

[203] assertion を使う場合は、 grant_type 引数を assertion の種別を表す絶対URL、 assertion 引数を assertion の値とします。 scope 引数も指定できます。 >>202

[69] クライアントは、拡張の承諾型の規定に従いトークンエンドポイントに要求を送信する場合、 grant_type 引数に絶対URLを指定し、 必要に応じて追加の引数も指定します >>68。

[41] 要求の引数は、複数指定してはなりません >>34。

[160] SurveyMonkey は payload body ではなく URL query に api_key 引数を指定することを求めています >>159。

[189] GitLab は要求の payload body の JSON によって引数を指定させています >>188。

[39] クライアントはトークンエンドポイントへの要求で POST 要求メソッドを使わなければなりません >>34。

[162] Facebook >>164 や fouresquare >>161 は GET を使っているようです。

クライアント認証

[22] クライアントは、トークンエンドポイントや revokeエンドポイントへの要求で、 client_id 引数を指定できます。また、 場合によっては認証に必要な情報を指定しなければなりません。

[23] 認可サーバーは、トークンエンドポイントやrevokeエンドポイントで、 場合によってはクライアント認証を行わなければなりません。

[24] 詳細は、OAuth 2.0クライアント認証を参照。

トークンエンドポイントの処理

[83] 認可鯖は、認識できない引数を無視しなければなりません >>34。

[40] 要求の引数に値が含まれなければ、指定されなかったものと扱わなければなりません >>34。

[54] 認可鯖は、認可符号からアクセストークンの発行を求められている場合、 認可符号が妥当なものであることを確認しなければなりません >>52。 認可符号は1回しか使えません。

[100] 攻撃者は大量の要求でクライアントに適当な認可符号を与え、認可鯖にアクセスさせることで、 間接的に認可鯖のHTTP接続を枯渇させる DoS攻撃を試みるかもしれません。 認可鯖には攻撃者の情報がほとんど届かず、対策が難しい攻撃です。 認可鯖は不適切な認可符号があまりに多いクライアントには誤り応答を返すべきかもしれません >>99。

[53] 認可鯖は、認可符号からアクセストークンの発行を求められている場合、

• [32] クライアント型が機密のクライアントに対するものであるか、
• [33] クライアント型が公開のクライアントに対するもので認可符号の発行先と client_id が合致しているか、

のいずれかを満たすことを確認しなくてはなりません >>52, >>89。

[102] 攻撃対象のクライアントがいわゆるOAuthログインを実装している場合において、攻撃者の有するクライアントに攻撃対象の資源所有者を誘導して認可符号を取得し、その認可符号を攻撃対象のクライアントに与えることで、攻撃者が攻撃対象クライアントにおける攻撃対象資源所有者になりすましてログインできてしまいます >>101。 公開のクライアントに関してこれを防ぐことはできません。

[54] 認可鯖は、認可符号からアクセストークンの発行を求められている場合、 認可エンドポイントへのアクセス時に redirect_uri 引数が指定されていたなら本要求にも redirect_uri 引数が含まれており、両者の値が一致することを確認しなければなりません >>52, >>89。

[62] 認可鯖は、資源所有者の credentials からアクセストークンの発行を求められている場合、 指定された credentials を検証しなければなりません >>52。

[3] 認可鯖は、更新トークンからアクセストークンの発行を求められている場合、 指定された更新トークンを検証しなければなりません >>1。 クライアント認証可能であれば、正しいクライアントか検証しなければなりません >>89。

[63] 認可鯖は、回数制限や警告などにより、資源所有者合言葉credentials の総当たり攻撃からエンドポイントを保護しなければなりません >>52。

[95] 認可鯖は CSRF 対策が必要です。資源所有者の credentials を第三者に漏らしてしまう形の攻撃は難しそうですが、認可鯖 (や間接的にクライアント) に対する DoS攻撃や、 CSRF を引き起こされた被害者たる Webブラウザーの利用者への嫌がらせには使えるかもしれません。

トークンエンドポイントの応答

[56] 認可鯖は、アクセストークンの発行を求められている場合、 要求が妥当であり認可されたなら、アクセストークンを発行します >>55, >>64, >>67, >>68, >>1。

[4] 認可符号や資源所有者合言葉credentials、拡張の承諾型では、 更新トークンも発行することもできます >>55, >>64, >>68。 ただしクライアント認証していない場合には発行するべきではないかもしれません >>89。

[5] クライアントcredentialsでは、 更新トークンを発行するべきではありません >>67。

[6] 更新トークンからアクセストークンを求めている場合には、 新しい更新トークンを発行しても構いません。その適用範囲 (scope) は元の更新トークンと同じでなければなりません。 その場合には認可鯖は古い更新トークンを取り消し (revoke) して構いませんし、クライアントは古い更新トークンを破棄しなければなりません。 >>1

[72] その場合には、 200 応答で次の引数を JSON (application/json) payload body の JSONオブジェクトの名前と値 (文字列なら JSON文字列、 数値なら JSON数値) に含めます >>71。

[106] アクセストークン型によっては、更に追加の引数を指定する必要があるかもしれません。

[117] grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1 では、 refresh_token (更新トークン) のみが返されることになっていました。

[121] Azure は resource 引数と expires_on 引数を追加しています >>119。

[134] ヤマレコは token_type 引数を指定せず、 成功時でも error 引数と error_message 引数 (独自) を指定するようです >>133。

[148] Instagram は token_type 引数を指定せず、 user 引数 (独自) を指定するようです >>147。

[173] Bitly は apiKey 引数 (独自) を指定するようです。 ただし非推奨で削除予定とあります。 >>172 2015-03-05T16:02:49.500Z

[179] Heroku は user_id、session_nonce を指定するようです >>178。

[182] Yahoo! は xoauth_yahoo_guid を指定するようです >>181。

[198] feedly は plan を指定するようです >>197。

[143] foursquare など >>161, >>163, >>142, >>172 は token_type 引数を指定しないようです。

[194] Facebook は token_type 引数を指定しません。 expires_in ではなく expires 引数に time_t 値を指定するようです。

[152] Salesforce は token_type 引数を指定しないようです。 独自の id, instance_url, issued_at, signature を指定するようです。 >>149, >>156, >>157

[151] Salesforce は要求で format 引数を指定した場合に応答が他のMIME型になるようです >>149, >>157。

[167] GitHub は要求で Accept: を指定した場合に応答が他の MIME型になるようです。既定値は application/x-www-form-urlencoded になっているようです。 >>166

[193] Facebook は応答に application/x-www-form-urlencoded を使うようです。ただし Content-Type: はなぜか text/plain; charset=UTF-8 になります。 2015-03-10T15:02:45.900Z

[30] その後 JSON に修正 (非互換変更) されています >>29。

[42] 応答の引数は、複数指定してはなりません >>34。

[79] 更に、 Cache-Control: no-store と Pragma: no-cache を含めなければなりません >>71。

[80] クライアントは、認識できない名前の引数を無視しなければなりません >>71。

[56] 認可鯖は、アクセストークンの発行を求められている場合、 クライアント認証に失敗したか要求が非妥当であったなら、 誤り応答を返します >>55, >>64, >>67, >>68, >>1。

[88] その場合には、 400 応答で次の引数を JSON (application/json) payload body の JSONオブジェクトの名前と値 (文字列なら JSON文字列、 数値なら JSON数値) に含めます >>87。

[127] Azure は timestamp、trace_id、 correlation_id、error_codes を追加しています >>128。

[51] error が invalid_client の場合には、 401 応答とすることもできます。 クライアントが Authorization: ヘッダーで認証を試みた場合には、 401 応答と WWW-Authenticate: ヘッダー (auth-scheme は要求で指定されたもの) を使って応答しなければなりません >>87。