Return to Revisions

If you use Authorization, be consistent

Some will argue that the following is unnecessary (and not too long ago I would have agreed with them) but, these days, if we use the Authorization header we should inform the type of the token, because API keys are not self-descriptive per se ¹.

Why do I think it's necessary and why I do think it's important? Because nowadays supporting different authentication/authorization protocols has become a must-have. If we plan to use the Authorization header for all these protocols, we have to make our auth service consistent. The way to communicate what kind of token we send and what authorization protocol should be applied should go in the header too.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

I used to don't care about this, but after working with app client apps whose updates were not guaranteed (mobiles and sensors mostly), I started to. I started to be more cautious in the way I implement security so that I can expand it without messing with clients and without too much pain on the server side.

Concerns

The problems I faced implementing my own schemes has been similar to the one commented.

On the other hand, I found a consideration that a custom Authorization scheme can be unexpected and unsupported by some clients and leads to custom code anyway

Say clients, say libraries, frameworks, reverse proxies.

Advantages

One important advantage is cache. Shared caches won't cache the header (and that's good of course) unless you say otherwise.

So Authorization or custom header?

To my experience, implementing my own Authorization scheme has taken me the very same amount of work (or more) than implementing custom authorization headers, with the slight difference of having more freedom of design and more control over the cache when I have used custom headers. The reason is rather stupid, most of the time I have the Cache-control set to no-cache or no-store, allowing me to make the calls to the server more deterministic (this is important when it comes to tracking and testing) regardless the topology of the network.

^{1: I find this answer to be very clear regarding API Keys}