OpenID Connect Implicit Flow

The Implicit Flow is an OpenID Connect authentication flow where tokens are returned directly in the authorization response — no separate token exchange step is required. The access_token or id_token is delivered via the browser redirect URL itself, making it a simpler but less secure flow compared to the Authorization Code Flow.

Note: The Implicit Flow is considered legacy. It has been deprecated in OAuth 2.0 Security Best Current Practice due to token exposure in browser history and referrer headers. For new applications, use the Authorization Code Flow with PKCE instead.

Overview

Unlike the Authorization Code Flow, the Implicit Flow skips the back-channel token exchange entirely. After the user authenticates, LoginRadius appends the requested tokens directly to the redirect_uri as a URL fragment (#). The tokens are immediately accessible to the client-side JavaScript but are never sent to the server.

The flow operates in a single phase:

Authorization & Token Phase — runs in the browser. The client redirects the user to the LoginRadius OIDC Authorization endpoint. After the user authenticates, LoginRadius redirects back to the client with the requested token(s) appended directly to the redirect_uri as a URL fragment.

Flow Diagram

Step-by-Step Walkthrough

Step 1 — Authorization Request

The client application redirects the user's browser to the LoginRadius OIDC Authorization endpoint with the desired response_type.

Endpoint

GET https://{SiteURL}/service/oidc/{OIDCAppName}/authorize

SiteURL = Either <TenantName>.hub.loginradius.com or CustomDomain i.e. auth.your-app.com · OIDCAppName = your configured OIDC App name

Supported response_type values

`response_type`	Tokens returned
`token`	`access_token` only
`id_token`	`id_token` only
`token id_token`	Both `access_token` and `id_token`

Example Request

GET https://your-app.hub.loginradius.com/service/oidc/MyApp/authorize
  ?client_id=YOUR_OIDC_CLIENT_ID
  &response_type=token%20id_token
  &scope=openid%20profile%20email
  &redirect_uri=https://your-app.com/callback
  &nonce=abc123xyz
  &state=xyz987abc

nonce is required when id_token is included in response_type. It is embedded in the id_token claim to prevent replay attacks.

Step 2 — Session Check

Upon receiving the request, LoginRadius checks whether the user already has an active authenticated session.

If an active session is found → LoginRadius skips the login UI and immediately redirects to redirect_uri with the requested tokens in the URL fragment.
If no active session → LoginRadius renders the login UI for the user to authenticate.

Step 3 — User Authentication

The user authenticates via the login page. Two login paths are supported:

Traditional Login — The user submits their credentials (email/password or phone).
Social Login — The user authenticates via a configured social provider. After successful authentication, LoginRadius generates the requested tokens and redirects back to the client's redirect_uri.

Step 4 — Token Issuance

LoginRadius redirects to the client callback with the tokens appended as a URL fragment.

Tokens are delivered as a URL fragment (#). Fragments are never sent to the server — they are only accessible to client-side JavaScript via window.location.hash.

Success Response — response_type=token id_token

HTTP 302
Location: https://your-app.com/callback
  #access_token={access_token}
  &token_type=Bearer
  &expires_in=3600
  &id_token={id_token}
  &state=xyz987abc

Success Response — response_type=id_token

HTTP 302
Location: https://your-app.com/callback
  #id_token={id_token}
  &state=xyz987abc

Success Response — response_type=token

HTTP 302
Location: https://your-app.com/callback
  #access_token={access_token}
  &token_type=Bearer
  &expires_in=3600
  &state=xyz987abc

Error Response

HTTP 302
Location: https://your-app.com/callback
  #error=access_denied
  &error_description=...

Errors are returned as fragment parameters on the redirect_uri by default. This behavior can be changed by passing the response_mode parameter in the authorization request.

Token Response Fields

Field	Description
`access_token`	LoginRadius JWT — use this to call protected APIs. Present when `response_type` includes `token`.
`token_type`	Always `Bearer`
`expires_in`	Lifetime of the access token in seconds
`id_token`	JWT containing identity claims about the authenticated user. Present when `response_type` includes `id_token`.
`state`	Returned as-is from the authorization request if provided

Error Handling

All errors are returned as fragment parameters appended to the client's redirect_uri:

https://your-app.com/callback#error=ERROR_CODE&error_description=Human+readable+message

Security Considerations

The Implicit Flow has known security limitations that make it unsuitable for most modern applications:

Risk	Description
Token in URL	Tokens are exposed in the browser URL fragment, making them visible in browser history, server logs, and referrer headers
No refresh token	The Implicit Flow does not support `refresh_token`, requiring full re-authentication when the access token expires
Token leakage	URL fragments can be leaked via browser extensions, third-party scripts, or referrer headers
No back-channel	Without a back-channel exchange, there is no way to verify the token request originates from a trusted client

For all new applications — particularly SPAs and mobile apps — use the Authorization Code Flow with PKCE instead. It provides the same browser-based simplicity without token exposure in the URL.