authorization grant

承諾 (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 引数で指定することになります。

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

[40] grant_type の値

[17] その他、クライアント認可鯖が定義する絶対URLによって拡張の承諾型を指定することができます >>5, >>15grant_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=oobGoogle 独自機能として 2-legged OAuthTwitter 独自機能として xAuth がありました。

関連

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

[33] GitHubHerokuOAuth の通常のフローとは別に、 認可を操作する API を用意しています >>32, >>34OAuth フローを介さずに 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