OAuth 2.0 Bearer-Tokens vs. Mac-Tokens. Why not using Mac-Tokens?

Question

I searched for other questions in this topic but i found not an answer to exatly this. So tell me if i'm wrong. I'm new in this topic and you can correct me with pleasure. Here is what i think at the actual moment:

I surfed arround the web for 2 days now, figuring out what is the actual state of the art to authorize a webrequest. Now what i figured out quickly is that OAuth 2.0 seems to be the most common standard. But OAuth 2.0 itself is everything other than standardized. Out of my sight it's a mess of different customizations for every greater company. But anyway there are two techniques to exchange authorization information: Mac-Tokens and Bearer-Tokens.

In my opinion Mac-Tokens offer way more security. So why is it not widely implemented? The only reason i could find is because its a little bit more complicated. And i heard say several times that Mac-Tokens are not recommended, if the client is not 100% trusted, because the client has to store the secret. But where is the difference? The client has to store a Authorazation-Information anyway. In my opinion it doesn't matter wheter its a bearer-token or a mac-secret. But what makes a difference is that the mac-secret (rather than the bearer-token) is not submitted over the wire on every request.

So can you tell me a sane reason why not using mac-tokens? (apart of having a litte more effort) Am i missing something? Or have i missunderstood the two token techniques.

Thanks for reading and your help.

Answer 1

The danger is that if the client proceeds without insisting on the SSL/TLS certificate being valid - which is a step that many clients fail to take - then the bearer token is susceptible to a man in the middle attack.

The Mac token is not susceptible to this attack; it may be correct to say that the Mac token provides some authenticity in the absence of SSL/TLS, or indeed when it is not being used correctly.

The Mac token strengthens a known weakness of the Bearer token.

A client should not be trusted with a MAC key that is shared. A new key should be generated for each client. It is no more of a security risk to trust each client with its own key, than it is to trust them with bearer tokens.

I think the problem comes when exchanging the Auhtorization Grant for the Access Token. For the Mac key, this returns a symmetric secret key. If the client is sloppy about checking SSL/TLS certificates, then this too is susceptible to a MITM attack.

In short, the Mac token may be less favoured because it is more complicated but you still need to do SSL/TLS right to make it secure, and if you do that then the Bearer token will also be secure.

Answer 2

In my opinion, the answer may be simple: Bearer token mechanism assumes existence of SSL/TLS layer, whereas MAC token tries to replace that. Since SSL/TLS is widely accepted and used, why doing things more complicated than needed?

Yes, as it was recently seen with the heartbleed vulnerability, many things are not really as reliable as expected, but who guarantees that MAC implementation is free of glitches as well?

Another point is, as you mentioned, exchange of symmetric secrets. In absence of absolutely reliable secondary channel it may be tricky. And trusting a client may also be an issue.