Security with API: OAuth, token-based access vs key-based accessSolution ·
Let’s consider security with APIs, i.e how to securely identify the caller.
There are two authentication methods quite popular in the cloud to secure APIs:
- Key-based access
- OAuth, or token-based access in general
Let’s compare them.
By key-based we mean an authentication scheme where we do pass a key to the API request.
That could be in the query string or HTTP header.
Example of key-based authentication in Azure (non exhaustive list):
OAuth / Token-based access
By OAuth we mean OAuth. In general for token-based we mean an authentication mechanism where credentials / secrets are passed to an identity / token-provider which returns a token then pass to relying party / APIs:
Example of OAuth-based authentication in Azure (non exhaustive list):
- Azure Active Directory (as an identity provider)
- Data Lake Storage (ADLS) REST API
- Azure Management REST API
Pros & Cons
Instead of giving a nice & neatly formatted pros & cons table where all the pros have a corresponding cons, let’s just discuss the major aspects: security & complexity.
Basically, in general, OAuth is more secure but more complex for both clients (i.e. consumer) and services.
Why is OAuth more secure? Relying parties never see credentials & secrets in an OAuth authentication scheme. They see a token. Token are revoked after a while ; often minutes, maximum a few hours.
By opposition, keys are passed directly to the relying parties. If they are passed in query strings, they’ll actually be audited. So it’s much easier for keys to be stolen. Each API we implement must handle keys and we must make sure that we handle them properly. We spread the attack surface around.
Also, typically, keys aren’t numerous. Azure Blob Storage have a primary & secondary key. We can revoke them but that’s about it. If more than 2 consumers are using the same account, they need to share the same key. It gets harder to audit which consumer is using the service.
By opposition OAuth relies on one party handling secrets: the identity provider. Typically those are specialized in doing so. For instance, Azure AD an identity provider and its secret handling has been harden. Also identity provider typically allow for multiple users / service users / service principles so it’s easier to audit consumers.
On the flip side, we mentioned complexity. It’s quite easy to see that OAuth is more complicated. Instead of invoking an API directly, we first need to obtain a token, then we pass this token. That’s on the consumer side. On the service side, we need to take this token and validate it. This often require cryptographic operation which gives headache to the average software engineer.
That complexity can be mitigated by the platform. For instance, Azure App Service can completely handle the validation task.
Authentication is a key design aspect of an API.
OAuth should be favoured for its security advantages but keys have a much lower entry point.
It is of course possible to support both, allowing consumers to start with keys to “kick the tyres” and upgrade to OAuth for more serious work.