grant

Edit New

承諾 (OAuth)

[7] 認可承諾 (authorization grant) フローは、 OAuth 2.0 においてクライアントが資源所有者にかわって資源にアクセスするためのアクセストークンを認可鯖から得るための手続きです。 その方法として OAuth 2.0 では4種類の承諾型 (grant type) と更新トークンからの取得の計5通りのフローが用意されています。 grant_type 引数は、クライアントが用いたい承諾型を指定するものです。

仕様書

認可承諾

[2] 認可承諾 (authorization grant) は、 資源所有者の (被保護資源へのアクセスの) 認可を表すcredentialsで、 クライアントがアクセストークンを得るために使うフローです >>1。

[3] OAuth 2.0 は4種類の承諾型 (grant type) を定義すると共に、 拡張も認めています >>1。

[39] OAuth 2.0 本体の4つの承諾型

[8] 承諾型の一種ではありませんが (とはいえ grant_type の値が割り当てられてはいますが)、 既にいずれかの承諾型フローにより取得した更新トークンを使って新たにアクセストークンを取得するフロー (grant_type=refresh_token) もあります。

[27] OpenID による OAuth 2.0 の拡張 >>28 では、暗示的承諾の派生形 id_token や、認可符号と暗示的承諾の中間形 (Hybrid Flow) を幾通りか規定しています。また「reponse_type=none」なる形も規定しています。 これらは response_type 引数により区別されます。

[29] Google は装置向けの grant_type=http://oauth.net/grant_type/device/1.0 フローや OAuth 1.0 から OAuth 2.0 への移行のための urn:ietf:params:oauth:grant-type:migration:oauth1 を規定しています。

[31] reddit はクライアントcredentials承諾型と実質的に同じながら、 「ログアウト状態」や client_secret を持たない公開のクライアントが使うべき grant_type=https://oauth.reddit.com/grants/installed_client を定義しています。

[38] SoundCloud は更新トークンのかわりに OAuth 1.0 アクセストークンを指定する grant_type=oauth1_token を実装しているようです。

grant_type 引数

[6] 承諾型は、トークンエンドポイントの grant_type 引数で指定することになります。

[11] トークンエンドポイントを使わない暗示的承諾型を除きます。

[10] 値としては、次のものがあります。

[40] grant_type の値

[17] その他、クライアントは認可鯖が定義する絶対URLによって拡張の承諾型を指定することができます >>5, >>15。 grant_type 引数で独自の値を指定する他、 追加の引数も必要に応じて指定します。 >>5

[22] OAuth 2.0 の他の部分と違って、なぜか承諾型の拡張は絶対URL に限定されていて、 URL でない短い値の登録は認められていないようです。 IANA登録簿も用意されていません。 (IETF の他の仕様書で規定される値も URL になっていて、無駄に長くなっています。)

[25] 構文としては、1文字以上のASCII英数字、-、.、 _ の列か、 RFC 3986 URI参照のいずれかとされています >>24。

[26] URI参照には相対URLも含まれるので、 >>10 および >>17 よりも構文上はかなり広い範囲の値が認められることとなります。この違いが意図的なものなのかどうかは不明です。

文脈

[18] 認可鯖のトークンエンドポイントに対する認可符号からアクセストークンを取得する要求では、 grant_type 引数の値は authorization_code としなければなりません >>12。

[19] 認可鯖のトークンエンドポイントに対する資源所有者合言葉credentialsからアクセストークンを取得する要求では、 grant_type 引数の値は password としなければなりません >>13。

[20] 認可鯖のトークンエンドポイントに対するクライアントcredentialsからアクセストークンを取得する要求では、 grant_type 引数の値は client_credentials としなければなりません >>14。

[21] 認可鯖のトークンエンドポイントに対する更新トークンからアクセストークンを取得する要求では、 grant_type 引数の値は refresh_token としなければなりません >>16。

歴史

[30] OAuth 1.0 には承諾型に相当するものはありませんでしたが、 標準機能として oauth_callback=oob、 Google 独自機能として 2-legged OAuth、 Twitter 独自機能として xAuth がありました。

関連

[23] response_type 引数も承諾型を指定するものとされていますが、 そちらは認可エンドポイントで認可符号または暗示的承諾型のいずれかを選択するものとなっています。

[33] GitHub や Heroku は OAuth の通常のフローとは別に、 認可を操作する API を用意しています >>32, >>34。 OAuth フローを介さずに API からアクセストークンを発行したり、 (トークンの revoke ではなく) 認可を取り消したりできます。

メモ

[35] draft-recordon-oauth-v2-device-00 - OAuth 2.0 Device Profile ( 版) https://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

[36] draft-hunt-oauth-chain-01 - Chain Grant Type for OAuth2 ( 版) https://tools.ietf.org/html/draft-hunt-oauth-chain-01

[37] draft-zhou-oauth-owner-auth-01 - Owner Authorization Grant Type Profile for OAuth 2.0 ( 版) https://tools.ietf.org/html/draft-zhou-oauth-owner-auth-01

Updated: