Azure Active Directory a besoin de l'approbation de l'administrateur après avoir défini prompt =consent.

Question

Dans mon application dans Azure Active Directory, j'ai ajouté l'une des autorisations requises par l'administrateur pour l'API graphique, à savoir Group.Read.All . J'ai cliqué sur Grant Admin Consent for ... . Si je frappe /authorize en tant qu'utilisateur avec un paramètre de requête prompt=consent j'obtiendrai l'avis que je dois obtenir l'approbation de l'administrateur. Si j'atteins le point de terminaison sans aucune prompt tout fonctionne bien - je suis capable d'obtenir un jeton avec une portée correcte. Dans la documentation, j'ai lu que prompt détermine uniquement la visibilité du consentement. Pourquoi cela fonctionne-t-il ainsi ?

Answer 1

Concernant prompt=consent , OpenID Connect dit :

Le serveur d'autorisation DEVRAIT demander le consentement de l'utilisateur final avant de renvoyer les informations au client. S'il ne peut pas obtenir le consentement, il DOIT renvoyer une erreur, typiquement consent_required .

Dans la plateforme Microsoft Identity, cela signifie que l'utilisateur final sera requis de donner son consentement, même si celui-ci a été accordé précédemment par l'utilisateur ou (dans le cas de comptes professionnels ou scolaires, par un administrateur au nom de l'utilisateur).

Si l'utilisateur n'est pas autorisé à consentir aux autorisations demandées (par exemple parce que le consentement de l'utilisateur est désactivé ou restreint), l'utilisation de la fonction prompt=consent se traduira toujours par un blocage dur pour l'utilisateur.

Dans la plupart des cas, l'utilisation de prompt=consent es no la meilleure approche. Il existe généralement trois scénarios prompt=consent est prise en compte :

1. Vous avez changé les permissions requises . Les autorisations requises ont changé (par exemple, des autorisations ont été ajoutées ou supprimées), et l'utilisateur doit consentir au nouvel ensemble d'autorisations.
2. Vous voulez informer l'utilisateur . Le développeur d'applications souhaite s'assurer que l'utilisateur est informé des autorisations que l'application sera autorisée à exercer (même si un administrateur a déjà donné son consentement au nom de l'utilisateur en question).
3. Vous devez obtenir le consentement de l'utilisateur lui-même, et non d'un administrateur. . Le développeur d'applications souhaite s'assurer que l'utilisateur final donne lui-même son consentement, indépendamment de ce qu'un administrateur a pu autoriser auparavant.

Si vous avez modifié les permissions requises

Lorsque les autorisations demandées sont définies de manière dynamique

Sur le point de terminaison v2.0 le scope peut être utilisé pour dynamiquement demander une liste de permissions déléguées. Par exemple, pour demander le read y export les permissions déléguées de l'API identifiée par https://api.example.com :

scope=openid https://api.example.com/read

Azure AD s'assurera que toutes les autorisations demandées ont été accordées et tentera de demander le consentement pour les autorisations qui n'ont pas encore été accordées (et uniquement pour celles-ci). Si les autorisations demandées ont toutes été accordées, le jeton émis comprendra toutes les autorisations accordées (même si elles n'ont pas été spécifiquement demandées).

En règle générale, lorsque vous utilisez la capacité de consentement incrémentiel du point de terminaison v2.0, prompt=consent devrait no être utilisé. Azure AD se chargera de demander le consentement incrémentiel si nécessaire.

Lorsque les autorisations demandées sont définies de manière statique

Une application peut également identifier uniquement la ressource (c'est-à-dire l'API) pour laquelle elle demande un jeton d'accès, les autorisations spécifiques étant définies de manière statique pour l'application. En utilisant le point de terminaison v2.0, cela se fait dans le champ scope en utilisant le paramètre le spécial .default valeur de la permission :

scope=openid https://api.example.com/.default

En le point de terminaison v1.0 ce qui a été réalisé en utilisant le resource paramètre :

resource=https://api.example.com

La liste des autorisations requises est configurée dans une liste statique lors de l'enregistrement de l'application. Dans le portail Azure, cette liste se trouve sous la rubrique Permissions configurées dans Azure AD > App registrations > API permissions. Dans la rubrique Application dans Microsoft Graph (et dans le manifeste de l'application ), il est stoqué dans le requiredResourceAccess propriété.

À la réception d'une demande de ce type (sur le point de terminaison v1 ou v2), Azure AD vérifie quelles autorisations ont été accordées pour la ressource demandée :

1. Si pas de des autorisations déléguées ont été accordées pour la ressource demandée OU si prompt=consent est utilisé, Azure AD tentera de demander toutes les autorisations requises à partir de la liste définie de manière statique. Cela inclut les autorisations pour les autres API, si elles sont configurées.
2. Si cualquier une autorisation déléguée a été accordée pour la ressource demandée, Azure AD émettra le jeton avec toutes les autorisations accordées. Le site scopes paramètre de la réponse comprendra la liste des permissions incluses dans le jeton d'accès.

Les applications qui s'appuient sur des autorisations requises définies de façon statique (c'est-à-dire /.default sur v2 ou resource sur v1) devrait no utiliser prompt=consent pour chaque demande de connexion. Au lieu de cela, l'application devrait :

1. Effectuer une ouverture de session sans prompt=consent .
2. Vérifiez le scope du paramètre réponse :
   • Si les autorisations souhaitées sont répertoriées, aucune autre action n'est nécessaire.
   • Dans le cas contraire (par exemple, si une nouvelle autorisation a été ajoutée à la liste des autorisations requises après que l'utilisateur a initialement consenti à l'application), alors seulement l'utilisateur doit-il être renvoyé à nouveau, cette fois-ci avec prompt=consent .

Cette stratégie garantit que les utilisateurs peuvent se connecter à une application lorsqu'un administrateur a donné son consentement en leur nom (par exemple parce qu'ils ne sont pas autorisés à donner leur propre consentement), et ne force l'invite de consentement (ou une escalade vers un administrateur pour qu'il donne son consentement en leur nom) que lorsqu'une nouvelle autorisation a été configurée.

