Hi, I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.
regards, Torsten. Sergey Beryozkin <[email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
