メインコンテンツまでスキップ

2.2. Access Token Request (アクセストークンリクエスト)

2.2. Access Token Request (アクセストークンリクエスト)​

トークンエンドポイント (token endpoint) へ行われるアクセストークンリクエストで resource パラメーターが用いられる場合, すべての grant type に対し, クライアントが要求したアクセストークンを使用する意図のある対象サービスまたは保護リソースを示す.

アクセストークンリクエストを履行する際に認可サーバーが受け入れ可能なリソース値は, ローカルポリシーまたは設定に基づきその単独の裁量による. refresh_token または authorization_code grant type のリクエストでは, そのようなポリシーは受け入れ可能なリソースを, もともとリソースオーナーにより付与されたものまたはその部分集合に限定してもよい. authorization_code の場合, 要求されたリソースがもともと付与されたリソース集合の部分集合であれば, 認可サーバーはその部分集合に基づいてアクセストークンを発行し, 返される refresh token があればそれは元の完全なグラントに束縛される.

トークンを要求する際, クライアントは resource パラメーターによりそのトークンを使用する意図の対象サービスを示し, scope パラメーターにより要求トークンの望ましい scope を示すことができる. そのようなリクエストの意味論は, クライアントが, 要求された scope を持ちすべての要求対象サービスで使用可能なトークンを求めているということである. 実質的に, トークンに要求されるアクセス権はすべての対象サービスにおけるすべての scope のデカルト積 (cartesian product) である. 可能な限りアクセストークンを発行する際, 認可サーバーはアクセストークンに関連付けられた scope 値を, それぞれのリソースが処理でき必要とする値へ downscope (ダウンスコープ, 元のリソースオーナー認可より少ない権限を与えること) すべきである. これはプライバシーをさらに改善する. scope 値のリストはリソースオーナーが列挙された複数の各種サービスを利用している示唆となるからであり, トークンを特定のサービスに必要な範囲だけに downscope すれば, そのような情報が異なるサービス間で露呈する度合いを抑えられる. [RFC6749] 第 5.1 節で規定されるとおり, 有効 scope がクライアントが要求した scope と異なる場合, 認可サーバーは scope 応答パラメーター値でアクセストークンの有効 scope をクライアントに示さなければならない.

図 2 の code flow 認可リクエストに続き, 以下は authorization_code grant type のアクセストークンリクエスト (図 3) と応答 (図 4) の例であり, クライアントが https://cal.example.com/ で使用するアクセストークンを求めている (表示のための追加の改行とインデント).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
&resource=https%3A%2F%2Fcal.example.com%2F

図 3: アクセストークンリクエスト

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
    ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
    lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
    zkiQNVpYw",
   "token_type":"Bearer",
   "expires_in":3600,
   "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
   "scope":"calendar"
}

図 4: アクセストークン応答

refresh token を用いた後続のアクセストークンリクエストで, クライアントが https://contacts.example.com/ で使用するアクセストークンを求める例を図 5 に, 応答を図 6 に示す (表示のための追加の改行とインデント).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
&resource=https%3A%2F%2Fcontacts.example.com%2F

図 5: アクセストークンリクエスト

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
    ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
    OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
    UowfmtNaA5EikYAw",
   "token_type":"Bearer",
   "expires_in":3600,
   "scope":"contacts"
}

図 6: アクセストークン応答

に最終更新