Consentement de l’utilisateur et applications tierces
Découvrez comment Auth0 gère le consentement de l’utilisateur lorsque des applications demandent l’accès à des API en son nom.
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 autorisations 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 demande d’autorisation. Pour les applications de première partie, le consentement peut être omis 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 autorisations demandées par l’application.La demande d’autorisation suivante affiche une boîte de dialogue de consentement demandant à l’utilisateur d’approuver les autorisations read:posts et write:posts pour l’API :
Si l’utilisateur approuve, Auth0 crée une autorisation utilisateur qui représente son consentement à cette combinaison d’application, d’API et de scopes demandés. 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 explicitement révoqué.
Les applications tierces dotées de contrôles de sécurité renforcés ne prennent pas en charge les scopes OIDC (openid, profile, email) dans cette version. La boîte de dialogue de consentement affiche uniquement les scopes de l’API. La prise en charge d’OIDC pour les applications tierces est prévue dans une prochaine version.
Par défaut, la page de consentement utilise les noms des scopes pour demander le consentement de l’utilisateur. Comme illustré ci-dessous, définissez les scopes au format action:resource_name pour qu’ils s’affichent clairement :
La page de consentement regroupe les scopes d’une même API et affiche toutes les actions sur une seule ligne. Par exemple, la configuration ci-dessus produit Publications : lire et écrire vos publications.Pour afficher le champ Description au lieu du nom du scope, définissez l’indicateur use_scope_descriptions_for_consent du locataire sur true :Ce paramètre s’applique aux demandes de consentement pour toutes les API du locataire.
Lorsqu’un utilisateur refuse de donner son consentement, le comportement dépend de la stratégie de redirection de l’application :
open_redirect_protection (par défaut pour les applications tierces) : Auth0 affiche une page d’erreur au lieu d’effectuer une redirection. Cela empêche les attaques par redirection ouverte.
allow_always : Auth0 redirige vers le redirect_uri avec une erreur access_denied :
Ignorer le consentement pour les applications de première partie
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 au bouton bascule Allow Skipping User Consent, sélectionnez Applications > APIs > (sélectionnez l’API) > Settings > Access Settings.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 tout de 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’identité d’une application sur le même appareil. Pour en savoir plus, consultez Measures Against Application Impersonation.
Lorsque vous utilisez le flux de mot de passe du propriétaire de la ressource, aucune boîte de dialogue de consentement n’est présentée, car 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 à consentir à chaque connexion (même s’ils ont déjà accordé une autorisation), incluez prompt=consent dans la requête /authorize :