The ability to describe a client to the user does not depend on the authentication but on the identification of the client and the meta data available to the authz server. The only difference between identified and authenticated clients is the trust level the authz server has regarding the client's identity. It must clearly indicate this fact to the end-user.
regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 21:20 An: Torsten Lodderstedt; Brian Eaton Cc: OAuth WG Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 I agree to the extent that the user can be trusted to know how they got to the authorization endpoint. If the client cannot be authenticated, the authorization server is limited in the information it can offer the user to make the decision. It is extremely hard to come up with language that will tell the user to only approve the application, claiming to be X, if they got here from X directly. There might be ways to improve security a bit using Origin header etc. but overall, if the client is not authenticated, the authorization server can't really describe it to the user. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Thursday, June 02, 2011 2:10 AM To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 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
