Basic authentication
- HTTP-based authentication approach. It uses a Base64 format to encode usernames and passwords, both of which are stored in the HTTP header. this approach doesn't offer out-of-the-box support for multifactor authentication (MFA) or dynamic, user-specific credentials. however, is that sensitive credentials often travel between systems unencrypted Hence, using Secure Sockets Layer (SSL) and Transport Layer Security (TLS) channels is a must 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
- is a variation of the HTTP Basic authentication strategy. This approach 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. Those credentials and tokens can be revoked and reissued 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. While they do provide a unique identification mechanism for front-end user interactions that can both apply and revoke credentials on demand, the simplicity of its design inhibits its ability to support layered authentication or MFA.
HMAC encryption
- known as hash-based message authentication code (HMAC) is often used 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 that code to the relevant messages. The caller and receiver will share the key and use it to ensure the integrity of the data within the payload.
he HMAC approach to REST API authentication requires little operational overhead in terms of management or tooling. It's useful in scenarios when you can directly control both the client and server applications involved. However, it can become challenging to store encryption keys securely when dealing with mobile and web applications that are outside of your control.
OAuth 2.0
OAuth (specifically, OAuth 2.0) is considered a gold standard when it comes to 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. It's a preferred approach for organizations looking to secure large numbers of REST APIs that contain sensitive information.
OAuth 2.0 creates secured access tokens that are refreshed periodically using a series of procedural verification protocols known as grant types. These grant types act as proxy authentication mechanisms that direct the flow of API access requests without exposing the underlying credentials, tokens and other authentication information associated with those requests.
The five major grant types in OAuth 2.0 are:
Authorization Code Proof Key for Code Exchange (PKCE) Client Credentials Device Code Refresh Token
OpenID Connect
OpenID Connect is an open standard authentication protocol built on top of 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 users have been authenticated by the RP. Eventually, the API associated with that RP can perform validation using its own variation of the OAuth grant types mentioned above. These grant types are:
Authorization Code Implicit Hybrid
Choosing a REST API authentication approach
No matter the approach, it's always a good idea to limit REST API exposure to secured SSL and TLS channels. Avoid transmitting sensitive credentials as embedded parts of API data payloads, URLs or querystrings, as applications may inadvertently store copies of these credentials through automated logging procedures. Finally, automate procedures such as encryption key rotations, as a manual approach may result in repetitive oversights and errors.