Subject: [OAUTH-WG] Associating access_token with user-agent on client?

From: "Martin, Bobby" <[email-masked]>
Date: Tue, 28 Feb 2012 13:54:00 -0800

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

---

From: André DeMarre <[email-masked]>
Date: Tue, 28 Feb 2012 16:13:37 -0800

Neglected to copy the WG.

---------- Forwarded message ----------
From: André DeMarre <[email-masked]>
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-masked]>

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-masked]> 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.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Martin, Bobby" <[email-masked]>
Date: Tue, 28 Feb 2012 16:18:47 -0800

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

---------- Forwarded message ----------
From: André DeMarre <[email-masked]>
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-masked]>

Regards,
Andre DeMarre

On Tue, Feb 28, 2012 at 1:54 PM, Martin, Bobby <[email-masked]> wrote:
> I searched the list archives and in general googled around, but I don't see
> require a login in the client's domain.
>
>
>