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

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? 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

Mark
e-mail: mark.mcgloin@ie.ibm.com

oauth-bounces@ietf.org wrote on 16/02/2011 21:38:45:

> Marius Scurtescu <mscurtescu@google.com>
> Sent by: oauth-bounces@ietf.org
>
> 16/02/2011 21:38
>
> To
>
> Eran Hammer-Lahav <eran@hueniverse.com>
>
> cc
>
> OAuth WG <oauth@ietf.org>
>
> Subject
>
> Re: [OAUTH-WG] Draft -12 feedback deadline
>
> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> > The reason why we don't return a refresh token in the implicit
> grant is exactly because there is no client authentication...
>
> Not sure that's the main reason. AFAIK it is because the response is
> sent through the user-agent and it could leak.
>
>
> > These are all well-balanced flows with specific security
> properties. If you need something else, even if it is just a tweak,
> it must be considered a different flow. That doesn't mean you need
> to register a new grant type, just that you are dealing with
> different implementation details unique to your server.
>
> The Authorization Code flow, with no client secret, is perfectly fine
> for Native Apps IMO.
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth