Authorization

Overview

The Authentication API uses a mixed model because it serves both public entry flows and authenticated user actions. Some endpoints are intended for public sign-up or login initiation, while others operate only after a valid user session exists.

As a result, this group combines application credentials, tenant credentials, and user bearer tokens depending on the operation.

Primary authentication models

The most common patterns in this group are:

• apikey plus client_id for public authentication entry points
• bearer access tokens for authenticated user actions
• selected management-style credential combinations on specific routes

This group should be treated as mixed, not uniformly public or uniformly admin-only.

Required credentials

Depending on the endpoint, you may see:

• apikey
• client_id
• client_secret
• apisecret
• Authorization: Bearer <access-token>
• X-LoginRadius-ApiKey
• X-LoginRadius-ApiSecret
• machine-to-machine bearer tokens on selected operations

Security schemes used in this group

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

• APIKey
• ClientId
• BearerToken
• ApiSecret
• APISecret
• ClientSecret
• XLoginRadiusAPIKey
• XLoginRadiusAPISecret
• M2MBearerToken

Practical interpretation

• APIKey and ClientId are the most common combination for public registration and login-style endpoints
• BearerToken is used when the endpoint acts on an authenticated user session
• APISecret and ClientSecret appear on more sensitive or management-adjacent operations
• X-LoginRadius-* header variants appear on selected routes and should be followed exactly when required

Headers and query parameters

Common auth inputs in this group include:

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

Do not assume an access token replaces application credentials for public auth flows. Many authentication entry points still require application-level parameters.

Token usage guidance

Public auth flows

For registration, login, passwordless, or passkey entry points, expect tenant/app-level parameters such as apikey and client_id.

Authenticated user flows

For user profile, user update, or session-bound actions, expect a bearer token. Use:

• Authorization: Bearer <access-token>

whenever the endpoint supports standard user-session authorization.

Sensitive or backend-only flows

Some routes expose administrative or elevated credential patterns. Those should remain server-side and should not be used directly from browser code.

Examples and common patterns

Typical patterns in this group include:

• initiating login with apikey and client_id
• completing user-scoped actions with a bearer access token
• calling verification or recovery operations with application credentials
• using backend-only secrets for specialized high-trust identity actions

Common auth errors and pitfalls

• using only a bearer token on endpoints that still require apikey and client_id
• exposing client_secret or apisecret in frontend code
• assuming all login endpoints share the same auth contract
• treating management-style security patterns as if they were safe for public flows
• forgetting that session-bound endpoints operate differently from registration or login initiation endpoints

Check each generated operation page before implementation, especially when moving between login, password, session, and user sub-sections.