Resource Owner Password Credentials exchange

Adoption Guide

This document is part of the adoption guide for OIDC-conformant authentication. If you haven't already, we strongly suggest reading the introduction before reading this document.

The Resource Owner Password Credentials exchange is used by highly-trusted clients to provide active authentication. Unlike the authorization code and implicit grants, this authentication mechanism does not redirect users to Auth0. It authenticates users with a single request, exchanging their password credentials for a token. This document describes the differences of this flow between the legacy and OIDC-conformant authentication pipelines.

Authentication request

POST /oauth/ro HTTP 1.1
Content-Type: application/json
{
  "grant_type": "password",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w",
  "connection": "my-database-connection",
  "scope": "openid email favorite_color offline_access",
  "device": "my-device-name"
}
POST /oauth/token HTTP 1.1
Content-Type: application/json
{
  "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w",
  "realm": "my-database-connection",
  "scope": "openid email offline_access",
  "audience": "https://api.example.com"
}
  • The endpoint to execute token exchanges is /oauth/token.
  • Auth0's own grant type is used to authenticate users from a specific connection (realm). The standard OIDC password grant is also supported, but it does not accept Auth0-specific parameters such as realm.
  • favorite_color is no longer a valid scope.
  • The device parameter is removed.
  • The audience parameter is optional.

Authentication response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • The returned access token is only valid for calling the /userinfo endpoint.
  • A refresh token will be returned only if a device parameter was passed and the offline_access scope was requested.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "eyJ...",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • The returned access token is valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) and optionally the resource server specified by the audience parameter.
  • The ID token will be forcibly signed using RS256 if requested by a public client.
  • A refresh token will be returned only if the offline_access scope was granted.

ID token structure

{
    "sub": "auth0|alice",
    "iss": "https://YOUR_AUTH0_DOMAIN/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "favorite_color": "blue"
}
{
    "sub": "auth0|alice",
    "iss": "https://YOUR_AUTH0_DOMAIN/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "https://app.example.com/favorite_color": "blue"
}
  • The ID token will be forcibly signed using RS256 if requested by a public client.
  • The favorite_color claim must be namespaced and added through a rule.

Access token structure (optional)

SlAV32hkKG
{
    "sub": "auth0|alice",
    "iss": "https://YOUR_AUTH0_DOMAIN/",
    "aud": [
        "https://api.example.com",
        "https://YOUR_AUTH0_DOMAIN/userinfo"
    ],
    "azp": "123",
    "exp": 1482816809,
    "iat": 1482809609,
    "scope": "openid email"
}
  • The returned access token is a JWT valid for calling the /userinfo endpoint (provided that the API specified by the audience param uses RS256 as signing algorithm) as well as the resource server specified by the audience parameter.
  • Note that an opaque access token could still be returned if /userinfo is the only specified audience.

Standard password grant requests

The Auth0 password realm grant is not defined by standard OIDC, but it is suggested as an alternative to the legacy resource owner endpoint because it supports the Auth0-specific realm parameter. The standard OIDC grant is also supported when using OIDC authentication.

Further reading