B.5 Refreshing an access token

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

B.5.1 General

To protect against leakage or other compromise, access token lifetimes are typically short lived (though it is ultimately a matter of security policy & configuration by the service provider). Some client types can be issued longer-lived refresh tokens, which enable them to refresh the access token and avoid having to prompt the user for authentication again when the access token expires. Refresh tokens are available only to clients utilizing the authorization code grant type (native MCX clients and web-based MCX clients). Refresh tokens are not given to clients utilizing the implicit grant type (browser-based MCX clients). Figure B.5.1-1 shows how Native MCX clients can use the refresh token as a grant type to obtain new access tokens.

Figure B.5.1-1: Requesting a new access token

B.5.2 Access token request

To obtain an access token from the IdM server using a refresh token, the MCX client makes an access token request to the token endpoint of the IdM server. The MCX client does this by adding the following parameters using the "application/x-www-form-urlencoded" format, with a character encoding of UTF-8 in the HTTP request entity-body. The access token request standard parameters are shown in table B.5.2-1.

Table B.5.2-1: Access token request standard required parameters

Parameter	Values
grant_type	REQUIRED. The value shall be set to "refresh_token".
scope	Space-delimited set of permissions that the MCX client requests. Note that the scopes requested using this grant type shall be of equal to or lesser than scope of the original scopes requested by the MCX client as part of the original authorization request.

An example of a token request for MCX Connect might look like:

EXAMPLE:

POST /as/token.oauth2 HTTP/1.1
Host: IdM.server.com:9031
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=Y7NSzUJuS0Jp7G4SKpBKSOJVHIZxFbxqsqCIZhOEk9&scope=3gpp:mcptt:ptt_server

If the MCX client was provided with client credentials by the IdM server, then the client shall authenticate with the token endpoint of the IdM server utilizing the client credential (shared secret or public-private key pair) established during the client registration phase.

B.5.3 Access token response

In response to the access token request (above) the token endpoint on the IdM server will return an access token to the MCX client, and optionally another refresh token in an access token response message.

The access token response standard parameters are shown in table B.5.3-1.

Table B.5.3-1: Access token response standard parameters

Parameter	Values
access_token	REQUIRED. This is the issued access token.
token_type	REQUIRED. This field shall be “bearer”
expires_in	REQUIRED. The lifetime in seconds of the access token.
Id_token	OPTIONAL. This is the issued id token.
Refresh_token	OPTIONAL. This is the issued refresh token.

An example of a successful response for MCX Connect might look like:

EXAMPLE:

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

 "access_token":"eyJhbGciOiJSUzI1NiJ9.eyJtY3B0dF9pZCI6ImFsaWNlQG9yZy5jb20iLCJleHAiOjE0NTM1MDYxMjEsInNjb3BlIjoib3BlbmlkIDNncHA6bWNwdHQ6cHR0X3NlcnZlciIsImNsaWVudF9pZCI6Im1jcHR0X2NsaWVudCJ9.yXGl0gu3SsRQ_VUrDTWuEp-X8wrj-xUzXzWhTnqntXn0fI6xLR0i6VHtY3L25w81u260bsOFUMiYLLBC0LOKi-SOcwMqrzH6_BZwjkRhExiAciHZNtwgIlHWYwpCuxQII0dcg7_bw_YAFEQQC9IDzsifPXl9JmazI8YMtGcAWohoiSi0KY1pnbORUDBSPLLFlekQH5aOWbe_6EF4pDbm5pH8GXLd_ZtxS7jC6tAAMsCvsRy7Pb_GeDr_jT8-IevGKWO82of7gaUQkF8qnKVagr4-qc2FJeSDuhj4ZvfL510cgcRGy4NJ_7xxS10bzFNLavfqOlgOelJv0KA9IAd-1Q",
   "refresh_token": "iTxQYALqlc7uLyFGpnl8tR8Y9gkw91mFy2qC9Yywkz",
   "token_type": "Bearer",
   "expires_in": 7199
}

It is possible to configure the IdM server to confirm that the user account is still valid each time the refresh token is presented, and to revoke the refresh token if not. This security practice is RECOMMENDED.