Authorization

Overview

The Single Sign-On API has one of the most mixed authorization profiles in the LoginRadius API surface because it spans several identity protocols. OAuth, OIDC, JWT, SAML, M2M, and cross-device flows do not all use the same input model.

This group should be treated as protocol-specific rather than uniform.

Primary authentication models

Across the current spec, the main patterns are:

• apikey plus client_id
• apikey plus X-LoginRadius-ApiKey on selected routes
• query access_token on some token-driven routes
• bearer tokens on selected endpoints

The protocol you are implementing determines which of these patterns applies.

Required credentials

Depending on the endpoint, you may need:

• apikey
• client_id
• query access_token
• Authorization: Bearer <token>
• X-LoginRadius-ApiKey

Security schemes used in this group

The current public spec uses these schemes in the Single Sign-On API group:

• APIKey
• XLoginRadiusAPIKey
• AccessToken
• BearerToken
• ClientId

Practical interpretation

• OAuth and OIDC token-oriented operations commonly use apikey plus client_id
• some JWT or SSO routes include X-LoginRadius-ApiKey
• some routes accept or require query access_token
• some operations support bearer-token authorization

Headers and query parameters

Common auth inputs in this group include:

• query apikey
• query client_id
• query access_token
• header Authorization: Bearer <token>
• header X-LoginRadius-ApiKey

Do not normalize these away at the integration layer. Respect the exact requirements per protocol endpoint.

Token usage guidance

OAuth and OIDC

Expect application-driven inputs such as apikey and client_id, especially for token issuance, device code, revocation, and introspection endpoints.

JWT and SSO connector-like behavior

Some JWT-adjacent routes use X-LoginRadius-ApiKey rather than the simpler public-flow shape.

Access-token-driven routes

Some SSO operations rely on a query access_token or a bearer token to represent an already-authenticated user or delegated identity.

Examples and common patterns

Typical examples in this group include:

• exchanging OAuth or OIDC device codes for tokens
• introspecting or revoking OAuth tokens
• requesting JWT-backed SSO tokens for downstream applications
• calling SSO routes with an existing user access token
• using application credentials for protocol bootstrap and configuration-driven flows

Common auth errors and pitfalls

• assuming all SSO protocols use the same parameters
• treating query access_token and bearer token usage as interchangeable
• omitting client_id on OAuth or OIDC routes that require it
• missing X-LoginRadius-ApiKey on selected SSO endpoints
• reusing public login assumptions from Authentication API in protocol-specific SSO flows

Always confirm the exact operation requirements in the generated reference page for the protocol and route you are implementing.