Am 04.05.2010 21:44, schrieb Marius Scurtescu:
On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
<[email protected]> wrote:
Am 03.05.2010 18:55, schrieb Allen Tom:
Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.
It could be an optional feature of the spec (as many other features).
Torsten, can you please have a look a the "explicit request for
refresh token" thread?
Would a "refresh_token_type=single" parameter solve the above?
Marius
Hi Marius,
I expected the authorization server to decide which kind of token to
use. Your proposal makes sense as well.
So the client can act according to its security requirements. If the
authorization server would like to enforce its
own policy, it can detect any mismatch during token issuance.
Nevertheless, support for the optional "refresh_token" response
parameter of the "refresh" request is the prerequisite.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
