Hi,

I posted to the wrong thread, I just re-sent the correct one.

Regards,
Torsten.



Torsten Lodderstedt <[email protected]> schrieb:

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

Reply via email to