How would replacing Bearer tokens with HMAC work in OAuth 2.0, and how would the client/server validate?

Question

This Pluralsight class discusses Bearer tokens, and that one of the things missing from OAuth 2.0 is HMAC based validation. Elsewhere on the thinktecture blogs, they are called PoP tokens (Proof of Possession)

HMAC based validation would prevent the CSRF based attacks where exchanging the bearer token would result in an impersonation.

What confused me was that in one of the slides regarding OAuth 2.0 risks, Dominic Baier discussed that this validation would occur on the client.

HMAC based validation was never added to the OAuth specification, and its omission was a key reason Eran Hammer (original author of OAuth) decided to remove his name from the specification.

Diving into this deeper, I'm a little confused on how HMAC tokens in OAuth would be:

1. Constructed in either code or implicit flows
2. How would the client validate these HMAC tokens? Should I assume this is only regarding SPA applications?
3. Does the JWT construction in OpenID Connect resolve all the HMAC concerns in OAuth 2.0?

Answer 1

Whatever the flow, the MAC token would be generated the same: a symmetric secret key and an id is sent to the client once. This secret is never sent over the wire again.

The client doesn't validate the token^*, the client uses it as it would use a bearer token, except that the secret is not sent over the wire and thus can't be leaked:

  +--------------+                                        +--------------+
  |              |>------Request with authenticator------>|              |
  |              |                                        |   Resource   |
  |    Client    |                                        |    server    |
  |              |<--------Requested resource------------<|              |
  |              |                                        +--------------+
  +--------------+                                                ^
         ^                                                        |
         |                                                        |
         |                                                        |
         |                                                        |
         |                                                 MAC algorithm  
   MAC algorithm                                           over key+params
   over key+params

The client constructs the authenticator calculating a MAC using the secret key and some parameters (that includes the token ID, a nonce, a timestamp and some other data), and attaches that to the request.

The resource server (or a third server the RS uses to validate tokens) knows this secret key, so it performs the same calculations as the client did using the same params. If everything matches it proceeds with the request.

The server is also tasked with preventing replay attacks by checking the timestamp and preventing nonce-reuse.

This protects agains many scenarios in which the token could be leaked: TLS misconfiguration/bug, attacker controlled endpoints finding their way into the client's database, etc.

Regarding your 3rd question, yes and no. The OAuth2 MAC spec draft defines a few claims for JWT to encode the information required for the emission and use of MAC tokens using JWT, but OpenID Connect is still using bearer tokens.

The main concern with bearer tokens is that the client's developer has to be very security-aware, and that its security depends exclusively on TLS.

A lot of people misunderstand this last statement and conclude that OAuth2 is inherently insecure and useless and doomed. Even worse, they blindly repeat this kind of conclussions in talks and posts and comments and simply confuse people.

OAuth2 is very good for some use cases and sucks for others. It requires a good understanding of some security principles. It requires some compromises as well. But it's out there, it's working and it solves a very hard problem.

The use of MACs was never standarized, but the draft is pretty good and easily implementable. Today there are several alternatives as well.

---

_{(*): I mean the client doesn't perform MAC validation. Of course, audience and other fields should still be validated.}

Answer 2

The OAuth WG is developing a great security extension which allows access tokens to be bound a client X.509 certificate. Relatively simple to implement with clients and resource servers, and it also works with public clients: https://tools.ietf.org/html/draft-ietf-oauth-mtls-03