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