Am 28.02.2011 23:58, schrieb Marius Scurtescu:
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
<igor.faynb...@alcatel-lucent.com> wrote:
+1
Igor
Torsten Lodderstedt wrote:
...
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.
I think it is much safer to go with refresh tokens only sent
indirectly through an authorization code swap.
why is it _much_ safer? The only threat elimimated by this approach is a
token leak via browser cache. On the other hand, the authorization code
flow has to be protected from session fixation and guessing attacks,
threats which are not applicable to the implicit grant flow.
It seams to be acceptable to issue access tokens with the implicit grant
but not refresh tokens. Why? Because we assume access tokens have a much
sorter lifetime than refresh tokens? This is not specified by the draft!
So anyone could issue access tokens with infinite lifetime via the
implicit grant and claim full OAuth 2.0 compliance.
Implicit grant with refresh token also has no client secret swap and
makes things worse by passing the refresh token through the browser.
What do you think is the value of having a client secret for a native app?
As pointed out in my previous posting, refresh tokens can be invalidated
during every refresh request. So the impact can be reduced to that of an
access token leak (which seams to be acceptable).
regards,
Torsten.
Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
