Authentication Using Implicit Flow
Implicit Flow is used by clients that are browser-based, use a scripting language, and are Single-Page Applications (SPA). Authorization Endpoint issues ID Token and Access Token, if configured, to Client directly. Authorization Server does not authenticate clients when it generates the tokens.
Due to the inherent risks of returning access tokens in an HTTP redirect it is not recommended to use the implicit flow. Public clients should now start using the authorization code flow with the PKCE extension instead.
How Implicit Flow Works
The following diagram details the flow:
Authentication Using Implicit Flow

The Implicit Flow works as follows:
- Client sends an authentication request to Authorization Endpoint.
- Authorization Server at Authorization Endpoint authenticates the user and obtains the user consent to share the requested scope information with Client.
- Authorization Server redirects the user to Client along with ID Token and Access Token depending on the response type.
- Client validates ID Token and sends Access Token to User Info Endpoint.
- User Info Endpoint authenticates the token and returns claims about the user.
Authorization Endpoint
Authorization Endpoint authenticates and authorizes users using the clients authentication request. The endpoint authenticates users to establish their identity, authorizes users, requests their consent, and then grants them access to the resource.
The Resource Provider (Client) must register with VIP Authentication Service to receives the Authorization Endpoint URL.
Authorization Endpoint Flow
Authorization Server performs the following steps at Authorization Endpoint:
- Client sends an authentication request to Authorization Endpoint.
- Authorization Server at Authorization Endpoint performs the following tasks:
- Validates the authentication request and uses the request parameters to determine whether the user is already authenticated.If the user is not authenticated, Authorization Server authenticates the user and upon successful authentication, it redirects the user to a consent page confirming if the requested scope information can be shared with Client.If the user is already authenticated, Authorization Server redirects the user to a consent page confirming if the requested scope information can be shared with Client.
- If the user clicks Allow on the consent page, returns a successful response that includes ID token and Access Token depending on the authentication request.If the user clicks Deny on the consent page or authentication fails, the browser will be redirected to the redirect_uri with corresponding error code appended to it. If the redirect_uri is invalid, the browser will not be redirected to Client.
Supported Parameters
The authentication request supports the following parameters:
response_type
Defines the authorization processing flow that must be used. Enter
id_token token
to retrieve ID Token and Access Token. Enter id_token
to retrieve only ID Token.Token to retrieve only Access Token.id_token token
Retrieves ID Token and Access Token.
id_token
Retrieves only ID Token.
token
Retrieves only Access Token.
redirect_uri
Specifies the URI to which the authentication response must be sent. This value must be the URI that was specified during client registration.
The URI can begin with one of the following schemes:
- HTTP
- HTTPS
- Custom URI in thescheme://formatwherescheme= alphabet *(alphabet|digit|+|-|.)
Examples
: https://iam.acme.com/example/redirect_uri OR oidc.example.ssp://iam.acme.com/example/redirect_uri
For Public Clients, use the HTTPS or
scheme
:// format.nonce
Specifies a value that associates a client session with an ID Token. The value must contain sufficient entropy to prevent attacks. VIP Authentication Service stores nonce from the authorization request and sends the same value as a standard nonce claim in ID Token.
state
(Optional) Defines an opaque value that Client uses to maintain state between the request and callback. Authorization Server includes this value when redirecting the request back to Client.
Supported HTTP Methods
Authorization Endpoint supports GET and POST methods.
GET
For GET, the authorization request contains an authorization endpoint URL and required OAuth 2.0 query parameters in the following format:
https://authorization_endpoint_URL?response_type=id_token_value&scope=scope_value&client_id=clientID_value&state=state_value&redirect_uri=redirect_URL_value&nonce=nonce_value
Or
https://authorization_endpoint_URL?response_type=id_token token_value&scope=scope_value&client_id=clientID_value&state=state_value&redirect_uri=redirect_URL_value&nonce=nonce_value
Example:
https://iam.acme.com:443/default/oauth2/v1/authorize?response_type=id_token&client_id=480e469c-8efa-4b11-946c-4badb446cc88&scope=UoS53-qFk0oI43icRjURWpk0OiM&redirect_uri=https%3A%2F%2Fsample.ca.com%2Fexample%2Fredirect_uri&nonce=IkfJuXy8Sseq_8L2Fq5aH2MVUYCUV7Khm1ApnLysLmU
POST
For POST, the authentication request is of the following format:
https://iam.acme.com:443/default/oauth2/v1/authorize
Ensure that the header type is Content-Type as shown:
Content-Type: application/x-www-form-urlencoded
Send the following parameters in the body of the authentication request:
scope=openid&redirect_uri=redirect_url_value&response_type=id_token&client_id=clientID_value
Or
scope=openid&redirect_uri=redirect_url_value&response_type=id_token token&client_id=clientID_value
Authorization Endpoint sends the following parameters:
access_token
Returns an access token if the response type is id_token token. This parameter is added to the response only if the response mode is id_token token.
token_type
Identifies the token type value. This value is Bearer and is returned only with an access_token. This parameter is added to the response only if the response mode is id_token token.
id_token
Identifies the ID token.
state
Identifies the state. Returns the value only if the authentication request contains this parameter.
expires_in
Identifies the validity of the access token.
Example Requests and Responses
Request 1
: Request with id_token tokenGET /https://iam.acme.com:443/default/oauth2/v1/authorize?response_type=id_token%20token &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: iam.acme.com
Response
: Successful responseHTTP/1.1 302 Found Location: https://iam.acme.com/cb# access_token=SlAV32hkKG &token_type=bearer &id_token=eyJ0NiJ9.eyJ1cI6IjIifX0.DeWt4QuZXso &expires_in=3600 &state=af0ifjsldkj
Request 2
: Request with id_tokenGET /https://iam.acme.com:443/default/oauth2/v1/authorize?response_type=id_token&client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&scope=openid%20profile&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj HTTP/1.1Host: iam.acme.com
Response
: Successful responseHTTP/1.1 302 Found Location: https://sample.ca.com/cb# &id_token=eyJ0NiJ9.eyJ1cI6IjIifX0.DeWt4QuZXso &state=af0ifjsldkj
Error Codes and Messages
Authorization Endpoint returns an error in response to an authentication request if the authentication fails or the user denies the request. When an error occurs, an error response with error, error description, and state (if included in the original request) is appended to the query string and sent to the client in redirect_uri. Authorization Endpoint displays the following errors and error descriptions:
Note
:- HTTP Status Code 302 indicates that the error code and description are sent to redirect_uri.
- HTTP Status Code 400 and HTTP Status Code 500 indicate that the error message is displayed in the web page after failing at VIP Authentication Server, and that the Administrator must verify the VIP Authentication Server log and trace files.
Scenario | Error Code | Error Description | HTTP Status Code |
The scope parameter is missing, or its value is empty in the authentication request or empty in the request | invalid_request | Missing or invalid scope | 302 |
The value of scope is not openid | invalid_request | Missing or invalid scope | 302 |
The response_type parameter is missing, or its value is empty in the authentication request | invalid_request | Missing or invalid response_type | 302 |
The value of response_type is not id_token or id_token token | unsupported_response_type | Missing or invalid response_type | 302 |
The nonce parameter is missing, or its value is empty in the authentication request | invalid_request | nonce is missing in the request | 302 |
The client_id of a disabled client is specified in the authentication request | unauthorized_client | Invalid client_id | 400 |
The client_id parameter is missing, or its value is empty or invalid in the authentication request | invalid_request | client_id is invalid or missing | 400 |
The client type is public and redirect_uri is not HTTPS URL | n/a | n/a | 400 |
Authorization Server configuration error | server_error | Internal Server Error | 500 |
Introspection Endpoint
Use Introspection Endpoint using POST method in the following format to validate the received Access Token, and view the scopes associated with the token:
POST introspect_endpoint HTTP/1.1 Host: host_name Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Basic encoded(client_id:client_secret) token=token_value&token_type_hint=token_type
token
Defines the token. Enter the value of access_token that you received from Token Endpoint.
(Optional) token_hint_type
Defines a hint about the token type that you want to verify. Authorization Server uses this hint in simplifying the search for the token. Enter
access_token
depending on the token value.For a public or confidential client, Client ID and Client Secret must be sent in an authorization header or POST body.
- Base64 encoded (Client ID:Client Secret)
- Base64 encoded (URL encoded Client ID:URL encoded Client Secret)
Example Requests and Response
Request 1
: Request with token and token_hint_typePOST /<tenant-name>/oauth2/v1/introspect HTTP/1.1 Host: auth.broadcom.com Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW token=QyHE5lcMiKPXfEIQILVq0pc&token_type_hint=access_token
Request 2
: Request with only tokenPOST /<tenant-name>/oauth2/v1/introspect HTTP/1.1 Host: auth.broadcom.com Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW token=2YotnFZFEjr1zCsicMWpAA
Response 1
: Successful responseHTTP/1.1 200 OK Content-Type: application/json { "active": true, "client_id": "bb8293f6-ceef-4e7a-90c8-1492e97df19f", "token_type": "bearer", "scope": "openid profile", "sub": "cn=odicuser,dc=example,dc=com", "exp": "86400", "iat": "1506513918", "iss": "https://iam.acme.com" }
active
Specifies the status of the token. The value true indicates that the token is valid and has not expired. The value false indicates that the token is invalid or has expired.
client_id
Identifies the client that requested the token.
token_type
Identifies the token type.
scope
Identifies the scopes that are associated with the token.
sub
Identifies the user who authorized the request.
exp
Identifies the time period in seconds in which the token will expire.
iat
Identifies the time in seconds when the token was originally issued.
iss
Identifies the authorization provider that issued the token.
Response 2
: Response if the token is invalid:HTTP/1.1 200 OK Content-Type: application/json { "active": false }
Response 3
: Error responseHTTP/1.1 400 Bad Request Content-Type:application/json; charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" "error_description": "token is missing in the request" }
Error Messages
The following table lists the error codes displayed:
Scenario | error_code | HTTP Status Code |
| invalid_request | 400 |
Client credentials are invalid | invalid_client | 401 |
The GET request is received | invalid_request | 405 |
Other server issues | Internal Server Error | 500 |
User Info Endpoint
User Info Endpoint returns claims related to the authenticated user. Client sends a request to User Info Endpoint along with Access Token, and User Info Endpoint returns the claims in the JSON format.
VIP Authentication Hub
sends claims that are scoped by the token to Client.Supported HTTP Methods
User Info Endpoint supports GET and POST methods. The GET request can be of the header or query format. The POST request is of the following format:
POST userinfo_endpoint HTTP/1.1 Host: host_name Content-Type: application/x-www-form-urlencoded access_token=access_token
Examples Requests and Responses
Request 1
: GET request in header formatGET/default/oauth2/v1/userinfo HTTP/1.1 Host: iam.acme.com Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjF
Request 2
: GET request in query formathttps://iam.acme.com:443/<tenant-name>/oauth2/v1/userinfo?access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjF
Request 3
: POST requestPOST /<tenant-name>/oauth2/v1/userinfo HTTP/1.1 Host: iam.acme.com Content-Type: application/x-www-form-urlencoded access_token=sfthwYNeo%2BvOOJses6KlKwShZF0=
Response 1
: Successful responseHTTP/1.1 200 OK Content-Type: application/json { "sub": "248289761001", "name": "Jane Doe", }
Response 2
: Successful response with encrypted user infoHTTP/1.1 200 OK Content-Type: application/jwt NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
Response 3
: Invalid responseHTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Error Messages
Error codes are displayed in the following scenarios:
Scenario | Error Code | HTTP Status Code |
Access Token is not found in either form parameter or authorization header of the request Request content type is not application/x-www-form-urlencoded Request has more than one Access Token Request has both authorization bearer header and access_token in the form parameters | invalid_request | 400 |
The access_token value expired, is revoked, malformed, or invalid | invalid_token | 401 |
Other server issues | Internal Server Error | 500 |
JSON Web Key Set Endpoint
You can use the JSON Web Key Set Endpoint (JWK Set Endpoint) to retrieve the public certificate that can be used for signing ID Token and user info.
When you export the endpoint, you will see this endpoint in the
jwks_uri
attribute.The following is an example of a successful response:
The following is an example of a failed response:{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"4b184eb1-28c6-4000-afa8-13905b5e4b65","n":"0_auyMyxoaTFbty5pUAvxNmp7PjljV8eh1a-Ebc5h956XhyU1X19HH7J_5mSuyzx2NZ6J3-vdjYqqJSuJi2f1u9tE5ISE5VTa7b7ykMdyHK-8qyCHNEd6rRorR7uVMrfHeoh6s066nGsHiRpyYpMqa72oCtiCtMj--flXSTQe1k"}]}
{"error":"invalid_request","error_description":"Failed to retrieve Configuration information."}
Error Messages
The following table lists the error messages that this endpoint displays:
Scenario | Error Code | HTTP Status Code |
Invalid POST request | invalid_request | 405 |
Authorization Provider is missing in the request or is invalid or is disabled | invalid_request | 400 |
Other server issues | Internal Server Error | 500 |