Resource Owner Password Credentials - Help

Reference to the Standard

Specification for the Resource Owner Password Credentials Flow (RFC 6749)

Prerequisites

Client knows user credentials and accesses resources on behalf of a user.

For example, client is the device operating system or a highly privileged application.

This grant type is suitable for clients capable of obtaining the resource owner's credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

Access Token Request

The client makes a request to the token endpoint 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:

grant_type: Required. Value must be set to "password".
username: Required. The resource owner username.
password: Required. The resource owner password.
scope: Required. 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.
access_type: Indicates whether the application requires access to Hub when the user is not online. Allowed values: online (used by default) and offline. If the application requires refreshing access tokens when the user is not online, use the offline value. In this case Hub issues a refresh token for the application the first time it exchanges an authorization code for a user. Refer to the Refresh Token page for more information.

The request must contain the "Authorization" header in the following format:

Authorization: Basic base64(service_id + ":" + service_secret)

For example: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

The service is not required to be trusted in Hub.

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: hub.company.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

Access Token Response

If the access token request is valid and authorized, the Hub server issues an access token and refresh token. If the request failed client authentication or is invalid, the authorization server returns an error response as described in the next section.

An example successful response:

HTTP/1.1 200 OK
            Content-Type: application/json;charset=UTF-8
            Cache-Control: no-store
            Pragma: no-cache

            {
            "access_token":"2YotnFZFEjr1zCsicMWpAA",
            "token_type":"example",
            "expires_in":3600,
            "example_parameter":"example_value"
            }

Handling Error response

If the request failed client authentication or is invalid, Hub responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response:

error

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 refresh 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.

error_description

Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred.

error_uri

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"
}