For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.

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 we use the low-level WLAuthorizationManager class and manage the OAuth interaction between the client and the authorization and resource servers yourself, or if we 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.

Parent topic: Access tokens