5 fundamental strategies for REST API authentication

Basic authentication

HTTP Basic authentication uses a Base64 format to encode usernames and passwords stored in the HTTP header. This is a practical approach for setting up various API access credentials while keeping the application lightweight and straightforward. However, it doesn't offer out-of-the-box support for multifactor authentication (MFA) or dynamic, user-specific credentials, which would require additional browser-based extensions and authorization tooling.

Basic authentication enjoys widespread support across development toolchains, technologies and platforms, thanks to its simplicity. One of the key challenges with this authentication scheme, however, is that sensitive credentials often travel between systems unencrypted. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) channels are essential when sharing sensitive data between multiple web applications -- especially third-party applications -- because threat actors can intercept traffic moving through unsecured channels and steal credentials.

API keys

The API keys approach is a variation of the HTTP Basic authentication strategy meant to provide authentication for the machines consuming REST APIs. It uses machine-generated strings to create unique pairs of identifying credentials and API access tokens. API keys can be sent as part of the payload, HTTP headers or query string, making them a good fit for consumer-facing web applications.

The benefit of API keys is that they decouple API access from the necessary credentials and validation tokens. It's possible to revoke and reissue credentials and tokens as needed, such as if a user's permission level changes or there is reason to believe the information has been compromised.

Unfortunately, API keys are susceptible to the same risks as Basic authentication: Hackers could intercept and exploit the associated credentials. While keys provide a unique identification mechanism for front-end user interactions that can both apply and revoke credentials on demand, the simplicity of this design inhibits their ability to support layered authentication or MFA.

HMAC encryption

A hash-based message authentication code (HMAC) is useful when the integrity of the REST API's data payload is a priority. HMAC uses symmetric encryption -- sometimes called single-key encryption -- to determine the hashing of a REST API's data payload. It then generates a unique code associated with that hashing and attaches it to relevant messages. The caller and receiver share the key and use it to ensure the integrity of the data within the payload.

Requiring little operational overhead regarding management or tooling, the HMAC approach to REST API authentication is effective when an individual can directly control both the client and server applications. However, it can become challenging to store encryption keys securely when dealing with mobile and web applications outside of an individual's control.

For example, a mobile application that uses URL-based HMAC encryption keys to facilitate data requests is a vulnerable target for attacks, especially if those encryption keys don't contain a fixed time frame for expiration. If a threat actor acquires that unique key, it can easily coerce the application to accept a malicious data payload simply by embedding the stolen encryption code within the URL.

OAuth 2.0

OAuth (specifically, OAuth 2.0) is considered a gold standard for REST API authentication, especially in enterprise scenarios involving sophisticated web and mobile applications. OAuth 2.0 can support dynamic collections of users, permission levels, scope parameters and data types. Organizations looking to secure large numbers of REST APIs that contain sensitive information might find this to be an optimal approach.

OAuth 2.0 creates secure access tokens that periodically refresh through a series of procedural verification protocols known as grant types. These grant types act as proxy authentication mechanisms and direct the flow of API access requests without exposing the underlying credentials, tokens and other associated authentication information.

The five major grant types in OAuth 2.0 are as follows:

• Authorization Code.
• Proof Key for Code Exchange (PKCE).
• Client Credentials.
• Device Code.
• Refresh Token.

In addition to recycling access keys, OAuth supports the concept of scopes, a method of limiting an application's access to a user's account and associated credentials. This helps control the degree to which third-party applications can access a user's account data. Another advantage is the ability to define multiple scopes and issue unique tokens for different requests and permission levels.

OAuth can perform payload integrity checks using a JSON Web Token (JWT). JWT tokens securely store encrypted, user-specific data and then transmit that data between applications as needed. Because an authenticating service can sign these web tokens, it's possible to imbue the token with new user roles and permissions once the user is authenticated. Tokens are typically invalidated using a time-based expiry mechanism.

Adding a shared symmetric key across application services can help all participating services verify the token's integrity concurrently rather than through a series of validation checks. This mitigates the risk of creating a single point of failure in the validation process. However, managing the distribution of symmetric keys required for payload integrity verification is a daunting security challenge in dynamic, highly scalable application environments.

