Section 4.2 of the draft OAuth 2.0 protocol indicates that an authorization server can return both an access_token (which is used to authenticate oneself with a resource) as well as a refresh_token, which is used purely to create a new access_token:
https://www.rfc-editor.org/rfc/rfc6749#section-4.2
Why have both? Why not just make the access_token last as long as the refresh_token and not have a refresh_token?
ベストアンサー1
The link to discussion, provided by Catchdave, has another valid point (original, dead link) made by Dick Hardt, which I believe is worth to be mentioned here in addition to what's been written above:
My recollection of refresh tokens was for security and revocation. <...>
revocation: if the access token is self contained, authorization can be revoked by not issuing new access tokens. A resource does not need to query the authorization server to see if the access token is valid.This simplifies access token validation and makes it easier to scale and support multiple authorization servers. There is a window of time when an access token is valid, but authorization is revoked.
Indeed, in the situation where Resource Server and Authorization Server is the same entity, and where the connection between user and either of them is (usually) equally secure, there is not much sense to keep refresh token separate from the access token.
Although, as mentioned in the quote, another role of refresh tokens is to ensure the access token can be revoked at any time by the User (via the web-interface in their profiles, for example) while keeping the system scalable at the same time.
Generally, tokens can either be random identifiers pointing to the specific record in the Server's database, or they can contain all information in themselves (certainly, this information have to be signed, with MAC, for example).
How the system with long-lived access tokens should work
The server allows the Client to get access to User's data within a pre-defined set of scopes by issuing a token. As we want to keep the token revocable, we must store in the database the token along with the flag "revoked" being set or unset (otherwise, how would you do that with self-contained token?) Database can contain as much as len(users) x len(registered clients) x len(scopes combination) records. Every API request then must hit the database. Although it's quite trivial to make queries to such database performing O(1), the single point of failure itself can have negative impact on the scalability and performance of the system.
How the system with long-lived refresh token and short-lived access token should work
Here we issue two keys: random refresh token with the corresponding record in the database, and signed self-contained access token, containing among others the expiration timestamp field.
アクセス トークンは自己完結型であるため、その有効性を確認するためにデータベースにアクセスする必要はまったくありません。トークンをデコードし、署名とタイムスタンプを検証するだけで済みます。
それでも、リフレッシュ トークンのデータベースを保持する必要がありますが、このデータベースへのリクエストの数は、通常、アクセス トークンの有効期間によって定義されます (有効期間が長いほど、アクセス率は低くなります)。
特定のユーザーからクライアントのアクセスを取り消すには、対応するリフレッシュ トークンを「取り消し済み」としてマークし (または完全に削除し)、新しいアクセス トークンの発行を停止する必要があります。リフレッシュ トークンが取り消されている期間があることは明らかですが、そのアクセス トークンはまだ有効な場合があります。
トレードオフ
リフレッシュ トークンは、アクセス トークン データベースの SPoF (単一障害点) を部分的に排除しますが、明らかな欠点もいくつかあります。
「ウィンドウ」。「ユーザーがアクセスを取り消す」イベントと「アクセスが取り消されることが保証される」イベント間の時間枠。
クライアントロジックの複雑化。
リフレッシュトークンなし
- アクセストークンを使用してAPIリクエストを送信する
- アクセストークンが無効な場合は失敗し、ユーザーに再認証を求めます
リフレッシュトークン付き
- アクセストークンを使用してAPIリクエストを送信する
- アクセストークンが無効な場合は、リフレッシュトークンを使用して更新してください
- 更新リクエストが成功した場合は、アクセストークンを更新し、最初のAPIリクエストを再送信します。
- 更新リクエストが失敗した場合は、ユーザーに再認証を求めます
この回答が意味を成し、誰かがより思慮深い決定を下すのに役立つことを願っています。また、github や foursquare などの有名な OAuth2 プロバイダーの中には、リフレッシュ トークンのないプロトコルを採用しているものもあり、それに満足しているようです。