Am 28.05.2011 20:25, schrieb Doug Tangren:
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 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.
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.
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.
[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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