OpenID Connect

OpenID Connect is an open-standard authentication protocol built on OAuth 2.0. It provides a simple way for a client application -- referred to as a relying party (RP) -- to validate a user's identity. This single standard facilitates information sharing without the need for explicit management of credentials for third-party applications.

REST APIs covered by OpenID Connect become usable once the RP authenticates users. Eventually, the API associated with that RP can perform validation using its variation of the OAuth grant types. These grant types are as follows:

• Authorization Code.
• Implicit.
• Hybrid.

While OpenID Connect always resides under the API provider's control, multiple RPs can use these grant types independently. REST API providers aiming to securely share user data across various third-party web applications might find this approach ideal, especially if they struggle with the complexities of dynamic, enterprise-level credential management tooling.

Additional REST API authentication strategies to consider

As online phishing, identity theft attempts and various cybersecurity threats advance in sophistication, other authentication methods for REST APIs continue to evolve and gradually gain traction with native device support.

Tokens (OTP or magic link)

One-time passwords (OTPs) and magic links provide passwordless authentication for REST APIs by sending a unique, short-lived credential through SMS, email or app notifications. However, these methods work slightly differently.

• OTPs. Relying on a shared secret key between a client and service provider, algorithms like time-based one-time passwords (TOTPs) and HMAC-based one-time passwords (HOTPs) generate temporary OTPs to enable verification between services. OTPs work well for high-security use cases with minimal user friction.
• Magic link. A magic link is a URL containing a time-bound code that the server verifies when the user clicks on the link. They are particularly effective for consumer apps where seamless authentication is preferred.

A token-based approach does not require the user to remember or enter a password, though it does necessitate switching between apps to log in. If the delivery mechanism fails, users can face login issues. And while tokens typically have a lower security risk than static passwords, token interception is possible. As a result, token security is only as good as the provider's security.

Passkeys

Preventing the transfer of secret data or passwords over a network, passkeys are a phishing-resistant authentication mechanism that relies on the WebAuthn standard, which is part of the FIDO2 framework. In this approach, the user device generates a secure and unique cryptographic key pair, where the device stores the private key and the service provider stores the public key.

Passkeys involve two levels of authentication. At login, the user device performs a local authentication through methods such as biometric or PIN-based authentication. Once authenticated, the device uses the private key to sign an automatic encryption challenge initiated by the service provider. The provider then verifies the signature using the public key and grants access. For REST API authentication, the challenge could create a token that authenticates and authorizes subsequent requests until the token expires and the process recurs.

As an evolving authentication option, not all platforms support passkeys. However, many industries, including financial services, rely on the inherent security they can provide. Passkeys are a strong choice when security and frictionless authentication are top priorities. Still, they require thoughtful fallback options for recovery as the approach is device-dependent, and a private key can be lost with a device.

Choosing a REST API authentication approach

Given the variety of REST API authentication approaches, carefully consider the pros and cons of each approach against an application's unique requirements before adoption. The HTTP-focused approach of Basic authentication is great for restricting public access to low-risk data and resources, but it still needs some security control. API keys, meanwhile, lend themselves to scenarios where API providers need to identify individual consumers and regulate their permissions as needed.

Data sensitivity is, of course, a significant part of the decision. While HMAC provides a fair degree of data payload integrity support for relatively contained operations, OAuth is a better fit for complex use cases that involve rotating access tokens and adjustable permission levels. For those who reside in the middle, OpenID provides a nice balance between OAuth's dynamic access management and the simplicity of HMAC. Existing authentication strategies can often be coupled with tokens or passkeys to establish identity more reliably and securely.

No matter the approach, limiting REST API exposure to secured SSL and TLS channels is always a good idea. Avoid transmitting sensitive credentials as embedded parts of API data payloads, URLs or query strings, as applications might inadvertently store copies of these credentials through automated logging procedures. Finally, use a hardened secret management system and automate procedures such as encryption key rotations, as a manual approach might result in repetitive oversights and errors.

Priyank Gupta is a polyglot technologist who is well-versed in the craft of building distributed systems that operate at scale. He is an active open source contributor and speaker who loves to solve a difficult business challenge using technology at scale.