Subject: [OAUTH-WG] oauth2 implicit flow user experience

From: Doug Tangren <[email-masked]>
Date: Tue, 10 May 2011 09:25:15 -0400

Hi,

I'm implementing an authorization and resource server at worked based on the
oauth2 draft 15. A question arose about the user experience of users of an
implicit client flow.  I've set a one hour expiry on access tokens but now
the question is should the client be forced to re-prompt the user for
authorization when their receive an error response from the resource server
or when they refresh the page?

I realize that some implementation details like this are mentioned as being
beyond the scope of the spec but I wanted to get a general sense of what the
authors and implementors thoughts about how it would actually be used and
what is the expected user experience.

I also realize that from a server's perspective, without a client secret,
authorization code, or other prior evidence of who a request is coming from
that there is little way for a server to be permissive about allowing for
the refreshing of an access token in an implicit flow. Has there been any
conversation around possible alternatives that would permit users of the
implicit flow to have the same user experience as the authorization code
flow?

Thanks

-Doug Tangren
http://lessis.me

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 10 May 2011 12:14:50 -0700

> implicit flow to have the same user experience as the authorization code

This question was raised a few times on this list. The only solution I
am aware of is for the authorization server to support auto-approvals
and an immediate mode,

Auto-approval means that the server will not show the approval page if
the same user/scopes/client have already been approved. So as long as
the user has an active session the client can get new access tokens in
a hidden iframe.

If the user session times out then the request in the iframe will
hang, the frame will be redirected to a login page. To prevent this
the client must be able to tell authorization server that it wants an
immediate type request, no UI whatsoever should be shown and if
auto-approval is not possible, or not active session, then just return
an error. The client then can popup a window and start a regular
request, so the user can login and/or approve.

Auto-approvals are up to the server to support, no support from the
protocol is required. You probably want to support this only for the
implicit flow. Immediate mode needs a special request parameter and
also a special error code. There is no extension that defines these,
the suggestion was that this should go into the OpenID Connect spec,
together with a username hint parameter.

Hope this helps,
Marius

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Wed, 11 May 2011 01:43:32 +0200

Hi Marius,

wrt "auto-approval": how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse the authorization previously approved by the user as long as the session with the authorization server is valid. The redirect_uri won't help for all kinds of clients since a native app could use the correct redirect_uri and nevertheless get access to the token. 

regards,
Torsten.

> -----Ursprüngliche Nachricht-----
> Von: Marius Scurtescu [mailto:[email-masked]]
> Gesendet: Dienstag, 10. Mai 2011 21:15
> An: Doug Tangren
> Cc: [email-masked]
> Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 11 May 2011 11:28:14 -0700

> wrt "auto-approval": how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse…

The only validation is based on the redirect URI. Native apps should
not use the implicit flow, and in general there is no need for
auto-approval for them.

Marius

---

From: Breno <[email-masked]>
Date: Wed, 11 May 2011 11:32:33 -0700

On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten <
[email-masked]> wrote:

> Hi Marius,
>
> wrt "auto-approval": how is the authorization server supposed to validated
> the client's identity in a reliable way? Otherwise another application
> (using the id of the legitimate client) could abuse the authorization
> previously approved by the user as long as the session with the
> authorization server is valid. The redirect_uri won't help for all kinds of
> clients since a native app could use the correct redirect_uri and
> nevertheless get access to the token.
>

A native app that can screen scrape the browser can probably also install a
keylogger. It would be very difficult or impossible to protect against a
malicious native app with access to shared OS resources.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Wed, 11 May 2011 11:33:52 -0700

> malicious native app with access to shared OS resources.

By which I mean we should consider protection against apps with such
capabilities a non-goal for this protocol and not an impediment to enabling
of auto-approval modes.

-- 
Breno de Medeiros

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Wed, 11 May 2011 20:44:27 +0200

How shall the authorization server ensure that the calling client is a user-agent based app (i.e. a native app could impersonate an user-agent based app)?

In my opinion, enforcing explicit user consent is the only way to prevent this kind of attack.

regards,
Torsten.

> Gesendet: Mittwoch, 11. Mai 2011 20:28
> An: Lodderstedt, Torsten
> Cc: [email-masked]; Doug Tangren
> > wrt "auto-approval": how is the authorization server supposed to
> validated the client's identity in a reliable way? Otherwise another
> application (using the id of the legitimate client) could abuse the
> authorization previously approved by the user as long as the session
> with the authorization server is valid. The redirect_uri won't help for
> all kinds of clients since a native app could use the correct
> redirect_uri and nevertheless get access to the token.
>

---

From: Breno <[email-masked]>
Date: Wed, 11 May 2011 12:08:06 -0700

On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten <
[email-masked]> wrote:

> How shall the authorization server ensure that the calling client is a
> user-agent based app (i.e. a native app could impersonate an user-agent
> based app)?
>

Native apps will require access to shared OS resources to retrieve the
access token if the redirect URI is a web location registered with the
proper web client.

If the Native app has such access, the native app can do far more
interesting things to compromise the users credentials directly.

No amount of protocol sophistication can address this.

-- 
Breno de Medeiros

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 11 May 2011 13:38:45 -0700

> How shall the authorization server ensure that the calling client is a user-agent based app (i.e. a native app could impersonate an user-agent based app)?

Through registration and redirect URI validation. A native app does
not have to impersonate, they can just register a user-agent client.
Everything boils down to the user trusting the app. As Breno mentions,
nothing the spec can do to help with that.

Marius

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 12 May 2011 00:26:16 +0200

> nothing the spec can do to help with that.

It could recommend the authorization server not to automatically process repeated authorizations without user consent if it cannot reliably authenticate the client.

---

From: Breno <[email-masked]>
Date: Wed, 11 May 2011 15:46:32 -0700

On Wed, May 11, 2011 at 3:26 PM, Lodderstedt, Torsten <
[email-masked]> wrote:

> It could recommend the authorization server not to automatically process
> repeated authorizations without user consent if it cannot reliably
> authenticate the client.
>

And, as I explained above, it would provide no additional meaningful
security while at the same time eliminating the value of the user-agent
profile.

-- 
Breno de Medeiros