Skip to main content
OAuth permet aux applications d’accéder aux API au nom de l’utilisateur. Avant qu’une application puisse agir au nom d’un utilisateur, celui-ci doit approuver explicitement les permissions demandées. Cette étape d’approbation s’appelle le consentement de l’utilisateur. Pour les applications tierces, le consentement de l’utilisateur est toujours requis. L’utilisateur doit approuver chaque requête d’autorisation. Pour les applications de première partie, il est possible de ne pas demander ce consentement lorsque cette option est configurée, puisque vous contrôlez l’application et lui faites confiance pour agir de manière appropriée. Lorsqu’une application tierce redirige un utilisateur vers le point de terminaison /authorize et demande l’accès à une API, Auth0 affiche une boîte de dialogue de consentement qui répertorie les permissions demandées par l’application. La requête d’autorisation suivante affiche une boîte de dialogue de consentement demandant à l’utilisateur d’approuver les permissions read:posts et write:posts pour l’API :
Autorisation - Consentement de l’utilisateur et applications - boîte de dialogue de consentement
Si l’utilisateur accepte, Auth0 crée une autorisation utilisateur qui représente le consentement de l’utilisateur pour cette combinaison d’application, d’API et de portées demandées. L’application reçoit un code d’autorisation comme d’habitude. Une fois le consentement accordé, l’utilisateur ne voit plus la boîte de dialogue de consentement lors des ouvertures de session suivantes, jusqu’à ce que ce consentement soit révoqué explicitement.
Les applications tierces avec des contrôles de sécurité renforcés ne prennent pas en charge les portées OIDC (openid, profile, email) dans cette version. La boîte de dialogue de consentement affiche uniquement les portées d’API. La prise en charge d’OIDC pour les applications tierces est prévue dans une version future.

​
Descriptions des portées

Par défaut, la page de consentement utilise les noms de portée pour obtenir le consentement de l’utilisateur. Comme illustré ci-dessous, définissez les portées au format action:resource_name pour un affichage clair :
Authorization - Consentement de l’utilisateur et applications - Portées de consentement
La page de consentement regroupe les portées d’une même API et affiche toutes les actions sur une seule ligne. Par exemple, la configuration ci-dessus produit Posts: lire et écrire vos publications. Pour afficher le champ Description au lieu du nom de la portée, définissez l’indicateur use_scope_descriptions_for_consent du tenant sur true :
Vous utilisez l’Auth0 CLI? Si ce n’est pas déjà fait, configurez et authentifiez votre session CLI avant d’exécuter cette commande.
Ce paramètre s’applique aux invites de consentement de toutes les API du tenant.

​
Gérer les permissions refusées

Lorsqu’un utilisateur refuse de donner son consentement, le comportement dépend de la politique de redirection de l’application :
  • open_redirect_protection (par défaut pour les applications tierces) : Auth0 affiche une page d’erreur au lieu de rediriger l’utilisateur. Cela empêche les attaques par redirection ouverte.
  • allow_always : Auth0 redirige vers le redirect_uri avec une erreur access_denied :
Les applications de première partie peuvent ignorer la boîte de dialogue de consentement lorsque l’option Allow Skipping User Consent est activée pour l’API. Pour accéder à la bascule Allow Skipping User Consent, sélectionnez Applications > APIs > (sélectionnez l’API) > Settings > Paramètres d’accès. Les applications tierces exigent toujours le consentement et ne peuvent pas ignorer la boîte de dialogue de consentement.
Même lorsque le consentement est ignoré pour les applications de première partie, une invite de confirmation de connexion peut quand même s’afficher lorsque l’application utilise un URI de rappel non vérifiable (comme localhost ou un schéma d’URI personnalisé). Cela protège les utilisateurs contre l’usurpation d’une application sur le même appareil. Pour en savoir plus, consultez Mesures contre l’usurpation d’application.
Lorsqu’une application tierce authentifie des utilisateurs dans le contexte d’une Organization, le consentement est associé à cette Organization. Un utilisateur qui consent à une application dans une Organization n’a pas consenti à cette même application dans une autre Organization.
Boîte de dialogue de consentement pour l'Organization Acme — application tierce demandant l'accès au compte Acme de l'utilisateur
Cela signifie :
  • Un utilisateur qui accède à la même application tierce à partir d’une nouvelle Organization voit de nouveau la boîte de dialogue de consentement, même s’il y avait déjà consenti dans une autre Organization.
  • La révocation du consentement dans une Organization n’a aucune incidence sur le consentement dans une autre.
  • L’autorisation est enregistrée pour chaque Organization.
Boîte de dialogue de consentement pour l'Organization Contoso — le même utilisateur doit consentir de nouveau pour une autre Organization
Pour forcer un nouveau consentement dans le contexte d’une Organization précise, incluez prompt=consent dans la requête /authorize. Pour révoquer le consentement d’un utilisateur pour une application donnée :
  1. Accédez à Auth0 Dashboard > User Management > Users.
  2. Sélectionnez l’utilisateur.
  3. Sélectionnez l’onglet Authorized Applications.
  4. Sélectionnez Revoke à côté de l’application.

​
Flux avec mot de passe

Le Resource Owner Password Flow n’est pas offert pour les applications tierces. Il s’applique uniquement aux applications de première partie. Pour les applications de première partie, aucun consentement n’est requis, puisque l’utilisateur fournit directement son mot de passe à l’application, ce qui revient à lui accorder un accès complet à son compte. Pour obliger les utilisateurs à donner leur consentement à chaque connexion (même s’ils disposent déjà d’une autorisation), incluez prompt=consent dans la requête /authorize :

​
En savoir plus