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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
