OAuth 2.0 Client Credentials Flow

The Client Credentials Flow is an OAuth 2.0 grant type designed for machine-to-machine (M2M) authentication — scenarios where there is no end-user involved. The client application authenticates directly with the LoginRadius Token endpoint using its own credentials (client_id and client_secret) and receives an access_token scoped to the application itself.

This flow is commonly used for backend services, daemons, scheduled jobs, and API integrations that need to call protected resources on their own behalf.

Note: The Client Credentials Flow does not issue an id_token or refresh_token. It is not an end-user authentication flow and cannot be used to identify or authenticate a human user. For user-facing authentication, use the Authorization Code Flow or PKCE Flow.

Overview

The flow operates in a single phase — there is no browser redirect, no login UI, and no user interaction:

Token Request Phase — runs entirely server-side (back-channel). The client application makes a direct POST request to the LoginRadius Token endpoint, authenticating with its client_id and client_secret. LoginRadius validates the credentials and returns an access_token.

Use Cases

The Client Credentials Flow covers any scenario where a backend service or automated process needs to authenticate and call a protected API without user involvement. The three primary use cases on the LoginRadius platform are:

LoginRadius Account Management

Use the Account Management audience to issue an M2M token authorized to call the LoginRadius Identity Management APIs. This is suited for backend jobs that provision, update, or delete user records — for example, a user migration pipeline, a nightly deactivation job for inactive accounts, or an internal admin tool that manages identity data on behalf of your operations team.

Audience: https://api.loginradius.com/identity/v2/manage
Token authorizes: CRUD operations on customer identity records via the LoginRadius Identity APIs

LoginRadius Config Management

Use the Config Management audience to issue an M2M token authorized to call the LoginRadius Configuration APIs. This is suited for infrastructure-as-code pipelines, CI/CD workflows, or automated deployment scripts that need to read or update tenant-level settings — security policies, email templates, social provider configuration, and similar platform config — without manual Admin Console access.

Audience: https://api.loginradius.com/v2/manage
Token authorizes: Read and write access to LoginRadius tenant configuration via the Config APIs

Custom API Authorization

Use a custom API identifier registered in the Admin Console to issue an M2M token for authorizing service-to-service calls within your own infrastructure. This is suited for microservice architectures where one backend service needs to call another — for example, an order service calling a billing service, or a data pipeline calling an internal reporting API — and you want to centralize token issuance and authorization through LoginRadius rather than managing a separate auth layer.

