agree that it'd be preferable to refer to the higher level grant
related, the spec stipulates
'The client MUST NOT make any assumptions about the timing and MUST NOT
use the token again.'
So what does the client do with it's existing access token when it
revokes the associated refresh token?
The rule indicating to the AS that access tokens be revoked as well is
only a SHOULD, so the client can't be certain that the access token is 'bad'
paul
On 6/13/12 2:01 AM, Torsten Lodderstedt wrote:
Hi all,
we should probably adopt the wording to refer to the access grant
underlying all tokens? Something like: "based on the same access grant
...".
What do you think?
regards,
Torsten.
doug foiles <doug.foi...@gmail.com> schrieb:
Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to
comment on what was intended for this ... and would be much
appreciated.
On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
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
<paul.mad...@gmail.com <mailto:paul.mad...@gmail.com>> 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
<gffle...@aol.com <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