Si vous voulez informer l'utilisateur

Utilisation de prompt=consent n'est pas une bonne approche si le but est de seulement informer l'utilisateur des permissions que l'application a été autorisée à exercer (soit par l'utilisateur précédemment, soit par un administrateur au nom de l'utilisateur).

Au lieu de cela, une application peut utiliser le scope du paramètre de la réponse du jeton pour construire l'expérience d'interruption souhaitée (par exemple, après que l'utilisateur a été redirigé vers l'application et que le jeton a été récupéré, mais avant de continuer), en informant l'utilisateur des autorisations qui lui ont été accordées.

Si vous exigez le consentement de l'utilisateur, et non d'un administrateur

Il peut exister des cas très spécifiques où une application requiert utilisateur consentement pour les permissions demandées, et souhaite no accepter le consentement accordé au nom de l'utilisateur par un administrateur.

Dans ce cas, l'utilisation de prompt=consent dans toutes les ouvertures de session pourrait être utilisé, mais il y a des mises en garde importantes à prendre en compte :

• Dans de nombreuses organisations, le consentement de l'utilisateur est désactivé ou restreint. Si les utilisateurs ne sont pas autorisés à consentir aux permissions configurées pour votre application, ils ne pourront pas l'utiliser.
• L'utilisateur sera invité à donner son consentement lors de chaque connexion, même s'il a déjà donné son consentement auparavant.
• Étant donné qu'il s'agit d'un paramètre de requête, un utilisateur averti pourrait très facilement intercepter la requête avant qu'elle ne soit effectuée, et supprimer le paramètre prompt=consent (et si le consentement a déjà été accordé précédemment, ils ne seront pas invités à le demander).

Dans ce cas, il peut être préférable que l'application mette en place une expérience de consentement séparée. après l'utilisateur s'est connecté (comme dans le scénario "informer" décrit précédemment), ce qui sépare les exigences supplémentaires de l'application en matière de consentement de l'expérience de consentement fournie par la plate-forme d'identité de Microsoft.

Answer 2

prompt=consent déclenche la boîte de dialogue de consentement OAuth après la connexion de l'utilisateur, en lui demandant d'accorder des autorisations à l'application.

Les personnes accédant à une application qui requiert au moins une autorisation qui ne relève pas de leur compétence.

Les administrateurs verront la même demande d'autorisation et verront un contrôle supplémentaire sur la demande de consentement traditionnelle qui leur permettra de consentir au nom de l'ensemble du locataire.

Les utilisateurs ne pourront pas donner leur consentement à l'application, et il leur sera demandé de demander à leur administrateur d'y accéder.

Pour plus de détails, vous pouvez vous référer à ce qui suit article .