API authorization methods

Introduction

In today's world, APIs are the backbone of modern applications. They are the primary way to access data and functionality from backend services. APIs allow different software systems from different parties to communicate and share data with each other, making them indispensable for businesses. However, APIs are also a common target for attackers. The need for API protection is more stronger than before.

API protection is the process of securing APIs from unauthorized access, misuse, and attacks. It is a critical component of any API strategy. In this article, we will explore three common API protection mechanisms: API keys, basic authentication, and OAuth JWT tokens. In the end, we will also show how Logto protect your APIs using the OAuth JWT tokens.

API Keys

API key is the the most straightforward and widely used method to secure APIs. An API key is a long string of characters generated by the API provider and shared with authorized users. This key must be included in the request header when accessing the API. API keys are simple and effective for basic security needs. For example, popular services like Google Maps API and AWS provide API keys to control access and monitor usage. However, they have limitations in terms of security. They are often used for machine-to-machine communication.

e.g.

curl -GET https://api.example.com/endpoint -H "Authorization: api-key YOUR_API_KEY"

Pros:

• Simple to implement: API keys are easy to implement and use. They involve attaching a key to the request header, making it a straightforward method for developers and clients to understand and employ.
• Easy to monitor: API keys are easy to monitor. You can track the usage of each key and revoke them if necessary.
• Effective rate limiting: API keys are effective for rate limiting. You can set a limit on the number of requests per key to prevent abuse.
• Suitable for non-sensitive data: API keys are suitable for non-sensitive data or publicly available APIs, where security requirements are lower.

Cons:

• Limited security: API keys are not secure enough for sensitive data, especially for client-side applications. They are often used in machine-to-machine communications.
• Not suitable for User Authentication: API keys are tied to applications or systems, not individual users, making it challenging to identify specific users or track their actions.
• No token expiry: API keys are typically static and don't expire. If a key is compromised, it could be misused indefinitely unless manually regenerated.

Basic authentication

Basic authentication is another common method to secure APIs. It is a simple authentication scheme built into the HTTPs protocol. It involves sending a username and password in the request header. The server then verifies the credentials and returns the requested resource if they are valid. For instance, many web applications and RESTful APIs use basic authentication as a quick and easy way to authenticate users.Basic authentication is more secure than API keys because it uses a username and password instead of a static key. However, it is still not secure enough for sensitive data. As the client credentials are transmitted in plain text,the are susceptible to interception. Basic authentication is suitable for internal systems where the network connection is secure e.g. machine-to-machine.

e.g.

curl -u USERNAME:PASSWORD https://api.example.com/endpoint

or

curl -H "Authorization: Basic $(echo -n 'USERNAME:PASSWORD' | base64)" https://api.example.com/endpoint

Pros:

• Stronger security: Basic authentication is more secure than API keys because it uses a username and password instead of a static key.
• Widely supported: Basic authentication is widely adopted and supported by most web servers and browsers.
• Simplicity: Like API keys, basic authentication is relatively simple to set up and use.

Cons:

• Credential exposure: Basic authentication sends credentials in plain text, making them susceptible to interception if not used over a secure connection (HTTPS).
• No token expiry: Basic authentication does not support token expiry. If a token is compromised, it could be misused indefinitely unless manually regenerated.

OAuth JWT tokens

JSON Web Token (JWT), defined by RFC 7519, is an open standard for securely transmitting information between parties as a JSON object. It is commonly used for authentication and authorization in web applications and APIs.

A signed JWT has the following format:

[header].[payload].[signature]

It consists of three parts separated by .: the header, payload, and signature.

Here is an example of a JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• header: contains information about the type of token and the hashing algorithm used to sign it.
• payload: contains the claims (statements) about the user and other data.
• signature: is a hash of the header and payload, signed with a secret key.

OAuth is a comprehensive open standard for securing APIs. and for access delegation, commonly used as a way for client users to grant websites or applications access to their information on other websites without giving them the passwords.

When used together with JWT, OAuth JWT tokens offer a robust security solution. Instead of transmitting sensitive information like usernames and passwords with each request, OAuth JWT tokens are issued to authorized clients upon successful authentication. These tokens contain information about the user and their permissions. In addition JWT tokens are digitally signed for tamper-proofing, and can expire. That provides an extra layer of security.

One of the key benefits of OAuth JWT tokens is their flexibility. They can be used for various types of applications, including web and mobile apps, single sign-on solutions, and more. For example, major social media platforms like Facebook, Twitter, and LinkedIn use OAuth JWT tokens to authenticate users and enable third-party applications to access user data securely.

Pros:

• Enhanced security: OAuth JWT tokens provide a higher level of security. They are digitally signed and can be encrypted, reducing the risk of unauthorized access and data tampering.
• User identity and access control: JWT tokens can carry user identity information and include claims that specify which actions or resources a user is authorized to access.0
• Fine-grained access control: JWT tokens can be used to implement fine-grained access control. For example, you can specify what resources a user can access and what actions they can perform on those resources.
• Token expiry: OAuth JWT tokens can be set to expire after a certain period of time, reducing the risk of misuse.

Cons:

• Complexity: OAuth JWT tokens are more complex than API keys and basic authentication. They require additional steps to set up and use.
• Token management: OAuth JWT tokens need to be managed and revoked if necessary. This can be challenging for large-scale applications with many users and clients.
• Resource consumption: Generating and validating tokens can have some performance overhead, which may be a concern in high-traffic scenarios.

Logto API protection

The choice of authentication method depends on the specific requirements and security considerations of your application. API keys are simple but less secure, basic authentication offers more security but lacks user identity features, while OAuth JWT tokens provide robust security and user identity capabilities but increase the complexity in implementation and management.

Logto provides a simple and secure way to protect your API using OAuth JWT tokens. It supports both OAuth 2.0 and OpenID Connect (OIDC) standards, allowing you to choose the authentication method that best suits your needs. You can use client_credentials flow for machine-to-machine communication and authorization_code flow for web applications.

Machine-to-machine communication

Logto uses the client_credentials flow for the machine-to-machine type applications. This flow is suitable for backend server communication, where the client is a confidential client that can securely store the client credentials. It is also known as the "two-legged OAuth" because it does not involve a user. The client credentials are used directly as an authorization grant to obtain an access token.

The integration flow is simple and straightforward:

1. Create an API resource in Logto Console.
2. Create a machine-to-machine client in Logto Console.
3. Send a request to Logto token endpoint to obtain an access token.

curl --location \
  --request POST 'https://your.logto.endpoint/oidc/token' \
  --header 'Authorization: Basic eW91ci1hcHAtaWQ6eW91ci1hcHAtc2VjcmV0' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'resource=https://shopping.api' \
  --data-urlencode 'scope=scope_1 scope_2'

4. Access the protected resource with the access token.

curl --location \
  --request GET 'https://api.example.com/endpoint' \
  --header 'Authorization: Bearer eyJhbG...2g' # Access Token

Please check our machine-to-machine integration documentation for more details.

Web applications

For public clients like web applications, Logto uses the authorization_code flow to authenticate users. This flow is suitable for web applications where the client is a public client that cannot securely store the client credentials. It is also known as the "three-legged OAuth" because it involves a user. The user is redirected to the authorization server to authenticate and authorize the client. The client then uses the authorization code to obtain an access token.

The integration flow is slightly more complicated than the machine-to-machine flow:

Please checkout our Protect your Express.js API with JWT and Logto article as a comprehensive example of how to integrate Logto with React and access your Express server APIs using JWT tokens.