2. Access Token

As per the diagram shown in figure 2, SP should obtain the access token by passing the same access code which was received in the previous step.

cURL Request for Token Generation Call

curl --location --request POST 'https://stg-id.uaepass.ae/idshub/token?grant_type=authorization_code&redirect_uri=https://stg-selfcare.uaepass.ae&code=bfe96299-83f4-3ee9-80e4-56c24f5265d3' \
--header 'Content-Type: multipart/form-data' \
--header 'Authorization: Basic c2FuZGJveF9zdGFnZTpzYW5kYm94X3N0YWdl'

Replace code parameter '{Access Code}' with the value received from Access Code.

Response

{
  "access_token": "67f2536e-07e6-37c1-967f-78562000a4f9",
  "scope": "urn:uae:digitalid:profile:general",
  "token_type": "Bearer",
  "expires_in": 3600
}

API detail to exchange the token

POST https://stg-id.uaepass.ae/idshub/token

Query Parameters

Name	Type	Description
grant_type	string	Must have the value as “authorization_code”.
redirect_uri	string	Redirect URI to the application. The application waits to receive at this URI the authorization or authentication response message with the authorization code.
code	string	Authorization code received in the previous authorization response.

Headers

Name	Type	Description
Authorization	string	Basic {credentials}
Content-Type	string	multipart/form-data; charset=UTF-8

200 In response, UAEPASS issues a bearer-type OAuth 2.0 access token and returns it in a JSON structure. JSON object containing the access token, associated information and (if the scope was openid requested) an ID token. access_token: Access token generated by UAE PASS. token_type: Type of access token. Always has the “Bearer” value. expires_in: Lifetime (in seconds) of the access token. scope: Scopes granted to those to which the access token is associated, separated by spaces.

{
  "access_token": "67f2536e-07e6-37c1-967f-78562000a4f9",
  "scope": "urn:uae:digitalid:profile:general",
  "token_type": "Bearer",
  "expires_in": 3600
}

400 invalid_client, unregisteredClient: The client application is not registered. This error is usually observed due to misconfiguration of client credentials. unsupported_grant_type: The value of the grant_type parameter in the request is not supported. TrustedX currently only supports the authorization_code type. invalid_grant, codeNotFound: The authorization code specified in the code parameter of the request was not issued in a recent authorization response or has expired. invalid_grant, expiredCode: The authorization code specified in the code parameter of the request has expired. This error appears when passing the expired code to token generation call. The auth code received from authorization url should be utilized by SP within 10 seconds. invalid_grant, codeNotIssuedToClientId: The authorization code specified was issued for a different client application than that identified in the Authorization HTTP header. invalid_grant, redirectUriMismatch: The authorization code specified was issued for an authorization request associated to a redirect URL different from the URL specified in the redirect_uri parameter of the request. Please make sure that SP passes the same redirect url in authentication and token generation calls. invalid_grant, invalidOrExpiredCode: The authorization code specified in the code parameter of the request has expired or invalid. invalid_scope: Only for the client credentials grant flow. One of the scopes requested by the application is not included in this list of scopes provided by the authorization server or has not been enabled for the client credentials grant. This error also occurs if the application did not request any scope and the server has no default scope defined for this type of grant. Invalid_basic_header_authentication: This error appears when SP is not passing the client id or secret properly as configured in server. Invalid_Token: Please make sure that SP is passing the token to user profile API using header Authorization as Bearer {token}.

{
  "error": "Error code",
  "error_description": "invalidHttpBasicAuthenticationToken"
}

401 invalid_client, unsupportedAuthenticationScheme: The authentication scheme specified in the Authorization HTTP header is not supported. TrustedX currently only supports the basic scheme (HTTP Basic authentication scheme) specified in RFC 2617. invalid_client, invalidCredentials: The client application cannot be authenticated with the credentials included in the Authorization HTTP header. This may be because there is no Client Application configured in TrustedX with the identifier specified or because the entity exists but the secret does not match the configured secret.

{
  "error": "Error code",
  "error_description": "Additional description of the error"
}

500 If an internal error occurred in the server, a JSON response is not returned. Instead, an HTTP 500 (Internal Server Error) status code is returned In these cases, the TrustedX administrator must browse the log records to identify the problem.

{
  "error_description": "description"
}