oauth-v2-1
oauth-v2-1 copied to clipboard
oauth-wg
Clarify limits on new access tokens issued from refresh tokens
from Vittorio:
https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-6
We might need to be more precise here. Do we mean the scopes consented by the RO in the request that led to the issuance of the RT being used? Just saying consented by the RO for the client does not exclude cases in which there are more instances of the client in operation. Say that I am running uber on phone 1 and I consent to read my google calendar, getting AT1 and RT1. Say that on phone 2 I also run the uber app, and this time I consent to write my google calendar, obtaining AT2 and RT2 on this new device. Now consider the various combinations here. Should RT2 allow me to get calendar:read too, given that it was already consented by RO for this client? Should RT1 allow me to get AT1’ containing calendar:write, given that RO consented for it when using a different instance of the same client? Whatever is the answer you want to the questions above, I think the spec should have language clear enough to unambiguously determine the desired behavior.
This is from the Security BCP, and I generally agree with this. I remember seeing somewhere a better description of limiting the access tokens to the same scope/permissions/privileges/etc as the original, but I can't seem to find it now.
What part of the Security BCP are you referring to? I'm only aware of https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.3, which refers to access tokens.
In my opinion the meaning of the text in OAuth 2.1. should be "refresh tokens shall always have a clear scope". In the end this requires the AS to tie the RT to a certain user approved grant (and its scope) (3rd parties) or a certain policy (1st parties).
I would consider this best practice and suggest to adopt the wording along these + move this to the security considerations.
We'll call out that the scope authorized in subsequent flows being either what was just asked for or includes scopes that were previously authorized to that client ID is dependent on AS policies. This will the new scope section #159