Types d’autorisation d’application

Les types d’autorisation d’application (ou flux) sont des méthodes par lesquelles les applications peuvent obtenir des Jetons d’accès et par lesquelles vous accordez un accès limité à vos ressources à une autre entité sans exposer des identifiants. Le protocole OAuth 2.0 prend en charge plusieurs types d’autorisation, qui permettent différents types d’accès.

En fonction des besoins de votre demande, certains types d’autorisations sont plus appropriés que d’autres. Auth0 fournit de nombreux flux d’authentification et d’autorisation différents et vous permet d’indiquer quels types d’autorisation sont appropriés en fonction de la propriété grant_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 pertinent.

Par ailleurs, si vous souhaitez sécuriser une application côté client, telle qu’une application à page unique, et que vous ne transmettez pas de jetons entre les serveurs, le Flux implicite avec Form Post est le plus pertinent.

Différents types d’autorisations sont valables lors de l’enregistrement d’applications. Ils peuvent être classés dans les catégories suivantes :

• Autorisations conformes aux spécifications : Autorisations définies par des spécifications externes et conformes à celles-ci, telles que OpenID Connect (OIDC).

• Auth0 extension grants (Autorisations d’extension Auth0) : Autorisations spécifiques à Auth0 conformes au OAuth extension mechanism (mécanisme d’extension d’OAuth) afin de prendre en charge des clients supplémentaires ou d’établir une passerelle entre OAuth et d’autres cadres d’applications de confiance.

• Autorisations héritées Auth0 : Types d’autorisation traditionnelles prises en charge pour les clients hérités uniquement. Si vous êtes un client hérité, nous vous recommandons vivement de passer à une solution plus sûre.

Les autorisations héritées comprennent

• http://auth0.com/oauth/legacy/grant-type/ro

• http://auth0.com/oauth/legacy/grant-type/ro/jwt-bearer

• http://auth0.com/oauth/legacy/grant-type/delegation/refresh_token

• http://auth0.com/oauth/legacy/grant-type/delegation/id_token

• http://auth0.com/oauth/legacy/grant-type/access_token

Les types d’autorisations héritées sont des types d’autorisations traditionnels qui ne sont prises en charge que pour les clients hérités. Si vous êtes un client hérité, nous vous recommandons vivement de passer à une solution plus sûre.

Depuis le 8 juin 2017, toutes les applications ont reçu une propriété grant_types qui doit être renseignée. Pour éviter les changements de fonctionnalité pour les clients Auth0 à ce moment-là, nous avons renseigné la propriété grant_types pour toutes les applications existantes avec tous les types d’autorisation hérités d’Auth0, d’extensions Auth0 et conformes aux spécifications.

À ce moment, les nouveaux clients d’Auth0 ne sont plus en mesure d’ajouter des types d’autorisations héritées à leurs applications. Les types d’autorisations héritées ne sont disponibles que pour les clients hérités pendant qu’ils migrent vers les nouveaux flux, afin les modifications majeures (« breaking changes »). Si vous étiez client avant le 8 juin 2017, vous pouvez activer un type d’autorisation héritée en utilisant l’Auth0 Dashboard ou de Management API Auth0.

Si vous utilisez actuellement un type d’autorisation héritée, consultez le tableau ci-dessous pour savoir laquelle des solutions de rechange sécurisées vous devriez plutôt utiliser. Par exemple, si vous mettez en œuvre l’authentification sans mot de passe,

Utilisez Connexion universelle au lieu du point de terminaison oauth/ro.

Lorsqu’elles sont enregistrées, les applications ont accès à différents types d’autorisations en fonction du type d’application, en particulier si l’application est privée ou publique. En outre, les applications tierces de confiance ont accès à des types d’autorisations supplémentaires.

Lorsqu’une application native ou une application à page unique (Single-Page Application/SPA) est enregistrée dans le Dashboard, elle est automatiquement marquée comme une application publique, ce qui est indiqué par le drapeau token_endpoint_auth_method qui est défini sur none. Par défaut, Auth0 crée des applications publiques avec les grant_types suivants activés :

• implicit

• authorization_code

• refresh_token

Les applications natives peuvent également utiliser le type d’autorisation device_code.

Les applications publiques ne peuvent pas utiliser le type d’autorisation client_credentials. Pour utiliser ce type d’autorisation, vous devez configurer l’application de manière à ce qu’elle soit privée plutôt que publique. Utilisez le point de terminaison de l’Auth0 Management API Mettre à jour un client 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.

Lorsqu’une application Web classique ou une application de communication entre machines est enregistrée dans le Tableau de bord Auth0, elle est automatiquement marquée comme une application confidentielle, ce qui est signalé par l’indicateur token_endpoint_auth_method défini sur une valeur autre que none. Par défaut, Auth0 crée des applications confidentielles avec les grant_types suivants activés :

• implicit

• authorization_code

• refresh_token

• client_credentials

Les applications de confiance de première partie ont les mêmes grant_types activés que les applications confidentielles, ainsi que les éléments suivants :

• password

• http://auth0.com/oauth/grant-type/password-realm

• http://auth0.com/oauth/grant-type/mfa-oob

• http://auth0.com/oauth/grant-type/mfa-otp

• http://auth0.com/oauth/grant-type/mfa-recovery-code

Si vous utilisez le Dashboard pour activer ou désactiver ces types d’autorisation, sachez que tous les types d’autorisation par mot de passe et MFA sont activés lorsque vous ajoutez le type d’autorisation Password ou MFA à votre application. Vous ne pouvez pas les sélectionner individuellement.

• Applications confidentielles et publiques
• Activer les applications tierces
• Applications de première et de tierce partie
• Paramètres fictifs d'URL de sous-domaine