I fully agree with Brian and would like to add some thoughts:
Not authenticating the client does not directly create a security
problem at all. If we would follow this line, every e-Mail client out
there would be considered insecure because the client itself is never
authenticated. Not even Kerbereos has a concept of client authentication.
In my opinion, OAuth client authentication (in delegated authorization
scenarios) is an improvement over classical approaches. But I do not see
a degration in security if it is not applicable. As long as the _user_
authorizes the client's access (and the duration of the token) and is
able to revoke the tokens at any time, the situation is much better than
with classical approaches.
regards,
Torsten.
Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -
I haven't read all of your comments yet, but I wanted to clarify one
point about client impersonation and installed apps. The cuirrent
text is unrealistic, but your request would push it the wrong way.
CC'ing Torsten as well.
---------------------
OLD:
The authorization server SHOULD issue access tokens with limited
scope and duration to clients incapable of authenticating.
NEW:
If the authorization server issues access tokens to clients
that are incapable of authenticating, the scope and duration of
such tokens SHOULD be limited.
RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------
We are most definitely recommending that clients that have no way of
authenticating are issued long-lived credentials to access user data.
Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk
That's a horrible security problem, because it means you cannot
upgrade user authentication to anything stronger than a password.
Client certificates, one time passwords, risk based authentication,
throw it all out the window. If you're going to let installed apps
authenticate with just a password, nothing else you do to improve
authentication is going to help.
This is a blocking issue for rolling out stronger forms of user
authentication, and it's one of the main reasons I care about OAuth2.
Think IMAP and XMPP clients running on Windows desktops. They are
important, and we need a way to migrate them off of saving passwords.
So the current text basically says that you should issue temporary
credentials to native apps. That's not practical. Native apps end up
needing permanent or near-permanent credentials. Expirations need to
be measured in months. And the credentials are going to be issued to
stock IMAP and XMPP clients that don't have any way of authenticating
themselves.
The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP
servers, they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can
create flows that bridge from those managed credentials to temporary
access credentials.
Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
