API Resources

An API Resource represents one of your backend APIs that LoginRadius can issue audience-restricted access tokens for. When a client requests a token with resource=<URI> (or its equivalent audience=<URI>), LoginRadius validates the value against the API Resources you have registered here, and binds the issued token's aud claim to that URI.

API Resources are configured under Authorization → APIs in the LoginRadius Admin Console. They are a platform-wide construct — the same registration powers audience binding for Authorization Code, PKCE, Client Credentials (M2M), and OIDC flows.

When to register an API Resource

You should register an API Resource when any of the following applies:

You are using Resource Indicators on /authorize or /token to scope tokens to a specific API.
You are using Machine-to-Machine Client Credentials to call your own backend APIs.
You want per-API scopes — for example, read:orders should only be valid for the Orders API.
You want different token TTLs for different APIs (e.g., shorter-lived tokens for the Payments API).
You want to allow token exchange against a specific API.

Create an API Resource

Navigate to Authorization → APIs in the LoginRadius Console and click Create API. Provide the following:

Field	Description
API Name	A friendly name used to identify the API resource.
Identifier	A unique URI used as the `audience` (or `resource`) value when requesting tokens for this API. Both `https://...` and `api://...` schemes are accepted — for example, `https://api.payments.example.com/` or `api://payment_gateway`. This value cannot be changed after the API is created.

Click Create to register the API. You can then configure its scopes and token settings.

Configure API Settings

Open the API resource to manage its settings.

General Settings

Field	Description
API Name	The display name of the API resource. Can be updated at any time.
Identifier	The audience URI for this API. Read-only once the API has been created.

Scopes

Define the scopes that clients can request when obtaining tokens for this API. Enter a scope name (e.g., read:orders) and a short description, then click Add. The actual enforcement of these scopes must be implemented in your API.

User Access

Field	Description
Access based on RBAC Roles	When enabled, the user must hold the requested scopes via an assigned RBAC role — the scopes on the issued token are the intersection of API Resource scopes, app-level allowed scopes, and the user's role permissions. When disabled, only the API Resource and app-level configuration are intersected (the user's roles are not consulted). See Scope Resolution for a worked example.

Token Settings

Field	Description
Token TTL (In Secs)	The lifetime of access tokens issued for this API, in seconds. The maximum allowed value is `31536000` (one year).
Allow Token Exchange	When enabled, tokens can be securely issued, mapped, and exchanged to support trusted authentication and authorization across systems and applications.

Click Update to save the configuration.

Attach an API Resource to Your Application

Registering an API Resource makes it available on your tenant, but each OAuth 2.0 / OIDC application must be explicitly granted access to the resources it can request tokens for. This is done on the application's APIs tab.

Navigate to Applications → Apps and open your OAuth 2.0 or OIDC app.
Open the APIs tab.
Click + Add New and select an API Resource from the Audience dropdown — the list reflects the API Resources you registered under Authorization → APIs.
In the Scopes column, pick the subset of that API Resource's scopes this app is allowed to request. At least one scope is required — you cannot save an attached API Resource with an empty Scopes selection.
Repeat for any additional API Resources this app needs access to.
Click Save.

The APIs tab displays a two-column table — Audience (the registered API Resource Identifier) on the left, Scopes (the per-app allowed subset) on the right — with an + Add New button to attach additional resources.

What this configuration controls

Audience visibility — the app can only request resource=<URI> for an API Resource that appears in its APIs tab. A request for an unattached resource returns invalid_target.
App-level scope subset — even if an API Resource defines 10 scopes, this app sees only the subset enabled here. This is the middle layer in Scope Resolution.

Tip — least privilege. Attach only the API Resources each app genuinely needs, and enable only the scopes that app requires for its function. This is the simplest, most effective control surface for limiting blast radius if a client credential leaks.

Scope Resolution

