Re: [OAUTH-WG] Draft -12 feedback deadline

Am 18.02.2011 18:40, schrieb Marius Scurtescu:
> On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin<mark.mcgloin@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