Authorization

Overview

The Account API uses a mixed authorization model. Most operations are administrative or backend-controlled, and many of them use tenant and application credentials rather than an end-user bearer token alone.

This is one of the most credential-heavy groups in the LoginRadius API surface, so integrations should assume backend-only execution unless an endpoint explicitly states otherwise.

Primary authentication models

Across the Account API, the most common authorization patterns are:

• tenant API credentials
• application client credentials
• machine-to-machine bearer tokens
• signed requests for selected management endpoints

Some account-adjacent actions also involve access-token-oriented behavior, but the dominant pattern in this group is administrative account management.

Required credentials

Depending on the endpoint, you may need some combination of:

• apikey
• apisecret
• client_id
• client_secret
• Authorization: Bearer <m2m-token>
• X-LoginRadius-ApiKey
• X-LoginRadius-ApiSecret
• Digest
• X-Request-Expires

Treat these as endpoint-specific combinations, not one universal requirement set.

Security schemes used in this group

The current public spec uses these schemes in the Account API group:

• APIKey
• APISecret
• ApiSecret
• XLoginRadiusAPIKey
• XLoginRadiusAPISecret
• ClientId
• ClientSecret
• M2MBearerToken
• Digest
• XRequestExpiresTime

What these mean in practice

• APIKey, APISecret, and ApiSecret represent tenant-level credentials
• ClientId and ClientSecret represent application credentials
• M2MBearerToken is used for service-to-service access
• XLoginRadiusAPIKey and XLoginRadiusAPISecret are header-based administrative variants
• Digest and X-Request-Expires are used for request-signing flows on selected endpoints

Headers and query parameters

Common parameters and headers you will see in this group include:

• query apikey
• query apisecret
• query client_id
• query client_secret
• header X-LoginRadius-ApiKey
• header X-LoginRadius-ApiSecret
• header Authorization: Bearer <token>
• header Digest
• header X-Request-Expires

When an endpoint supports signed requests, the digest and expiry values are part of the authorization contract and should be treated as required for that route pattern.

Token usage guidance

Use backend credentials by default

For most Account API operations, use backend-held credentials and never expose tenant secrets or client secrets in browser code.

Use M2M tokens for service-to-service operations

Where supported, prefer machine-to-machine bearer tokens for automation, orchestration, or admin-service integrations.

Use signed requests where required

For selected account management endpoints, request signing adds integrity and replay protection. In those cases:

• generate Digest using the expected signing process
• set X-Request-Expires
• keep signing keys strictly server-side

Examples and common patterns

Typical account-management integrations include:

• admin dashboards managing account profile data
• customer-support tooling for unlock, reset, or recovery operations
• backend workflows that assign role contexts or permissions
• service-side systems creating or updating account-scoped custom objects
• compliance or support flows that revoke, refresh, or invalidate account session artifacts

Common auth errors and pitfalls

• using Account API routes from client-side code with exposed secrets
• assuming bearer-token auth is enough for management routes that require tenant or client credentials
• missing Digest or X-Request-Expires on signed-request endpoints
• mixing query-based credentials and header-based credentials incorrectly
• assuming all account endpoints share the same auth contract

Always validate the exact operation requirements in the generated reference page before implementation.