Developer Portal for YouTrack and Hub Help

Extension Grants

An extension grant lets you exchange access tokens from a third-party OAuth 2.0 authorization service with access tokens from Hub.

Reference to the Standard

Specification for Extension Grants (RFC 6749)


The service that you want to retrieve a Hub access token for is registered in Hub.

An OAuth 2.0 auth module for the third-party authorization service has been created an enabled in Hub.

A value is stored in the Extension grant setting for the authentication module.

Exchanging an Access Token

The client makes a request to exchange an access token by posting to the token endpoint and 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:

Required. Use the value that is stored in the Extension grant setting for the third-party authentication module in Hub.

Optional. The scope of the access request: A space separated list of IDs of the registered in Hub services associated with the resource servers. For example, if the client wants to access issues in YouTrack it should find out the ID of YouTrack service in Hub. The client can access more then one resource server with a single access token.

Note: The requested scope must not include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner.


Required. The token that grants access to the third-party authorization service that is registered in the OAuth 2.0 authentication module.

For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):

POST /api/rest/oauth2/token Host: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=token_exchange&scope=b4f60b9d-4131-4a6c-9367-3c397d380101&token=tGzv3JOkF0XG5Qx2TlKWIA

The authorization server (Hub) will:

  1. Require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements)

  2. Authenticate the client if client authentication is included and ensure that the access token was issued to the authenticated client.

  3. Validate the access token.

If the access token is valid and authorized, Hub issues an access token in exchange. The client can then use the Hub token to make subsequent calls to the API.

If the request failed verification or is invalid, Hub returns an error response.

Error Response from Hub for the Token Exchange Request


A single ASCII [USASCII] error code from the following:

  • invalid_request - The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.

  • invalid_client - Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server may return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the Hub server will respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client.

  • invalid_grant - The provided authorization grant (e.g., authorization code, resource owner credentials) or token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.

  • unauthorized_client - The authenticated client is not authorized to use this authorization grant type.

  • unsupported_grant_type - The authorization grant type is not supported by Hub.

  • invalid_scope - The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.

Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred.
A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error.

The parameters are included in the entity-body of the HTTP response using the "application/json" media type. The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. The order of parameters does not matter and can vary.

For example:

HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" }
Last modified: 30 April 2024