Access-token response

Learn about the structure of a successful response to a client's access-token acquisition request.

Note: The structure of a valid access-token response is relevant if you use the low-level WLAuthorizationManager class and manage the OAuth interaction between the client and the authorization and resource servers yourself, or if you use a confidential client. If you are using the high-level WLResourceRequest class, which encapsulates the OAuth flow for accessing protected resources, the security framework handles the processing of access-token responses for you. See Client security APIs and Confidential clients.
A successful HTTP response to an access-token request contains a JSON object with the access token and additional data. Following is an example of a valid-token response from the authorization server; (actual access tokens are longer than shown in the example):
HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store
    Pragma: no-cache
{
    "token_type": "Bearer",
    "expires_in": 3600,
    "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
    "scope": "scopeElement1 scopeElement2"
}
The token-response JSON object has these property objects:
  • token_type - the token type is always "Bearer", in accordance with the OAuth 2.0 Bearer Token Usage specification.
  • expires_in - the expiration time of the access token, in seconds.
  • access_token - the generated access token.
  • scope - the requested scope.
The expires_in and scope information is also contained in the token (access_token). See Structure of the MobileFirst access token.