You assume correctly :-) I do recognize that general authentication of a user on a web site is the problem, and that it is to some degree outside the scope of OAuth. I waffled about including that in my original email; I felt that it watered down the argument.
In our model the authentication of the user on the client (by the OAuth 2.0 spec's definition of client, in our case a web server) is mixed up somewhat with the OAuth authentication process. Before the user authenticates with the auth server, the user on the client has no identity, or at most has an anonymous session. It is the act of authenticating with the auth server which gives the user a meaningful identity on the client. In our design so far we have elected to send back a cookie in the response from the final 302 to the client redirect_uri. In fact, our whole client domain(s) are insecure, and securing all of them is essentially impossible. So we need to do a balancing act in that we would like to limit the scope of the breach if the client authentication is hijacked, but we know that for many threats we simply have no recourse. (No recourse in that e.g. a MITM attack is always possible on an insecure domain). Which is acceptable because the resources are relatively low value (user's real name, etc). To be more specific about limiting the scope of a breach - for example it is less impactful for a 3rd party to be able to snoop on the transactions that the user agent initiates than to be able to make arbitrary requests itself, and less impactful for a 3rd party to be able to retrieve data about the user for a limited time than for them to be able to retrieve at any time in the future. Does anyone have recommendations of specs to look at for the specifically managing user authentication with an insecure server, which work well with the OAuth 2.0 model? Thanks! Bobby -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of André DeMarre Sent: Tuesday, February 28, 2012 4:14 PM To: OAuth WG Subject: [OAUTH-WG] Fwd: Associating access_token with user-agent on client? Neglected to copy the WG. ---------- Forwarded message ---------- From: André DeMarre <[email protected]> Date: Tue, Feb 28, 2012 at 3:52 PM Subject: Re: [OAUTH-WG] Associating access_token with user-agent on client? To: "Martin, Bobby" <[email protected]> I assume you're talking about the authorization code flow, and that your client is a server-side web application. How to persist state to maintain a session between a user agent and a web app client is beyond the scope of OAuth. The spec alludes to it in its explanation of the "state" parameter and CSRF, but that's not what you're asking. The client will usually use cookies to maintain a user session, and it's up to the client to decide how sessions are secured. This is no different when the client uses an OAuth server for user authentication; the client still needs to manage a session so it can identify the user as he interacts with the app. There is a difference between matching a user to a real identity (authentication), and recognizing the same user between stateless HTTP requests (sessions). You do bring up a very good point though, that being that if a user's client session is hijacked, then the attacker can use the client to access the user's protected resources. Session security at the client is beyond the scope of OAuth, and the spec only touches on it in its consideration of client redirection endpoint security. For example, see section 3.1.2.1 (http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.1.2.1). OAuth is not about securing web applications, but at the very least, perhaps the threat model document could explain that clients need to defend against session hijacking, not only at the redirection endpoint but throughout the application. In the case of cookie-based sessions, the session ID cookie should only be transmitted over TLS. If it's in the threat model already, I must have overlooked it. Regards, Andre DeMarre On Tue, Feb 28, 2012 at 1:54 PM, Martin, Bobby <[email protected]> wrote: > The OAuth 2.0 spec specifically says not to return the access_token to the > user-agent (which I understand), but it does not indicate how to associate > the access_token with a particular client session. > > > > This seems like an important omission, since any way that spoofs how the > client recognizes a user-agent request as belonging to a resource owner is > as good as spoofing the access_token. > > > > I searched the list archives and in general googled around, but I don't see > any discussion of this. In our use case, we want to recognize the customer > based on their authentication with the auth server, so ideally we do not > require a login in the client's domain. > > > > Can someone point me to discussions around this? > > > > Thanks, > > Bobby > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
