Extremely Serious

Category: OAuth2

The Resource Owner Password Credential (ROPC) Grant Type

The resource owner password credential grant type is designed as a stop-gap for legacy applications. Should only be used temporarily until the migration of the application to OAUTH is complete. This grant type should never be used anymore. This type can request for offline_access scope (i.e. to request for refresh token).

  1. Use the token end point to do post request for the access token with the following headers:

    Content-Type = application/x-www-form-urlencoded

    And with the following form data:

    grant_type = password
    client_id = the one used from step 1.
    client_secret = 
    username = 
    password = 
    scope = (Optional) what permision wanted. If not specified, default permission will be given.
    state = (Optional) value to echo to us.

    Expected Response

    {
    "access_token" : <ACCESS_TOKEN>,
    "token_type" : "Bearer",
    "expires_in" : 3600,
    "scope" : <The scope allowed by the server>
    }
  2. Call the API with the authorization header like the following syntax:

    Bearer <ACCESS_TOKEN>

Related Post
KEYCLOAK – JWT GENERATION – PASSWORD GRANT TYPE

Keycloak – Realm – OpenID Configuration

The open id configuration exposes some information like the following:

  • Authorization endpoint
  • Token endpoint
  • Supported grant types
  • Supported response types
  • Supported response modes
  • Supported claims
  • Supported scopes

Use the following address syntax to find-out the OpenID configuration:

<KEYCLOAK_ADDRESS>/realms/<TARGET_REALM>/.well-known/openid-configuration

Example

Given

Token Value
KEYCLOAK_ADDRESS http://localhost:8080
TARGET_REALM test

The OpenID configuration would be:

http://localhost:8080/realms/testrealm/.well-known/openid-configuration

Keycloak – JWT Generation – Password Grant Type

Pre-requisite

  • Keycloak 19^1

Creating a New Client and User

  1. Sign in to keycloak admin console using the following address:

    Must know a valid credential.

    http://localhost:8080/admin/

  2. Switch or create a realm that is NOT a master realm (i.e. leave the master realms for keycloak usage only), like the following (i.e. jwtrealm):
    jwt-realm

  3. Create a new client as follows:

    1. Ensure that OpenID Connect is the Client type.

    2. Provide a Client ID (e.g. jwtclient).

    3. Click the Next button.

      client-general-settings

    4. Enable the Client authentication.

    5. In the Authentication flow, unselect the standard flow.

    6. Click the Save button.

      client-capability-config

  4. Create a new user as follows:

    1. Fill-in the username field (e.g. testuser).

    2. Click the Create button.

      user-create

    3. Click the Credentials tab.

    4. Click the Set password button.

    5. Fill-in the Password field.

    6. Fill-in the Password confirmation field.

    7. Turn-off temporary.

    8. Click the Save button.

      user-password

    9. Click the Save password button.

Using Postman for Testing

  1. Create a post request to the following address format:

    http://localhost:8080/realms/<TARGET_REALM>/protocol/openid-connect/token

    Example

    Using the jwtrealm as the TARGET_REALM (i.e. configured in the previous section).

    http://localhost:8080/realms/jwtrealm/protocol/openid-connect/token

  2. Click the Body tab.

  3. Select x-www-form-url-encoded.

  4. Add the following entries:

    Key Value Comment
    client_id jwtclient This is the client configured earlier.
    grant_type password This is for direct access grant type.
    client_secret <Client secret> This can be found in the jwtclient (i.e. configured earlier) client credentials tab.

    client-secret

    scope openid The openid scope is required; to indicate that the application intends to use OIDC to verify the user's identity.
    username testuser This is the user configured earlier.
    password <password> This is the password for the user that is configured earlier.
  5. Click the Send button.

    postman-request

Success Output

The success output is in the following format.

{
    "access_token": "The access token.",
    "expires_in": "Access token expiration.",
    "refresh_expires_in": "Refresh token expiration",
    "refresh_token": "The refresh token.",
    "token_type": "Bearer",
    "id_token": "The ID token.",
    "not-before-policy": 0,
    "session_state": "The session state.",
    "scope": "openid profile email"
}

You paste the encoded token to the following website to decode its content:

https://jwt.io/

Invalid Credential Output

{
    "error": "invalid_grant",
    "error_description": "Invalid user credentials"
}

Related Post
THE RESOURCE OWNER PASSWORD CREDENTIAL (ROPC) GRANT TYPE

Authorization Code Grant Type

The authorization code grant type is designed for confidential clients (e.g. websites with a server back end) that can keep a secret. This type can request for offline_access scope (i.e. to request for refresh token).

  1. Use the authorization end point to request the authorization code with the following query parameters:

    response_type = code 
    client_id = the client unique code
    redirect_uri = redirection URL.
    state = (Optional) value to echo to us.
    scope = (Optional) what permision wanted. If not specified, default permission will be given.
    response_mode = (Optional) query

    A login form will be displayed if not yet filled-up before.

    Expected Response

    The redirect_uri with the following query parameters:

    code = The authorization code
    state = state value if given.
  2. Use the token end point to do post request for the access token with the following headers:

    Content-Type = application/x-www-form-urlencoded
    Authorization = Basic <CREDENTIAL>

    And with the following parameters:

    grant_type = authorization_code.
    code = The authorization code from step 1.
    redirect_uri = The used from step 1.

    Expected Response

    Header

    Content-Type: application/json
    
    {
    "access_token" : <ACCESS_TOKEN>,
    "token_type" : "Bearer",
    "expires_in" : 3600,
    "scope" : <The scope allowed by the server>
    }
  3. Call the API with the authorization header like the following syntax:

    Bearer <ACCESS_TOKEN>

Sample implementation can be found here.