Authorization Response Issuer Identifier (RFC 9207)

LoginRadius implements RFC 9207 (OAuth 2.0 Authorization Server Issuer Identifier) across all OpenID Connect (OIDC) and OAuth 2.0 flows. LoginRadius returns the iss parameter directly in authorization responses to defend clients against Mix-up Attacks.

Why It Matters: Mix-up Attacks

A Mix-up Attack occurs when a client application interacts with multiple authorization servers (e.g., a production server and a compromised/malicious test server).

An attacker can intercept the client's request to the malicious server and redirect it to the LoginRadius server, tricking the client into sending its authorization code or access token to the wrong server.

How RFC 9207 Solves This

LoginRadius appends the iss parameter to the callback redirection URL. The client validates this parameter against the expected issuer URI for that provider. If the issuer does not match, the client aborts the flow, preventing the code or token from being leaked.

LoginRadius Implementation Details

LoginRadius provides a standardized and robust implementation of issuer resolution on the core level:

Standardized Issuer Resolution (GetAuthorizationResponseIssuerV3): All authorization responses resolve the issuer through the centralized GetAuthorizationResponseIssuerV3 method. This method ensures that the computed issuer matches the configured tenant and app environment dynamically.
Path Normalization: Requests received at /api/ endpoints (such as API-centric back-channel requests) are normalized to resolve to their canonical /service/ discovery issuer endpoints, avoiding discrepancies between front-channel login interfaces and backend token issuers.
Centralized Logic (OidcRequest): Issuer resolution logic is encapsulated in the OidcRequest entity. This centralization prevents mismatches between the iss parameter returned in the authorization response, the iss claim in issued ID/access tokens, and the discovery document metadata.
Protocol & Route Variations: The issuer resolution logic dynamically detects the protocol type (OIDC vs. OAuth 2.0) and route types (service endpoints vs. non-service endpoints) to determine the correct format of the issuer URL.

How It Works in LoginRadius Flows

When a user completes authentication, LoginRadius redirects the browser back to your redirect_uri with the code and state parameters, along with the iss parameter.

Example Redirection URL

HTTP 302
Location: https://your-app.com/callback
  ?code=auth_code_xyz123
  &state=random_state_abc
  &iss=https%3A%2F%2Fyour-tenant.hub.loginradius.com%2Fservice%2Foidc%2Fyour-app-name

Client Validation Guidelines

If your client application supports RFC 9207 validation (which is natively supported by modern OIDC client libraries), it should perform the following steps:

Extract iss: When receiving the callback request, parse the iss query parameter.
Compare with Configured Issuer: Verify that the extracted iss matches the issuer URI configured for that client (e.g., the URL fetched from the .well-known/openid-configuration document).
Aborts on Mismatch: If the values do not match, reject the authorization code and return an error.

[!NOTE] The iss parameter is automatically URL-encoded in the redirection URL query string. Ensure your client library properly decodes it before comparison.