Resource Owner Password Credentials

The resource owner password credentials grant type is a flow where the end user fills out an authentication form in the client application. The client application sends the credentials to the OAuth 2.0 server, which validates the credentials and returns an access token.

The server returns error messages (according the specification) when the validation fails.

+----------+
| Resource |
|  Owner   |
|          |
+----------+
     v
     |    Resource Owner
    (A) Password Credentials
     |
     v
+---------+                                  +---------------+
|         |>--(B)---- Resource Owner ------->|               |
|         |         Password Credentials     | Authorization |
| Client  |                                  |     Server    |
|         |<--(C)---- Access Token ---------<|               |
|         |    (w/ Optional Refresh Token)   |               |
+---------+                                  +---------------+

Explanation:

  1. The Resource Owner (end user of the application) enters his Quasydoc user credentials (username, password, company).
  2. The application sends the credentials to the Authorization Server (Quasydoc OAuth2 server).
  3. The Quasydoc OAuth2 server verifies the credentials and, if succesful, issues an access token.

Step (B) in detail

The client makes a HTTP POST request to the Token endpoint van de Quasydoc OAuth 2.0 server (https://quasydoc.eu/oauth/token.php).

POST parameters:

  • grant_type

    MANDATORY. Value “password”.

  • username

    MANDATORY. Quasydoc username and company (“username”+@+”“company) of the Resource Owner.

  • password

    MANDATORY. Quasydoc password of the Resource Owner.

  • scope

    MANDATORY. (not mandatory according the OAuth 2.0 specification, but necessary for Quasydoc).

  • client_id

    MANDATORY. Id of the application (defined by Quasydoc).

  • client_secret

    MANDATORY. Secret code of the application (defined by Quasydoc).

The client_id and client_secret can be sent in one of the following ways:

  • Via POST parameters

    parameters ‘client_id’ and ‘client_secret’

  • Via the HTTP Authorization request-header field

    with the base64 encoded value of the client_id and client_secret separated by a single colon.

    Authorization: Basic base64(client_id+’:’+client_secret)

    e.g.

    Authorization: Basic aWQ6c2VjcmV0

Example request

 POST /oauth/token.php HTTP/1.1
 Host: quasydoctest.be
 Authorization: Basic cWRfY29sbGVjdDpmQVk5YmJLWg==
 Content-Type: application/x-www-form-urlencoded

grant_type=password&username=test@quasydoc&password=A3ddj3w&scope=prodords

Step (C) in detail

When the Authorization server validates the request, the response looks as follows:

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

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "scope": "prodords"
}

The response body is a JSON object with the following members:

  • access_token

    The token for the API calls.

  • token_type

    For Quasydoc this will always have the value “Bearer”.

  • expires_in

    Number of seconds after which the issued access token expires (default: 1 hour).

  • refresh_token

    The refresh token can ben used to request a new access token (refresh tokens have a longer expiration time)

  • scope

    MANDATORY (not mandatory according the OAuth 2.0 specification, but necessary for Quasydoc).