Subject: [OAUTH-WG] draft 16 notes on security considerations

From: Doug Tangren <[email-masked]>
Date: Sat, 28 May 2011 14:25:09 -0400

I just re-read draft 16 on this memorial day weekend :)

1. I had a comment on the suggested use of the authorization code flow for
native clients [1].

Section 10.9 on auth code transmission [2] suggests users of the auth code
flow should implement tls on it's redirect uri. This makes sense for web
servers which may register something like "https://foo.com/i/got/authed" but
may not be possible on native clients.

It's a common practice for android clients, for instance, to open a browser
window to authorize a user via `Intent` and then register their redirect_uri
to be a custom scheme registered with their android `activity`, something
like "myapp://i/got/authed".

2. With regards to resource owner creds flow security consideration
mentioned [3], it really feels like this is dodging the whole idea of oauth
asking for authorization on the site owning the resources.

Is this mainly meant for `official` apps developed by the site owning the
resource?
Otherwise, it feels like its no different than ye old basic http auth and
gimme your login and password and trust me not to store them.

[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9
[2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9
[3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12

-Doug Tangren
http://lessis.me

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 29 May 2011 15:06:52 +0200

Am 28.05.2011 20:25, schrieb Doug Tangren:
> 1. I had a comment on the suggested use of the authorization code flow 
> for native clients [1].
>
> Section 10.9 on auth code transmission [2] suggests users of the auth 
> code flow should implement tls on it's redirect uri. This makes sense 
> for web servers which may register something like 
> "https://foo.com/i/got/authed" but may not be possible on native clients.

It makes sense for all flows where the redirect_uri referes to a server 
resource. This holds true for web servers acting as OAuth client as well 
as any server-based resource used by other clients to obtain the 
authorization code. This should be clarified.

>
> It's a common practice for android clients, for instance, to open a 
> browser window to authorize a user via `Intent` and then register 
> their redirect_uri to be a custom scheme registered with their android 
> `activity`, something like "myapp://i/got/authed".

As pointed out by e.g. Marius in some postings, there are other 
techniques as well. Some of them are based on server resources the 
native app relies on.

> mentioned [3], it really feels like this is dodging the whole idea of 
> oauth asking for authorization on the site owning the resources.

The section clearly states our preference to use other grant types.

    "The authorization server and client SHOULD minimize use of this grant
    type and utilize other grant types whenever possible."

Apart from that, I would not limit OAuth 2.0 to "just" delegated 
authorization via end-user authorization. In my opinion, OAuth 2.0 is a 
generic token issuance framework. Such tokens can be issued based on 
delegation flows but also based on direct authentication on the tokens 
endpoint. Other examples of reasonable credentials are assertions of all 
kind. We at Deutsche Telekom also added a custom grant type to directly 
authenticate users based on their SIM card.

What I like the most, OAuth 2.0 combines the user involvement of OAuth 
1.0 with architectural properties of Kerberos (trusted third-party 
authentication, scalability). Moreover, it is based on and integrated 
with HTTP(S) and allows to use different token formats (and even designs).

>
> Is this mainly meant for `official` apps developed by the site owning 
> the resource?

We use it for our own apps. Here, the decision to use web-based flows or 
username/password is typically met by product managers.

> Otherwise, it feels like its no different than ye old basic http auth 
> and gimme your login and password and trust me not to store them.

It clearly has the security advantages that refresh tokens instead of 
passwords are stored in order to provide a convenient login experience. 
The scope of such a token can (and must) be much less powerful than a 
password.

regards,
Torsten.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth