Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateformegrant_types de votre application.
Par exemple, si vous souhaitez sécuriser une application mobile, le flux de code d’autorisation avec Proof Key for Code Exchange (PKCE) est le plus approprié.
Autrement, si vous souhaitez sécuriser une application côté client, comme une application monopage (SPA), et que vous ne faites pas transiter de jetons entre serveurs, le flux implicite avec Form Post est le plus approprié.
Plusieurs types d’octroi sont valides lors de l’enregistrement d’applications. Ils peuvent être répartis dans les catégories suivantes :
- Octrois conformes aux spécifications : octrois définis par des spécifications externes et conformes à celles-ci, comme Connect (OIDC).
- Octrois d’extension Auth0 : octrois propres à Auth0 qui sont conformes au mécanisme d’extension OAuth afin de prendre en charge des applications supplémentaires ou d’établir un pont entre et d’autres cadres de confiance.
- Types d’octroi Auth0 anciens : types d’octroi traditionnels pris en charge uniquement pour les clients existants. Si vous êtes un client existant, nous vous recommandons fortement de passer à une solution de rechange plus sécuritaire.
Types d’octroi disponibles
Types d’octroi conformes aux spécifications
| Type d’octroi | Description |
|---|---|
implicit | Octroi implicite |
authorization_code | Octroi avec code d’autorisation |
client_credentials | Octroi avec identifiants de l’application |
password | Octroi avec mot de passe du propriétaire de la ressource |
refresh_token | Utiliser des jetons d’actualisation |
urn:ietf:params:oauth:grant-type:device_code | Octroi d’autorisation d’appareil |
Octrois d’extension Auth0
| Type d’octroi | Description |
|---|---|
http://auth0.com/oauth/grant-type/password-realm | Utilisez un octroi d’extension semblable à l’octroi avec mot de passe du propriétaire de la ressource, qui permet d’indiquer un realm précis |
http://auth0.com/oauth/grant-type/mfa-oob | Demande d’octroi OOB pour l’authentification multifacteur |
http://auth0.com/oauth/grant-type/mfa-otp | Demande d’octroi OTP pour l’authentification multifacteur |
http://auth0.com/oauth/grant-type/mfa-recovery-code | Demande d’octroi de code de récupération pour l’authentification multifacteur |
http://auth0.com/oauth/grant-type/passwordless/otp | Demande d’octroi de connexion Passwordless intégrée |
Octrois Auth0 anciens
http://auth0.com/oauth/legacy/grant-type/rohttp://auth0.com/oauth/legacy/grant-type/ro/jwt-bearerhttp://auth0.com/oauth/legacy/grant-type/delegation/refresh_tokenhttp://auth0.com/oauth/legacy/grant-type/delegation/id_tokenhttp://auth0.com/oauth/legacy/grant-type/access_token
grant_types qui doit être renseignée. Afin d’éviter tout changement de fonctionnalité pour les clients d’Auth0 à ce moment-là, nous avons renseigné la propriété grant_types pour toutes les applications existantes avec tous les octrois Auth0 anciens, les types d’octroi d’extension Auth0 et les types d’octroi conformes à la spécification.
À partir de ce moment, les nouveaux clients d’Auth0 ne pouvaient plus ajouter d’octrois Auth0 anciens à leurs applications. Les octrois Auth0 anciens sont offerts uniquement aux anciens clients pendant leur migration vers de nouveaux flux, afin d’éviter des changements incompatibles. Si vous étiez client avant le 8 juin 2017, vous pouvez activer un octroi Auth0 ancien à l’aide de l’ ou de l’ d’Auth0.
Si vous utilisez actuellement un octroi Auth0 ancien, consultez le tableau ci-dessous pour déterminer laquelle des solutions sécurisées vous devriez utiliser à la place. Par exemple, si vous mettez en œuvre l’,
utilisez Universal Login au lieu du point de terminaison oauth/ro.
Correspondance des types d’octroi
Applications publiques
token_endpoint_auth_method défini sur none. Par défaut, Auth0 crée des applications publiques avec les grant_types suivants activés :
implicitauthorization_coderefresh_token
device_code.
Les applications publiques ne peuvent pas utiliser le type d’octroi client_credentials. Pour utiliser ce type d’octroi, vous devez configurer l’application comme confidentielle plutôt que publique. Utilisez le point de terminaison de l’Auth0 Management API Mettre à jour une application pour définir token_endpoint_auth_method sur client_secret_post, client_secret_basic ou private_key_jwt. Pour en savoir plus, consultez Identifiants de l’application.
Applications confidentielles
token_endpoint_auth_method est défini à une valeur autre que none. Par défaut, Auth0 crée des applications confidentielles avec les grant_types suivants activés :
implicitauthorization_coderefresh_tokenclient_credentials
Applications de première partie de confiance
grant_types activés que les applications confidentielles, ainsi que les suivants :
passwordhttp://auth0.com/oauth/grant-type/password-realmhttp://auth0.com/oauth/grant-type/mfa-oobhttp://auth0.com/oauth/grant-type/mfa-otphttp://auth0.com/oauth/grant-type/mfa-recovery-code
Password ou MFA à votre application. Vous ne pouvez pas les sélectionner individuellement.
Restrictions applicables aux applications tierces
| Type d’octroi | Disponible pour les applications tierces |
|---|---|
authorization_code | Oui (PKCE obligatoire) |
refresh_token | Oui |
client_credentials | Oui (applications confidentielles uniquement) |
implicit | Non |
password | Non |
urn:ietf:params:oauth:grant-type:device_code | Non |
| Octrois MFA | Non |
| Octrois anciens | Non |