The scopes that end up in an issued access token are not simply whatever the client asked for. LoginRadius intersects three sets to compute the final scope list:

API Resource scopes — every scope you defined on the API Resource (e.g., all 10 scopes registered under your Payments API).
App-level allowed scopes for the resource — the subset of the API Resource's scopes that this specific OAuth / OIDC app is permitted to request, configured on the app's APIs tab (e.g., only 5 of the 10 are enabled for your mobile app).
User's role permissions — the scopes granted to the user through their assigned RBAC role(s) (e.g., the user's role grants 2 scopes).

The token's scope claim contains only the scopes present in all three sets. The user's role permissions (set 3) are consulted only when Access based on RBAC Roles is enabled on the API Resource.

With RBAC enforcement ON

If the intersection is empty — i.e., the user holds no role permissions overlapping the app's allowed scopes for this resource — the request fails with an access_denied error and no token is issued.

With RBAC enforcement OFF

User roles are not consulted. The token reflects whatever the API Resource and the app jointly allow.

Worked example

Layer	Configured scopes
API Resource (`https://api.payments.example.com`)	`read:payments`, `write:payments`, `read:refunds`, `write:refunds`, `read:disputes`, `write:disputes`, `read:reports`, `export:reports`, `admin:users`, `admin:keys`
App-level allowed scopes for this resource	`read:payments`, `write:payments`, `read:refunds`, `read:reports`, `admin:users`
User's role permissions	`read:payments`, `read:reports`

With RBAC enforcement ON — the token's scope claim contains: read:payments read:reports. The user requested write:payments too, but it's dropped because the user's role does not grant it.

With RBAC enforcement OFF — the token's scope claim contains: read:payments write:payments read:refunds read:reports admin:users (the full app-level allowed list, regardless of user role).

Common gotcha — If a developer sees fewer scopes on the issued token than they requested, the cause is almost always one of these three layers filtering them out. Check the API Resource's scope list, the app's APIs tab, and (if RBAC is enabled) the user's role assignments.

Using API Resources with Different Grant Types

The same API Resource registration powers audience-restricted tokens across all OAuth 2.0 and OIDC flows. The parameter name and the request location vary by flow:

Authorization Code / PKCE
Client Credentials (M2M)
OIDC Flows

Pass resource on /authorize and again on /token (the values must match):

GET /service/oauth/{OAuthAppName}/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &resource=https%3A%2F%2Fapi.payments.example.com
  ...

Full guide: Resource Indicators.

Pass audience (or equivalently resource) in the token request body:

{
  "audience": "https://api.payments.example.com",
  "grant_type": "client_credentials",
  "client_id": "<CLIENT_ID>",
  "client_secret": "<CLIENT_SECRET>"
}

Full guide: Machine-to-Machine OAuth.

OIDC /authorize and /token accept the same resource parameter as OAuth 2.0. The OIDC app configuration also exposes an Audiences field for the default audience list. See the OIDC Overview.

The `resource` vs `audience` Parameter

LoginRadius accepts both resource and audience as aliases for the same parameter — identical behavior, identical result. The two names exist for historical reasons:

resource follows the RFC 8707 "Resource Indicators for OAuth 2.0" standard.
audience is LoginRadius's historical naming, also used by several other identity providers in the Client Credentials grant.

Use whichever your SDK or library exposes — the issued token is identical either way. For new integrations, prefer resource for OAuth 2.0 spec parity.

Migration: Existing integrations using audience continue to work without changes.

Validation Rules

The Identifier must be an absolute URI with a scheme. Both https://api.example.com/ and api://payment_gateway style identifiers are valid. Relative URIs and URIs containing a fragment (#...) are rejected.
The Identifier is read-only after API creation. To change it, create a new API Resource and migrate clients.
A request with a resource / audience value that does not match any registered API Resource returns invalid_target.
Do not embed PII, credentials, or secrets in the Identifier URI — the value appears in issued JWT claims and server logs.