Resource Owner Password Flow with OIDC

The Resource Owner Password Flow (sometimes called Resource Owner Password Grant or ROPG) is used by highly-trusted applications 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.

The OIDC-conformant pipeline affects the Resource Owner Password Flow in the following areas:

• Authentication request

• Authentication response

• ID token structure

• Access token structure

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

The device parameter is only needed if requesting a refresh token by passing the offline_access scope.

POST /oauth/token HTTP 1.1
Content-Type: application/x-www-form-urlencoded
grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fpassword-realm&client_id=123&username=alice&password=A3ddj3w&realm=my-database-connection&scope=openid+email+offline_access&audience=https%3A%2F%2Fapi.example.com

• The endpoint to execute credential 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.

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 application. To learn more, read Confidential and Public Applications.

• A refresh token will be returned only if the offline_access scope was granted.

{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "favorite_color": "blue"
}

{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "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 application.

• The favorite_color claim must be namespaced and added through a rule. To learn more, read Create Namespaced Custom Claims.

SlAV32hkKG

The returned Access token is opaque and only valid for calling the /userinfo endpoint.

{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": [
        "https://api.example.com",
        "https://{yourDomain}/userinfo"
    ],
    "azp": "123",
    "exp": 1482816809,
    "iat": 1482809609,
    "scope": "openid email"
}

• The returned access token is a JWT valid for calling the /userinfo endpoin (provided that the API specified by the audience parameter 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.

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 flow is also supported when using OIDC authentication.

• Access Tokens with OIDC
• External APIs with OIDC
• Authorization Code Flow with OIDC
• Client Credentials Flow with OIDC
• Implicit Flow with OIDC
• Refresh Tokens with OIDC