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. 
casso128
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. 
How Implicit Flow Works
The following diagram details the flow:
Authentication Using Implicit Flow
Authentication Using Implicit Flow
The Implicit Flow works as follows:
  1. Client sends an authentication request to Authorization Endpoint.
  2. Authorization Server at Authorization Endpoint authenticates the user and obtains the user consent to share the requested scope information with Client.
  3. Authorization Server redirects the user to Client along with ID Token and Access Token depending on the response type.
  4. Client validates ID Token and sends Access Token to User Info Endpoint. 
  5. 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
CA Single Sign-On
 to receives the Authorization Endpoint URL. For information, see Configure  as OpenID Connect Provider.
Authorization Endpoint Flow
Authorization Server performs the following steps at Authorization Endpoint:
  1. Client sends an authentication request to Authorization Endpoint.
  2. Authorization Server at Authorization Endpoint performs the following tasks:
    1. 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.
    2. 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.
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 the 
    scheme
    ://
     format 
    where 
    scheme
     = alphabet *(alphabet|digit|+|-|.)
Examples
https://sample.ca.com/example/redirect_uri
OR
oidc.example.sso://sample.com/example/redirect_uri
For Public Clients, use the HTTPS or 
scheme
:// format.
response_mode
Specifies whether the authentication response to redirect_uri must be sent in the form of query parameters or encoded as HTML form values that are sent in POST method. By default, Implicit Flow uses
fragment
 as the response mode. To send the the response in fragment format, you need not send this parameter in the authentication request. To send the response in encoded as HTML form values, specify 
form_post
 as the value in the authentication request.
nonce
Specifies a value that associates a client session with an ID Token. The value must contain sufficient entropy to prevent attacks.
CA Single Sign-On
 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://wa.example.com/affwebservices/CASSO/oidc/sample_client/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://
authorization_endpoint_URL
/affwebservices/CASSO/oidc/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 token
GET /affwebservices/CASSO/oidc/sample_client/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: sample.ca.com
Response
: Successful response
HTTP/1.1 302 Found
Location: https://sample.ca.com/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0NiJ9.eyJ1cI6IjIifX0.DeWt4QuZXso
&expires_in=3600
&state=af0ifjsldkj
Request 2
: Request with id_token
GET /affwebservices/CASSO/oidc/sample_client/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.1
Host: sample.ca.com
Response
: Successful response
HTTP/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 
    CA Access Gateway
    , and that the Administrator must verify the 
    CA Single Sign-On
     log and trace files.
Scenario
Error Code
Error Description
HTTP Status Code
Request does not use HTTPS
invalid_request
Request is not secure
302
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 redirect_uri parameter is missing or its value is empty in the authentication request, or its value is not matching with the value configured in the client configuration
invalid_request
redirect_uri 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
Display query parameter value is not empty and is other than page, popup, wap, and touch  
invalid_request
Invalid display parameter
302
Prompt query param value is not empty, and contains all with space separated (login, consent, none), contains none with any other value, or contains select_account
invalid_request
Invalid prompt parameter
302
Invalid value in max_age
invalid_request
Invalid max_age
302
User clicked
Deny
in the consent page or the user corresponding to the current SMSESSION cookie does not have the permission to access the current client_id OpenID transaction
access_denied
access_denied
302
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. However, from Release 12.8.02, public clients do not require client credentials in requests to endpoints.
From Release 12.8.02, the Client ID and Client Secret values can be specified in one of the following formats in the authorization header for a Basic client authentication:
  • 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_type
POST /affwebservices/CASSO/oidc/sample_client/introspect HTTP/1.1
Host: wa.example.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 token
POST /affwebservices/CASSO/oidc/sample_client/introspect  HTTP/1.1
Host: wa.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=2YotnFZFEjr1zCsicMWpAA
Response 1
: Successful response
HTTP/1.1 200 OK 
Content-Type: application/json 
"active": true,
"client_id": "bb8293f6-ceef-4e7a-90c8-1492e97df19f",
"token_type": "refresh_token",
"scope": "openid profile",
"sub": "cn=odicuser,dc=example,dc=com",
"exp": "86400",
"iat": "1506513918",
"iss": "https://wa.example.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 response
HTTP/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
  • Required inputs are missing in the request
  • Authorization header and client ID/Client Secret exist in the request
  • Unable to get client ID from authorization header or form parameters of the request
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
Revocation Endpoint
You can send a request to 
CA Single Sign-On
 if you want to revoke Access Token in the following format:
POST 
revocation_endpoint
 HTTP/1.1