Audience: Your registered API identifier (e.g. https://api.your-app.com/billing)
Token authorizes: Scoped access to your API based on the scopes registered and requested at token issuance

How to Configure

Before using the Client Credentials Flow, you must create and configure an OIDC application in the LoginRadius Admin Console.

Step 1 — Create a New Application

Navigate to Admin Console → Application and click Create New App. Provide a name for the application and proceed to the configuration tabs.

Step 2 — Enable the Client Credentials Grant Type

On the application settings, locate the Grant Type options and select Client Credentials.

Only the client_credentials grant type is required for M2M flows. Do not enable user-facing grant types (Authorization Code, Implicit) on the same application unless explicitly required.

Once saved, the Admin Console will display the client_id and client_secret for this application. Store the client_secret securely — it will not be shown again.

Step 3 — Configure API Audiences and Scopes

Navigate to the API tab within the application configuration. This tab controls which audiences the application is permitted to request tokens for, and which scopes are included in the issued token for each audience.

Field	Description
API Audience	Select the audience(s) this application is authorized to request tokens for. Options include the LoginRadius prebuilt audiences (Account Management, Config Management) and any custom APIs you have registered under Admin Console → Authorization → API.
Allowed Scopes	For each selected audience, choose the scopes to include in the issued `access_token`. The `scope` claim in the token will reflect exactly what is configured here — scopes are not passed in the token request.

Scopes are determined at the application configuration level, not at token request time. The issued access_token will contain the scopes configured for the matching audience on this application.

Flow Diagram

Step-by-Step Walkthrough

Step 1 — Token Request

The client application makes a direct POST call to the LoginRadius Token endpoint. No user redirect or browser interaction is involved.

Endpoint

POST https://{SiteURL}/api/oidc/{OIDCAppName}/token

SiteURL = Either <TenantName>.hub.loginradius.com or CustomDomain i.e. auth.your-app.com · OIDCAppName = your configured OIDC App name

The token endpoint accepts application/x-www-form-urlencoded as the content type. The client_id and client_secret can be passed using either of the two authentication methods below.

Client Secret Basic
Client Secret Post

The client_id and client_secret are passed as a Base64-encoded Authorization header (Basic Base64(client_id:client_secret)). They must not be included in the request body.

POST /api/oidc/{OIDCAppName}/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Base64(YOUR_OIDC_CLIENT_ID:YOUR_OIDC_CLIENT_SECRET)

grant_type=client_credentials
&audience=https://api.loginradius.com/identity/v2/manage

The client_id and client_secret are included directly in the request body.

POST /api/oidc/{OIDCAppName}/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_OIDC_CLIENT_ID
&client_secret=YOUR_OIDC_CLIENT_SECRET
&audience=https://api.loginradius.com/identity/v2/manage

Step 2 — Token Validation

LoginRadius validates the incoming request:

Verifies client_id and client_secret against the registered OIDC application.
Confirms the client is authorized to use the client_credentials grant type.
Confirms the requested audience is permitted for this application (if provided).

The scopes included in the issued access_token are determined by what is configured on the OIDC application in the Admin Console — not by the token request itself.

If validation fails, an error response is returned immediately (see Error Handling).

Step 3 — Access Token Issuance

On successful validation, LoginRadius returns an access_token scoped to the client application.

Success Response

{
  "access_token": "<LoginRadius JWT Access Token>",
  "token_type": "Bearer",
  "expires_in": 3600
}

No id_token or refresh_token is issued. When the access_token expires, the client must request a new one using the same Client Credentials grant.

Step 4 — Calling a Protected Resource

The client uses the access_token as a Bearer token in the Authorization header when calling downstream protected APIs or resources.

GET /api/some-protected-resource
Authorization: Bearer <access_token>

Token Request Parameters

Parameter	Required	Description
`client_id`	✅ Required	Your OIDC application `client_id`
`client_secret`	✅ Required	Your OIDC application `client_secret`. Pass via `Authorization` header when using `client_secret_basic`.
`grant_type`	✅ Required	Must be `client_credentials`
`audience`	Optional	The intended recipient of the issued `access_token`. Sets the `aud` claim in the JWT. Accepts a LoginRadius prebuilt audience URI or a custom API identifier registered in the Admin Console — see Audiences below.

Audiences

The audience value in the token request determines the aud claim in the issued JWT and controls which API the token is authorized to call. LoginRadius supports two categories of audience.

Prebuilt Audiences

LoginRadius exposes two prebuilt audience values for accessing LoginRadius-managed API surfaces directly.

Audience	Identifier	Purpose
Account Management	`https://api.loginradius.com/identity/v2/manage`	Token authorized to call the Identity Management APIs — create, read, update, and delete customer identity records.
Config Management	`https://api.loginradius.com/v2/manage`	Token authorized to call the Configuration Management APIs — app settings, security policies, workflows, and tenant-level configuration.

For the full list of available scopes per audience, see Prebuilt Audience Scopes.

Example — Account Management token

POST /api/oidc/{OIDCAppName}/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Base64(YOUR_OIDC_CLIENT_ID:YOUR_OIDC_CLIENT_SECRET)

grant_type=client_credentials
&audience=https://api.loginradius.com/identity/v2/manage

Example — Config Management token

POST /api/oidc/{OIDCAppName}/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Base64(YOUR_OIDC_CLIENT_ID:YOUR_OIDC_CLIENT_SECRET)

grant_type=client_credentials
&audience=https://api.loginradius.com/v2/manage

Custom API Audiences

In addition to the prebuilt audiences, you can register your own APIs with LoginRadius and use the Client Credentials Flow to issue M2M tokens for authorizing requests to those APIs.

Registering a Custom API

Navigate to Admin Console → Authorization → API and create a new API entry with the following fields:

Field	Description
Name	A human-readable label for the API (e.g. `Billing Service`)
Identifier	The audience URI for this API (e.g. `https://api.your-app.com/billing`). This is the value passed as `audience` in the token request. Must be a unique URI — it does not need to be a reachable URL.
Scopes	The list of permission scopes this API exposes (e.g. `read:invoices`, `write:invoices`). Scopes defined here are the only values accepted for this audience in the token request.

Requesting a Token for a Custom API

Once the API is registered, pass its Identifier as the audience in the token request. The scopes granted in the token are determined by what is configured on the OIDC application for that audience in the Admin Console.

POST /api/oidc/{OIDCAppName}/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Base64(YOUR_OIDC_CLIENT_ID:YOUR_OIDC_CLIENT_SECRET)

grant_type=client_credentials
&audience=https://api.your-app.com/billing

LoginRadius validates that the audience matches a registered API identifier. On success, an access_token is issued with the aud claim set to the registered identifier and the scope claim populated with the scopes configured for this application in the Admin Console.

Using the Token to Authorize Requests

The issued access_token is a signed JWT. Your API must validate it on every inbound request:

Verify the JWT signature using the LoginRadius JWKS endpoint.
Confirm the aud claim matches your registered API identifier.
Confirm the scope claim includes the permission required for the requested operation.
Confirm the token has not expired (exp claim).

GET /billing/invoices
Authorization: Bearer <access_token>

Tokens are audience-scoped. A token issued for one audience cannot be used against a different API surface — prebuilt or custom. Request a separate token per audience.

Token Response Fields

Field	Description
`access_token`	LoginRadius JWT — use this to call protected APIs
`token_type`	Always `Bearer`
`expires_in`	Lifetime of the access token in seconds

id_token and refresh_token are not returned in the Client Credentials Flow.

Error Handling

All errors are returned as a JSON body with an HTTP 400 status code.

Error Response Format

{
  "error": "ERROR_CODE",
  "error_description": "Human-readable description of the error"
}

Security Considerations

Risk	Mitigation
`client_secret` exposure	Never hardcode the `client_secret` in source code or client-side assets. Load it exclusively from environment variables or a secrets manager.
Overly broad scopes	Configure only the minimum scopes required for each audience on the OIDC application. Scopes are set in the Admin Console — apply least-privilege when selecting allowed scopes per audience.
Token storage	Store the `access_token` in memory only. Do not persist it to disk, logs, or databases.
Token expiry	Implement proactive token refresh: re-request a new token before expiry rather than waiting for a `401` response from the resource server.

Flow Comparison

Aspect	Client Credentials Flow	Authorization Code Flow	PKCE Flow
Use case	M2M / service-to-service	Server-side user auth	SPA / mobile user auth
User interaction	❌ None	✅ Required	✅ Required
`client_secret` required	✅ Yes	✅ Yes	❌ No
`id_token` issued	❌ No	✅ Yes	✅ Yes
`refresh_token` issued	❌ No	✅ Yes	✅ Yes
Back-channel only	✅ Yes	✅ Token exchange	✅ Token exchange
Browser redirect	❌ No	✅ Yes	✅ Yes