リフレッシュトークンの継続利用設定
概要
OAuth 2.0 の「リフレッシュトークングラント」では、クライアントは認可サーバーに対し、事前に発行されたリフレッシュトークン (RT) を送信し、アクセストークン (AT) 発行を要求します。RT が有効な場合、認可サーバーは新たな AT を発行し、クライアントに返却します。
この際に利用された RT の取り扱いについては以下の選択肢があります。
- 1-1: 継続使用する(無効化しない)& 有効期間をリセットしない
- 1-2: 継続使用する(無効化しない)& 有効期間をリセットする
- 2-1: 継続使用しない(無効化する)& 有効期間を引き継がない
- 2-2: 継続使用しない(無効化する)& 有効期間を引き継ぐ
上記の選択肢に加えて、Authlete は「トークン有効期限のリンク」機能を提供します。これは、発行する AT の有効期間を RT の残り有効期間に制限するものです。
Authlete では、設定により、いずれにも対応可能です。それぞれの特性について以下に説明します。
Authlete では、設定により、いずれにも対応可能です。それぞれの特性について以下に説明します。
1-1: 継続使用する場合 & 有効期間をリセットしない場合
認可サーバーは RT (rt1) を持つクライアントからのトークンリフレッシュ要求に対して、新しい AT (at2) とクライアントが提示してきた RT (rt1) をクライアントに返却します。RT (rt1) の有効期間が残っている限り、クライアントはRT (rt1) をトークンリフレッシュ要求に使用し続けることができます。
RT (rt1) の有効期間はトークンリフレッシュを行っても変更されません。
1-2: 継続使用する場合 & 有効期間をリセットする場合
認可サーバーは RT (rt1) を持つクライアントからのトークンリフレッシュ要求に対して、新しい AT (at2) とクライアントが提示してきた RT (rt1) をクライアントに返却します。RT (rt1) の有効期間が残っている限り、クライアントはRT (rt1) をトークンリフレッシュ要求に使用し続けることができます。
RT (rt1) の有効期間はトークンリフレッシュ要求ごとに初期値にリセットされます。結果的に、RT (rt1) の有効期間は延長されます。

2-1: 継続使用しない & 有効期間を引き継がない場合
認可サーバーは RT (rt1) を持つクライアントからのトークンリフレッシュ要求に対して、新しい AT (at2) と RT (rt2) をクライアントに返却します。クライアントが認可サーバーに提示した RT (rt1) は無効化されるため、次回以降のトークンリフレッシュ要求では RT (rt1) を利用することはできなくなります。
RT (rt2, rt3, …) の有効期間は初期値が設定されます。結果的に、RT (rt2, rt3, …) の有効期間の合計は RT (rt1) の初期値よりも長くなります。
2-2: 継続使用しない & 有効期間を引き継ぐ場合
認可サーバーは RT (rt1) を持つクライアントからのトークンリフレッシュ要求に対して、新しい AT (at2) と RT (rt2) をクライアントに返却します。クライアントが認可サーバーに提示した RT (rt1) は無効化されるため、次回以降のトークンリフレッシュ要求では RT (rt1) を利用することはできなくなります。
RT (rt2, rt3, …) の有効期間は最初に発行された RT (rt1) の残りの有効期間が設定されます。結果的に、RT (rt2, rt3, …) の有効期間の合計は RT (rt1) の初期値と同じになります。

トークン有効期限のリンク
認可サーバーは RT (rt) を持つクライアントからのトークンリフレッシュ要求に対して、その RT の残存期間が AT のデフォルト期間より短いかどうかをチェックします。真であれば、Authlete は、持続時間を RT の残り持続時間にリンクした AT を発行します。

設定
Authlete サービスの「トークン」タブにある「リフレッシュトークン継続使用」にて、「継続使用する」「継続使用しない」のいずれかを選択します。それぞれの選択肢にはさらに追加の設定が存在します。
- 「継続使用する」を選択した場合: 「リフレッシュトークン有効期間のリセット」の「有効」「無効」を指定できます。
- 「継続使用しない」を選択した場合:「リフレッシュトークン有効期間引継」の「有効」「無効」を指定できます。
また、上記の選択にかかわらず、「トークン有効期限リンク」の項目で「リンクする」「リンクしない」を指定できます。
実行例
以下は、クライアントからの、RT (<refresh_token_1>) を用いたトークンリクエストに対して、Authlete がどのようなレスポンスを返却するかの例です。
- リクエスト
認可サーバーは、Authlete の /auth/token API に、RT を含むトークンリクエストを処理するよう、リクエストを送信します。以下は curl を用いる例です。(読みやすさのために折り返しています)
curl -s -X POST .../auth/token -u $apiKey:$apiSecret -H 'Content-type: application/json' -d '{"clientId":"...", "clientSecret":"...", "parameters": "grant_type=refresh_token &refresh_token=<refresh_token_1>"}'
- 「継続使用する & 有効期間をリセットしない」が指定された場合のレスポンス
リクエストに用いたものと同一の RT (<refresh_token_1>) を返却します。有効期間は初期化されません(この例では残り 332 秒)。
{ "type": "tokenResponse", "resultCode": "A053001", "resultMessage": "[A053001] The token request (grant_type=refresh_token) was processed successfully.", "accessToken": "...", "action": "OK", "grantType": "REFRESH_TOKEN", "refreshToken": "<refresh_token_1>", "refreshTokenDuration": 332, "refreshTokenExpiresAt": ..., "responseContent": "{\"access_token\":\"...\", \"refresh_token\":\"<refresh_token_1>\", \"scope\":\"payment\", \"token_type\":\"Bearer\", \"expires_in\":300}", "scopes": [ "payment" ], "subject": "testuser01", ... }
- 「継続使用する & 有効期間をリセットする」が指定された場合のレスポンス
リクエストに用いたものと同一の RT (<refresh_token_1>) を返却します。有効期間は初期化されます。(例は省略します)。
- 「継続使用しない & 有効期間を引き継がない」が指定された場合のレスポンス
新たな RT (<refresh_token_2>) を発行・返却します。また、有効期間は初期化されます(この例では 900 秒)。
{ "type": "tokenResponse", "resultCode": "A053001", "resultMessage": "[A053001] The token request (grant_type=refresh_token) was processed successfully.", "accessToken": "...", "action": "OK", "grantType": "REFRESH_TOKEN", "refreshToken": "<refresh_token_2>", "refreshTokenDuration": 900, "refreshTokenExpiresAt": ..., "responseContent": "{\"access_token\":\"...\", \"refresh_token\":\"<refresh_token_2>\", \"scope\":\"payment\", \"token_type\":\"Bearer\", \"expires_in\":300}", "scopes": [ "payment" ], "subject": "testuser01", ... }
- 「継続使用しない & 有効期間を引き継ぐ」が指定された場合のレスポンス
新たな RT (<refresh_token_2>) を発行・返却します。有効期間は初期化されません(例は省略します)。
How did we do with this article?