Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

[Justin Richer <[e-mail]>]

I agree with Doug and George's reading: nuking the refresh token gets 
rid of all access tokens associated with that refresh token's lifetime. 
This includes both simultaneous issuance as well as derived issuance.

  -- Justin

On 06/11/2012 08:13 PM, doug foiles wrote:
> Hi Paul and George,
> Even though the Access Token is short lived, I would still like to 
> revoke it immediately if the user chooses to revoke the Refresh 
> Token.  And I would love for the client application to only have to 
> make one web service call to accomplish that and not one for the 
> Refresh Token and another for the Access Token.
> Given that we always generate a new Refresh Token value during "Token 
> Refresh", we would never have a true parent / child relationship 
> between a Refresh Token and Access Token.
> Is there a case where it is NOT appropriate to revoke an "associated" 
> Access Token when explictly revoking a Refresh Token?  I define 
> "associated" as an Access Token generated from a Refresh Token OR 
> generated at the same time of the Refresh Token.
> I do see the AS challenges in trying to manage multiple 
> simultaneous "associated" Access Tokens.  For example let's say a 
> client generates multiple Access Tokens at the same time while 
> generating new Refresh Token values during each "Token Refresh" 
> operation.  However I don't really see the useful of this case.
> Doug
>
> On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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 <[e-mail]
>     <mailto:[e-mail]>> 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
>>>>     [e-mail]  <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail]  <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth