RFC 8707 Resource Indicators for OAuth 2.0
yapooRFC 8707 - Resource Indicators for OAuth 2.0
クライアントが認可サーバーからアクセストークンを取得するにあたって、得たアクセストークンをどのリソースのために用いようとしているのかを認可サーバーに示す方法が定義されている。
クライアントは認可エンドポイントやトークンエンドポイントでパラメータ resource を (1 つ以上) 用いることでアクセストークンの用途を示す。resource パラメータは以下のルールを守る必要がある
-
resourceは絶対 URL である - フラグメント部を含んではならない
- クエリパラメータは含むべきではない
クライアントはアクセスしようとしているリソースのベース URI を resource として指定することで、複数のリソースへの権限のためにアクセストークンを用いることを示すことができる。本仕様で挙げられている例として、以下の 3 つのリソースへのアクセストークンを得たいときに resource として https://apps.example.com/scim/ を指定することができる。
https://apps.example.com/scim/Usershttps://apps.example.com/scim/Groupshttps://apps.example.com/scim/Schemas
認可サーバーは、リクエストに含まれる resource パラメータが不適切な場合にはエラーコード invalid_target を用いてエラーを返却する。
本仕様によって発行されるアクセストークンは、resource で指定されたリソースのみで用いることができるようなものであるべきとされている。アクセストークンが JWT 形式の場合、ペイロードの aud クレームによってアクセストークンが利用可能なリソースの一覧が示される (これはクライアントが resource で指定した値と同じでもよい)。同様に、トークンイントロスペクションエンドポイントに (JWT でない場合も含め) 当該アクセストークンを送ると、レスポンスの aud によって利用可能なリソースの一覧が示される。
認可エンドポイント
以下は Section 2.1 で示されている、認可エンドポイントで resource パラメータを用いる場合のリクエストの例である。
GET /as/authorization.oauth2?response_type=code
&client_id=s6BhdRkqt3
&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=calendar%20contacts
&resource=https%3A%2F%2Fcal.example.com%2F
&resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com
トークンエンドポイント
以下は Section 2.2 で示されている、トークンエンドポイントで resource パラメータを用いる場合のリクエスト例であり、上記の認可エンドポイントでの例で示されたリクエストで得た認可コードを用いてアクセストークンを取得する場合のリクエストである。
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
resource が認可エンドポイントで示された 2 つのうちの最初のものだけが指定されている。このとき認可サーバーはトークンエンドポイントで示された resource で使えるアクセストークンを返却する。
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"
}
このアクセストークンは JWT で、デコードすると aud クレームとして 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=refresh_token
&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
&resource=https%3A%2F%2Fcontacts.example.com%2F
ここで指定される resource は、最初に認可エンドポイントで指定したものには含まれるが、その後の 1 回目のトークンエンドポイントへのリクエストでは指定しなかったものであることに注意する。トークンのリフレッシュ時にはもともとのリソースオーナーから許諾を得た範囲で scope や resource を指定することが可能である (scope に関しては RFC 6749 Section 6 に記載がある)。