Am 18.02.2011 18:40, schrieb Marius Scurtescu:
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin<mark.mcgl...@ie.ibm.com> wrote:
Marius
Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both?
Sure, but refresh tokens never die.
One can replace the refresh token with every refresh request, so the
impact of a refresh token leakage could be reduced to that of a leaked
access token.
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable for native apps. On the other
hand, requirements of the authorization code flow could be strengthened
to require client authentication.
regards,
Torsten.
IMO, the refresh token
just provides a server side mechanism for revoking access, where resource
servers are distributed, through having short lived access tokens
Of course, the refresh access token flow currently requires a secret so
would need to be changed or alternative flow introduced. Will wait for
details of how auth code flow can be used
The flow is not changing. For native apps the client secret can either
be declared optional, or a "well known secret" can be issued for
native apps.
The authorization server can also insist that each native app has a
unique secret and it must guard it, that may or may not make sense.
Marius
_______________________________________________
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