Host: 
host_name
Accept: application/json
Content-Type: application/x-www-form-urlencoded
token=
token_value
&token_type_hint=
token_type&
client_id=
client_id
&client_secret=
client_secret
Supported Parameters
The request must contain either the authorization header, or Client ID and Client Secret in the POST body for a public or confidential client.
The following parameters must be sent in the revoke request:
token
Defines Access Token that must be revoked.
token_type_hint
(Optional) Specifies type of the token that must be revoked. Enter
access_token
.
client_id
 and 
client_secret
Specifies the credentials of the client that is requesting to revoke the token.
From Release 12.8.02, the Client ID and Client Secret values can be specified in one of the following formats in the authorization header for a Basic client authentication:
  • Base64 encoded (Client ID:Client Secret)
  • Base64 encoded (URL encoded Client ID:URL encoded Client Secret)
Example Requests and Responses
Request 1
: Request format for a public client 
POST /affwebservices/CASSO/oidc/sample_client/revoke HTTP/1.1
Host: wa.example.com
Content-Type: application/x-www-form-urlencoded
token=4d81zFeVyY3JctQ5t30BKCBqjYI=
token_type_hint=access_token
client_id=c297db44-6d51-4b7b-8ed8-99e1323dd813
 
Request 2
: Request format for a confidential client using POST authentication method 
POST /affwebservices/CASSO/oidc/sample_client/revoke HTTP/1.1
Host: wa.example.com
Content-Type: application/x-www-form-urlencoded
token=sfthwYNeo%2BvOOJses6KlKwShZF0=
token_type_hint=access_token
client_id=3aaf31b-86ee-48d7-adf9-42dea3a2e3df
client_secret=xT4v8xMjMJ7ZvDXf4yezG3W6eYghYXUM6Lf4
Response 1
: Authorization Server sends an HTTP status code 200 in the following format if the token is revoked successfully
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-store
Content-Length: 0
Response 2
: Authorization Server sends an HTTP status code 400 error in the following format if the request is invalid
Sample Error Response:
HTTP/1.1 400 Bad Request
Cache-Control: no-store
Pragma: no-store
Content-Type: application/json; charset=UTF-8
{"error":"invalid_request","error_description":"token is missing"}
Error Messages
Authorization Server uses the following error codes:
Scenario
Error Code
HTTP Status Code
Request is not using the HTTPS protocol
Request is not in the application/x-www-form-urlencoded format
Token hint is other than access_token
Both authorization header and client ID form parameter exists in the request
Unable to get client ID from authorization header or form parameters of the request
Token is missing or the request has more than one token
invalid_request
400
Client ID in the request is not authorized to revoke the token
unauthorized_client
400
Client Configuration is not configured correctly
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. 
CA Single Sign-On
 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 format
GET /affwebservices/CASSO/oidc/sample_client/userinfo HTTP/1.1
Host: wa.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjF
Request 2
: GET request in query format
https://wa.example.com:443/affwebservices/CASSO/oidc/sample_client/userinfo?access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjF
Request 3
: POST request
POST /affwebservices/CASSO/oidc/userinfo HTTP/1.1
Host: wa.example.com
Content-Type: application/x-www-form-urlencoded
access_token=sfthwYNeo%2BvOOJses6KlKwShZF0=
Response 1
: Successful response
HTTP/1.1 200 OK 
Content-Type: application/json 
"sub": "248289761001", 
"name": "Jane Doe", 
}
Response 2
: Successful response with encrypted user info
HTTP/1.1 200 OK 
Content-Type: application/jwt
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
Response 3
: Invalid response
HTTP/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.
The following is the format of the endpoint:
<a
uthorizationserver_base_URL
>/affwebservices/CASSO/oidc/sample_client/jwks?AuthorizationProvider=
Authorization_Provider_Name
The following is an example of a successful response:
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"4b184eb1-28c6-4000-afa8-13905b5e4b65","n":"0_auyMyxoaTFbty5pUAvxNmp7PjljV8eh1a-Ebc5h956XhyU1X19HH7J_5mSuyzx2NZ6J3-vdjYqqJSuJi2f1u9tE5ISE5VTa7b7ykMdyHK-8qyCHNEd6rRorR7uVMrfHeoh6s066nGsHiRpyYpMqa72oCtiCtMj--flXSTQe1k"}]}
The following is an example of a failed response:
{"error":"invalid_request","error_description":"Failed to retrieve Configuration information."}
When you export the endpoint, you will see this endpoint in the 
jwks_uri
 attribute.
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