Hi,
On 30/11/12 06:48, Torsten Lodderstedt wrote:
Hi,
it might be reasonable in some cases to revoke the old access token (if
the AS actually supports access token revocation). However, I can
imagine situations in clustered systems where access tokens are acquired
from from the same refresh token and used independently by different
nodes or modules. In this case, revocation on refresh would not be desired.
Note: In this case one would probably not use refresh token rotation.
What I'm understanding is that there are many subtleties with the way
refresh grant can be used in different scenarios. I hope in time there
will be more specific recommendations about the refresh grants and
specifically about the expectations of the clients with respect to using
such grants.
For the moment "use it when AT has expired" is the most straightforward
case with the predictable outcome and thus the code which use the grant
for these purposes is portable. The other uses of the grant (with or
without the optional scope) have the application-specific outcome - so
hopefully in time more of these application specific uses will make it
into the spec level text - IMHO it will help users or developers like
myself :-)
Thanks
Sergey
regards,
Torsten.
Sergey Beryozkin <sberyoz...@gmail.com> schrieb:
Apologies for a noise on it, however I'd like to get some more
clarifications on it.
What I thought first about the refresh grant was that a client would use
it for getting a new access token back after it gets a 401 back from PR.
Next after seeing the comments from others it became obvious the refresh
grant can be used to pro-actively refresh the existing token when the
client realizes - this is what I'm really going to ask about.
I also learned about the fact a refresh grant can effectively be used to
clone the existing token - I'd like to avoid talking about this case in
this thread, even I got it wrong with the term 'clone' :-)
So, as far as the refresh token grant is concerned, the grant which is
'supported' by the core spec, what are the expectations of the client
which request to refresh a
still valid access token ?
I got a bit confused by the feedback that it may be per-AS specific.
If it were the expectation then I'd not see the difference between the
core spec "refresh_token" grant and "a.b.c" custom grant.
It seems reasonable that if the client does decide to be proactive and
use a refresh grant without using any optional scopes, and specifically
with the main and only purpose to refresh the access token which may get
expired shortly, it should predictably get a new access token with a new
time lease...
And which means the old token must've gone by now and effectively
revoked. This exactly what the client means, get me a new refreshed
token...
I've checked the token revocation grant. It's obviously a good idea to
let the client directly interact with the endpoint and remove whatever
token it want to remove. However, a refresh token request (without a
scope
parameter) should have the same side-effect
Does it make any sense at all ?
Thanks, Sergey
------------------------------------------------------------------------
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
