2016/01/30

Bearer v MAC

I've been struggling recently to get my head around OAuth2 access tokens - bearer and MAC tokens specifically...

Bearer tokens are essentially just static tokens valid for some predefined period before they need to be refreshed. They can essentially be passed around willy-nilly and will be accepted by a resource server so long as they can be validated. If a 3rd party manages to hijack one then they can use it to perform whatever the token is authorised to do just by submitting it in the correct manner. Consequently these tokens need to be looked after carefully. Shuffled over encrypted channels and protected by the client. They're arguably even less secure than session cookies since there's no "HTTP Only" option on an access token so preventing malicious access to tokens from dodgy code on clients is something the developer needs to manage. And given the number of clients around and quality of code out there we can pretty much assume a good chunk will be piss poor at this.

So Bearer tokens. Not so great.

MAC tokens aren't just static strings. A client secret and nonce is combined with some request data to essentially sign tokens. So if you hijack a request in flight you can't replay the token - it's valid only for the original request. This is good but really only protects against snooping over the wire which SSL/TLS does a pretty good job of managing without all the additional complexity. Beyond this a MAC token seems to make very little difference. The client needs to know the secret in the same way it would need a Bearer token. If someone manages to snatch this we're done for regardless and the false sense of security MAC tokens give isn't worth a damn.

The client application is often the weak point in OAuth since it's often an untrusted device - mobile phones and web-browsers (single page applications) etc. If the "client" is a downstream server (and this poor terminology by the way has caused way too much confusion and argument) then we've a reasonable chance to secure the server and data but ultimately we're still going to have a client ID and secret stuffed in memory just like we would have with a Bearer token. Ok, so we're adding some hoops to jump through but really it's no more secure.

So if we don't have transport level encryption (SSL/TLS) then MAC tokens offer some reasonable value over Bearer tokens. But if we do have transport encryption then MACs just add complexity and a false sense of security. Which I'd argue is a bad thing since increased complexity is likely to lead to increased defects... which in security is a very bad thing!

Besides, neither option allows me to identify the user or ensure the client calling the service is authorised to do so... Just that they appear to be in possession of a token saying the user has granted them authority (which may have been hijacked as per above).

p.s. One of my many failed new years resolutions was to post a new article every week of the year. This being the first four weeks in isn't a good start...

Voyaging dwarves riding phantom eagles

It's been said before... the only two difficult things in computing are naming things and cache invalidation... or naming things and som...