Hi George, perhaps it depends on the reason for the refresh token being revoked. If because the user removed their consent then yes I agree that *all* tokens should be revoked
Sent from my iPhone On 2012-06-11, at 5:10 PM, George Fletcher <gffle...@aol.com> wrote: > Paul, > > I think I came to a different conclusion... > > If I use the Resource Owner Password Credential flow and get back both an > access_token and a refresh_token then I would assume that the issued > access_token is tied in some way to the refresh_token. If the refresh_token > is revoked, then my expectation is that the simultaneous issued access_token > would also be revoked. > > I read the spec as having a typo that should read... > If the processed token is a refresh token and the authorization > server supports the revocation of access tokens, then the > authorization server SHOULD also invalidate all access tokens issued > *based on* that refresh token. > Or maybe better... "invalidate all access tokens associated/tied-to that > refresh token". > > Now in the case that the client is retrieving a new refresh_token and > access_token, then the new ones should be valid and the old ones potentially > revoked. > > Thanks, > George > > On 6/11/12 4:09 PM, Paul Madsen wrote: >> >> Hi Doug, my interpretation is that 'for that refresh token' means those >> access tokens issued in exchange for that refresh token. >> >> Consequently, for the cases you cite below, the access tokens at the same >> time as a given refresh token need not be invalidated when that refresh >> token is 'processed' >> >> I assume the justification for the rule is that an access token issued in >> exchange for a given refresh token may have been compromised if the refresh >> token had been. But there is no such causal relationship between an access >> token & refresh token issued at same time >> >> paul >> >> On 6/11/12 3:31 PM, doug foiles wrote: >>> >>> Hi all, >>> >>> I was hoping to get some clarity on a statement in section 2.0 of >>> draft-ietf-oauth-revocation-00. >>> >>> If the processed token is a refresh token and the authorization >>> server supports the revocation of access tokens, then the >>> authorization server SHOULD also invalidate all access tokens issued >>> for that refresh token. >>> >>> My question is on the statement "access tokens issued for that refresh >>> token". What does it mean to have an Access Token "issued" for a Refresh >>> Token? >>> >>> This specific case is clear to me. I am refreshing an Access Token where I >>> keep the same Refresh Token that I used to generate the new Access Token. >>> I see the new Access Token was issued for that Refresh Token. >>> However these two cases are a bit muddy to me. Let’s say I am using the >>> "Resource Owner Password Credentials Grant" where the Access Token Response >>> returns both an Access Token and Refresh Token. Would the Access Token >>> have been issued for that Refresh Token? And let’s say I am refreshing an >>> Access Token but choose to create a new Refresh Token and immediately >>> revoke the original Refresh Token. Would the newly created Access Token >>> have been issued for the original Refresh Token or the new one that was >>> created. >>> If a client would revoke a Refresh Token … I would like the Access Tokens >>> in all of the above cases to be automatically revoked as well. I just want >>> to make sure I understand the model. Thanks. >>> Doug Foiles >>> Intuit >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
