B.4 Refreshing an access token

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

B.4.0 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 MCPTT clients and web-based MCPTT clients). Refresh tokens are not given to clients utilizing the implicit grant type (browser-based MCPTT clients). Figure B.4.0-1 shows how Native MCPTT clients can use the refresh token as a grant type to obtain new access tokens.

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

B.4.1 Access token request

To obtain an access token from the MCPTT IdM server using a refresh token, the MCPTT client makes an access token request to the token endpoint of the IdM server. The MCPTT 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.4.1-1.

Table B.4.1-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 MCPTT 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 MCPTT client as part of the original authorization request.

An example of a token request for MCPTT 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 MCPTT client was provided with client credentials by the MCPTT 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.4.2 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 MCPTT client, and optionally another refresh token.

An example successful response for MCPTT 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.