CODEWITHSUNDEEP
securityauthenticationoauth-2.0bearer-token
Jamie Pollard
Jamie Pollard

Reputation: 1599

OAuth2 Token Validation and confidential clients

I have a question about OAuth2 and validating the client that a token has been assigned to.

The spec says that for confidential clients a client must authenticate when requesting tokens etc, for example with a basic auth header. This means we can verify that a client has been registered and an access token can be granted. The headers for a token request may look like the following:

 POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

The spec also says that once a token has been allocated, a client can use the token to request information by passing it in the auth header, as follows:

GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

This is fine, but say we have one or more client applications (lets call them App1 and App2), and our Server to which we have granted them access, via Token1 and Token2 respectively, how can we be sure that a request containing a bearer token sent in the auth header comes from the client application that we have assigned it to.

Can't App2 (somehow) get a hold of the token given to App1 (maliciously or otherwise) and just use it to gain access to resources by passing it in the auth header instead of its own token?

Should (is it even possible) we be sending two auth headers on the requests we make to resources, one with our bearer token and one with our client credentials so the serve can verify the token comes from the correct client?

Upvotes: 1

Views: 788

Answers (1)

Hans Z.
Hans Z.

Reputation: 53888

Short answer: that is not possible in a standardized way today.

The OAuth 2.0 specification today defines Bearer tokens that don't have the property that you're looking for since clients presenting them will get access to resources without proving that they're the rightful owner of that token. Tokens are meant to be delivered and used only over confidential (TLS) channels so they would not end up with the wrong client.

Work is underway in the OAuth 2.0 working group to define so-called "Proof of Possession" extensions of OAuth 2.0 that would allow a client to sign requests so that the receiver can verify that it is the right client presenting it. See also: http://www.thread-safe.com/2014/04/oauth-proof-of-possession-drafts.html

The current iteration of the OAuth 2.0 spec was kept as simple as possible with Bearer tokens only to make it very easy to write client implementations. If you control both client and Resource Server you may come up with your own custom mechanism for Proof of Possession, but there's no standard way of doing that right now.

Upvotes: 2

Related Questions