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
