Modern applications rely heavily on APIs to exchange data between services, mobile apps, and third-party integrations. Because APIs often expose sensitive data and business logic, authentication becomes the first line of defence.

This article explores the core principles of API authentication, common authentication methods, and the standards used to securely verify API requests.

Authentication vs Authorisation

These two terms are often confused but represent different stages of access control.

Authentication answers the question:

Who is making this request?

It verifies the identity of the user or system interacting with the API.

Authorisation answers a different question:

What is this entity allowed to do?

Authorisation determines whether the authenticated identity has permission to perform a specific action.

Authentication Methods for APIs

APIs support several authentication mechanisms, each with different security characteristics.

Method	Identity Type	Description
Basic Authentication	User / Machine	Uses Base64 encoded username and password. Considered insecure and largely discouraged.
API Keys	Machine	A simple token used to identify applications. Often used for rate limiting rather than security.
Mutual TLS (mTLS)	Machine	Uses client certificates to authenticate machines. Highly secure but complex to manage.
Token-Based Authentication	User + Machine	Uses signed tokens issued by an authorization server. Most common in modern APIs.

Among these, token-based authentication has become the dominant approach for modern distributed systems.

Token-Based Authentication

Token-based authentication allows APIs to trust requests without repeatedly verifying credentials.

Instead of sending passwords with every request:

1. A client authenticates with an authorisation server.

2. The server issues a token.

3. The client sends that token when calling APIs.

Tokens can include important properties such as:

• Expiration times

• Audiences (to whom the token is meant)

• Scopes and claims (permissions and identity attributes)

However, an important concept must be understood:

A valid token does not automatically grant access.

The API still needs to verify that the token has the required permissions.

OAuth and OpenID Connect

Most modern APIs rely on OAuth-based authentication frameworks.

OAuth provides a standardised way for applications to obtain tokens.

Protocol	Purpose	Notes
OAuth 2.0	Delegated access to APIs	Current industry standard
OpenID Connect	Adds identity to OAuth	Provides ID tokens for authentication
OAuth 1.0	Legacy protocol	Rarely used today
OAuth 2.1	Updated OAuth specification	Simplifies and improves OAuth 2.0

OAuth is often misunderstood as an authentication protocol. In reality, it is primarily a delegation framework.

OAuth Is All About Delegation

OAuth allows a user to grant a third-party application limited access to their resources without sharing credentials.

Instead of giving an application your password, OAuth allows you to delegate permission.

Example scenario:

1. A user stores files in a cloud service.

2. The user wants a third-party app to access those files.

3. OAuth allows the user to grant limited access to that app.

The key actors in OAuth are:

• Resource Owner – the user who owns the data

• Client – the application requesting access

• Resource Server – the API hosting the data

• Authorisation Server – the service issuing tokens

The authorisation server verifies the user and issues tokens to the client.

Common OAuth Flows

OAuth defines different flows for different types of applications.

Authorisation Code Flow (with PKCE)

This is the most widely used OAuth flow.

Best suited for:

• Web applications

• Mobile applications

• Applications involving user login

High-level process:

1. User is redirected to the authorisation server.

2. User authenticates.

3. The authorisation server returns a code.

4. Client exchanges the code for an access token.

5. The client calls APIs using that token.

PKCE adds an extra security layer to prevent authorisation code interception.

Refresh Token Flow

Access tokens are usually short-lived. To avoid forcing users to log in again, applications can use a refresh token to request a new access token.

This allows long-lived sessions while maintaining security.

Client Credentials Flow

Used when no user is involved.

Typical use cases include:

• Microservices communication

• Backend automation

• Scheduled jobs

In this flow:

1. A service authenticates using client credentials.

2. It receives an access token.

3. It uses that token to call APIs.

Scopes and Claims

Tokens usually contain two types of information.

Scopes – What the application can do

Scopes define the permissions granted to the client application.

Examples:

• invoice.read

• invoice.write

• video.stream

Scopes provide coarse-grained access control.

Claims – Information about the user

Claims contain identity attributes.

Examples:

• sub (user ID)

• email

• subscription_level

• subscriber_id

Claims enable fine-grained authorization decisions inside APIs.

Example:

A token may allow reading invoices (invoice.read), but the API must still verify that the invoice actually belongs to the requesting user.

Tokens and Their Types

Tokens can be categorised in several ways.

By Purpose

Token	Purpose
Access Token	Used when calling APIs
Refresh Token	Used to obtain new access tokens
ID Token	Contains user identity information

By Format

Self-contained tokens

These contain all the information inside the token itself.

Examples:

• JWT

• SAML

These can be validated without contacting the authorisation server.

Reference tokens

These are opaque tokens containing no visible data.

APIs must call the authorisation server to retrieve token information.

This approach improves privacy and control.

JSON Web Tokens (JWT)

JWT is one of the most common token formats used in APIs.

A JWT contains three parts: Header.Payload.Signature

• Header – metadata about the token

• Payload – claims and identity data

• Signature – verifies integrity

JWT validation must include:

• Signature verification

• Expiration checks

• Issuer validation

• Audience validation

Developers must also explicitly whitelist supported algorithms and never accept alg: none.

Key Takeaways

Modern API authentication relies heavily on:

• OAuth for delegation

• Token-based authentication

• JWTs for identity and permissions

• Scopes and claims for access control

Authentication is only the first step. Once identity is verified, APIs must still enforce strict authorisation policies.

In Part 2, we will explore how APIs validate tokens, how API gateways enforce security, and how modern architectures use JWT validation, token introspection, and secure service-to-service communication.