Flux Resource Owner Password avec OIDC

Découvrez comment le pipeline conforme à OIDC influe sur le flux Resource Owner Password (ROP).

Le Resource Owner Password Flow (parfois appelé Resource Owner Password Grant ou ROPG) est utilisé par des applications hautement dignes de confiance pour effectuer une authentification active. Contrairement au code d’autorisation et aux octrois implicites, ce mécanisme d’authentification ne redirige pas les utilisateurs vers Auth0. Il authentifie les utilisateurs au moyen d’une seule requête, en échangeant leurs identifiants et leur mot de passe contre un jeton.

Le pipeline conforme à OIDC affecte le Resource Owner Password Flow dans les domaines suivants :

• Requête d’authentification
• Réponse d’authentification
• Structure du jeton d’ID
• Structure du jeton d’accès

​

Requête d’authentification

​

Ancienne version

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

Le paramètre device n’est nécessaire que si vous demandez un refresh token en incluant la portée offline_access.

​

Conforme à OIDC

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

• Le point de terminaison pour effectuer les échanges d’identifiants est /oauth/token.
• Le grant type propre à Auth0 est utilisé pour authentifier les utilisateurs d’une connexion précise (realm). Le grant de mot de passe OIDC standard est aussi pris en charge, mais il n’accepte pas les paramètres propres à Auth0, comme realm.
• favorite_color n’est plus un scope valide.
• Le paramètre device a été supprimé.
• Le paramètre audience est facultatif.

​

Réponse d’authentification

​

Ancienne version

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

• Le jeton d’accès retourné est valide uniquement pour appeler le point de terminaison /userinfo.
• Un jeton d’actualisation sera retourné seulement si un paramètre device a été transmis et si la portée offline_access a été demandée.

​

Conforme à OIDC

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

• Le jeton d’accès renvoyé est valide pour effectuer une requête vers le endpoint /userinfo (à condition que l’API précisée par le paramètre audience utilise RS256 comme algorithme de signature) et, au besoin, vers le serveur de ressources précisé par le paramètre audience.
• Le jeton d’ID sera obligatoirement signé avec RS256 s’il est demandé par une application publique. Pour en savoir plus, consultez Applications confidentielles et publiques.
• Un jeton d’actualisation sera renvoyé seulement si la portée offline_access a été accordée.

​

Structure du jeton d’ID

​

ancienne version

​

Conforme à OIDC

• Le jeton d’ID sera obligatoirement signé avec RS256 s’il est demandé par une application publique.
• La revendication favorite_color doit être associée à un espace de noms et ajoutée au moyen d’une règle. Pour en savoir plus, consultez Create Namespaced Custom Claims.

​

Structure du jeton d’accès (facultatif)

​

Ancienne version

JSON

SlAV32hkKG

Le jeton d’accès renvoyé est opaque et n’est valide que pour effectuer une requête au point de terminaison /userinfo.

​

Conforme à OIDC

• Le jeton d’accès renvoyé est un JWT valide pour envoyer une requête au point de terminaison /userinfo (à condition que l’API spécifiée par le paramètre audience utilise RS256 comme algorithme de signature), ainsi qu’au serveur de ressources spécifié par le paramètre audience.
• Notez qu’un jeton d’accès opaque peut tout de même être renvoyé si /userinfo est la seule audience spécifiée.

​

Requêtes standard d’octroi par mot de passe

L’octroi par mot de passe avec realm d’Auth0 n’est pas défini par la norme OIDC, mais il est proposé comme solution de rechange au point de terminaison Resource Owner existant, car il prend en charge le paramètre realm propre à Auth0. Le flux OIDC standard est également pris en charge lorsque l’authentification OIDC est utilisée.

​

Pour en savoir plus

• Jetons d’accès avec OIDC
• API externes avec OIDC
• Flux de code d’autorisation avec OIDC
• Flux d’identifiants du client avec OIDC
• Flux implicite avec OIDC
• Jetons d’actualisation avec OIDC