Hi Nick (+ OAuth WG) I'm sharing my thoughts from a personal review of draft-ietf-oauth-refresh-token-expiration-01.
1. This draft uses various terms in the context of OAuth authorizations. It may be helpful to define and differentiate between at least the following: - "Authorization," referring to the user's permission grant to the client. - "Access token," referring to the mechanism the client uses to prove their authorization. - "Refresh token," referring to the mechanism the client uses to get new access tokens, *not* to renew authorizations. Without the concept of expiring refresh tokens, it is/would be feasible to think of access tokens as analogous to authorizations, and refresh tokens as renewing those authorizations. Since we are now creating a meaningful difference between tokens and authorizations, clarifying that difference could be worthwhile. 2. *Section 5* (Refresh Token Expiration) states: If the user renews their authorization, the authorization server SHOULD > update the expiration time of existing refresh tokens if their lifetime was > truncated due to user authorization expiration. *Section 8* (User Experience Considerations) mentions one such renewal mechanism – a management UI provided by the authorization server. It may be helpful to move this example mechanism up to (or add a link to it from) *Section 5*. Alternatively, it may be better to give it its own heading or subheading (e.g. "Example Mechanisms for Updating Authorizations"). 3. The draft mentions that users could extend their authorizations, but could they also shorten them? Also, could the authorization server tighten refresh token timeouts? 4. *Section 6* (Token Endpoint Response) introduces 2 new fields that provide information about authorization expiration. It also mentions that the token endpoint may return this information even if a refresh token is not in the response, since the information could have been updated out of band. This currently is the only mechanism for clients to learn of updates to this info, which means they must rotate access tokens just to check expiration. *Section 8* (User Experience Considerations) reiterates this: The client would discover the extended expiration on its next refresh token > grant request. However, a client might never make an additional refresh token grant request if it believes the authorization has expired, which would lead to service interruptions anyway. I would suggest adding these to the token introspection endpoint defined by RFC 7662 <https://datatracker.ietf.org/doc/html/rfc7662> and recommending that clients occasionally invoke that endpoint with the refresh token to check expiration information. This would additionally solve for the scenario in (3) above: if a client thinks their refresh token times out in 14 days, they may not make a refresh request for 14 days; if the server updates this to 7 days in the background, the client wouldn't find out until service was interrupted, unless they were also polling an endpoint like introspect to check for updates. 5. In *Section 6.1*, after the definitions of the two fields: The authorization server MAY return these values even if *the response > contains no refresh_token field in the response.* change to [...] the response contains no refresh_token field. 6. In *Section 6.1.1*, last paragraph: If clients are requesting multiple scopes that can have different > lifetimes, *they will ultimately need make* their own tradeoffs to decide > how and when to ask the user for reauthorization. change to [...], they will ultimately need to make [...] 7. In *Section 6.1.2*, the draft mentions that the lack of expiration information in the token response may be seen as lack of support for expiration *or* the presence of an infinite grant. It might be helpful to add a note here about backwards compatibility, perhaps to the effect of "lack of a finite expiration today does not guarantee the server won't add one in the future." 8. The example in *Section 6.3* shows the grant state on initial authorization, after 7 days, and after 28 days. The third example *implies* that the refresh token was used between 7 and 28 days into the grant, since it would've expired otherwise. I might suggest an example on a shorter timescale to make this a little clearer: - Day 0: authorization granted, refresh_token_timeout 7 days, authorization_expires_in 10 days - Day 2: token refreshed, refresh_token_timeout 7 days, authorization_expires_in 8 days - Day 7: token refreshed, refresh_token_timeout 3 days, authorization_expires_in 3 days - Additional example of what would happen if the first refresh request was made on Day 8 9. In *Section 7* (Update to Authorization Server Metadata), it may be clearer for the new metadata field to take the value `token_timeout` rather than `credential` when referring to the possibility of refresh tokens timing out, for consistency with the concept. I think Dan's review of -00 asked about the meaning of these values, so this might help alleviate confusion. That's all I could think of for now. Hope this is helpful and happy to discuss further! Best, Vanshaj Singhania
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
