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

Neglected to copy the WG.

---------- Forwarded message ----------
From: André DeMarre <andredemarre@gmail.com>
Date: Tue, Feb 28, 2012 at 3:52 PM
Subject: Re: [OAUTH-WG] Associating access_token with user-agent on client?
To: "Martin, Bobby" <bobbym@amazon.com>

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 <bobbym@amazon.com> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>