You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/conditional-access/concept-conditional-access-conditions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -127,7 +127,7 @@ On Windows 7, iOS, Android, and macOS Azure AD identifies the device using a cli
127
127
128
128
#### Chrome support
129
129
130
-
For Chrome support in **Windows 10 Creators Update (version 1703)** or later, install the [Windows 10 Accounts](https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji) or [Office Online](https://chrome.google.com/webstore/detail/office/ndjpnladcallmjemlbaebfadecfhkepb) extensions. These extensions are required when a Conditional Access policy requires device-specific details.
130
+
For Chrome support in **Windows 10 Creators Update (version 1703)** or later, install the [Windows Accounts](https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji) or [Office](https://chrome.google.com/webstore/detail/office/ndjpnladcallmjemlbaebfadecfhkepb) extensions. These extensions are required when a Conditional Access policy requires device-specific details.
131
131
132
132
To automatically deploy this extension to Chrome browsers, create the following registry key:
Copy file name to clipboardExpand all lines: articles/active-directory/develop/active-directory-v2-protocols.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ Your client app needs a way to trust the security tokens issued to it by the Mic
53
53
54
54
When you register your app in Azure AD, the Microsoft identity platform automatically assigns it some values, while others you configure based on the application's type.
55
55
56
-
Two the most commonly referenced app registration settings are:
56
+
Two of the most commonly referenced app registration settings are:
57
57
58
58
***Application (client) ID** - Also called _application ID_ and _client ID_, this value is assigned to your app by the Microsoft identity platform. The client ID uniquely identifies your app in the identity platform and is included in the security tokens the platform issues.
59
59
***Redirect URI** - The authorization server uses a redirect URI to direct the resource owner's *user-agent* (web browser, mobile app) to another destination after completing their interaction. For example, after the end-user authenticates with the authorization server. Not all client types use redirect URIs.
Copy file name to clipboardExpand all lines: articles/active-directory/develop/application-consent-experience.md
+54-20Lines changed: 54 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,24 +2,21 @@
2
2
title: Azure AD app consent experiences
3
3
description: Learn more about the Azure AD consent experiences to see how you can use it when managing and developing applications on Azure AD
4
4
services: active-directory
5
-
author: rwike77
5
+
author: omondiatieno
6
6
manager: CelesteDG
7
-
8
7
ms.service: active-directory
9
8
ms.subservice: develop
10
9
ms.custom: aaddev
11
10
ms.workload: identity
12
11
ms.topic: conceptual
13
-
ms.date: 04/18/2022
14
-
ms.author: ryanwi
15
-
ms.reviewer: jesakowi, asteen
12
+
ms.date: 11/01/2022
13
+
ms.author: jomondi
14
+
ms.reviewer: jesakowi, asteen, jawoods
16
15
---
17
16
18
-
# Understanding Azure AD application consent experiences
19
-
20
-
Learn more about the Azure Active Directory (Azure AD) application consent user experience. So you can intelligently manage applications for your organization and/or develop applications with a more seamless consent experience.
17
+
# Consent experience for applications in Azure Active Directory
21
18
22
-
## Consent and permissions
19
+
In this article, you'll learn about the Azure Active Directory (Azure AD) application consent user experience. You'll then be able to intelligently manage applications for your organization and/or develop applications with a more seamless consent experience.
23
20
24
21
Consent is the process of a user granting authorization to an application to access protected resources on their behalf. An admin or user can be asked for consent to allow access to their organization/individual data.
25
22
@@ -42,50 +39,87 @@ The following diagram and table provide information about the building blocks of
42
39
| 2 | Title | The title changes based on whether the users are going through the user or admin consent flow. In user consent flow, the title will be “Permissions requested” while in the admin consent flow the title will have an additional line “Accept for your organization”. |
43
40
| 3 | App logo | This image should help users have a visual cue of whether this app is the app they intended to access. This image is provided by application developers and the ownership of this image isn't validated. |
44
41
| 4 | App name | This value should inform users which application is requesting access to their data. Note this name is provided by the developers and the ownership of this app name isn't validated.|
45
-
| 5 | Publisher name and verification | The blue "verified" badge means that the app publisher has verified their identity using a Microsoft Partner Network account and has completed the verification process. If the app is publisher verified, the publisher name is displayed. If the app is not publisher verified, "Unverified" is displayed instead of a publisher name. For more information, read about [Publisher Verification](publisher-verification-overview.md). Selecting the publisher name displays more app info as available, such as the publisher name, publisher domain, date created, certification details, and reply URLs. |
42
+
| 5 | Publisher name and verification | The blue "verified" badge means that the app publisher has verified their identity using a Microsoft Partner Network account and has completed the verification process. If the app is publisher verified, the publisher name is displayed. If the app isn't publisher verified, "Unverified" is displayed instead of a publisher name. For more information, read about [Publisher Verification](publisher-verification-overview.md). Selecting the publisher name displays more app info as available, such as the publisher name, publisher domain, date created, certification details, and reply URLs. |
46
43
| 6 | Microsoft 365 Certification | The Microsoft 365 Certification logo means that an app has been vetted against controls derived from leading industry standard frameworks, and that strong security and compliance practices are in place to protect customer data. For more information, read about [Microsoft 365 Certification](/microsoft-365-app-certification/docs/enterprise-app-certification-guide).|
47
44
| 7 | Publisher information | Displays whether the application is published by Microsoft. |
48
-
| 8 | Permissions | This list contains the permissions being requested by the client application. Users should always evaluate the types of permissions being requested to understand what data the client application will be authorized to access on their behalf if they accept. As an application developer it is best to request access, to the permissions with the least privilege. |
45
+
| 8 | Permissions | This list contains the permissions being requested by the client application. Users should always evaluate the types of permissions being requested to understand what data the client application will be authorized to access on their behalf if they accept. As an application developer it's best to request access, to the permissions with the least privilege. |
49
46
| 9 | Permission description | This value is provided by the service exposing the permissions. To see the permission descriptions, you must toggle the chevron next to the permission. |
50
47
| 10 |https://myapps.microsoft.com| This is the link where users can review and remove any non-Microsoft applications that currently have access to their data. |
51
48
| 11 | Report it here | This link is used to report a suspicious app if you don't trust the app, if you believe the app is impersonating another app, if you believe the app will misuse your data, or for some other reason. |
52
49
53
-
## App requires a permission within the user's scope of authority
50
+
## Common scenarios and consent experiences
54
51
55
-
A common consent scenario is that the user accesses an app which requires a permission set that is within the user's scope of authority. The user is directed to the user consent flow.
52
+
The following section describes the common scenarios and the expected consent experience for each of them.
53
+
### App requires a permission that the user has the right to grant
56
54
57
-
Admins will see an additional control on the traditional consent prompt that will allow them consent on behalf of the entire tenant. The control will be defaulted to off, so only when admins explicitly check the box will consent be granted on behalf of the entire tenant. As of today, this check box will only show for the Global Admin role, so Cloud Admin and App Admin will not see this checkbox.
55
+
In this consent scenario, the user accesses an app that requires a permission set that is within the user's scope of authority. The user is directed to the user consent flow.
56
+
57
+
Admins will see an additional control on the traditional consent prompt that will allow to give consent on behalf of the entire tenant. The control will be defaulted to off, so only when admins explicitly check the box will consent be granted on behalf of the entire tenant. The check box will only show for the Global Admin role, so Cloud Admin and App Admin won't see this checkbox.
58
58
59
59
:::image type="content" source="./media/application-consent-experience/consent_prompt_1a.png" alt-text="Consent prompt for scenario 1a":::
60
60
61
61
Users will see the traditional consent prompt.
62
62
63
63
:::image type="content" source="./media/application-consent-experience/consent_prompt_1b.png" alt-text="Screenshot that shows the traditional consent prompt.":::
64
64
65
-
## App requires a permission outside of the user's scope of authority
65
+
###App requires a permission that the user has no right to grant
66
66
67
-
Another common consent scenario is that the user accesses an app which requires at least one permission that is outside the user's scope of authority.
67
+
In this consent scenario, the user accesses an app that requires at least one permission that is outside the user's scope of authority.
68
68
69
69
Admins will see an additional control on the traditional consent prompt that will allow them consent on behalf of the entire tenant.
70
70
71
71
:::image type="content" source="./media/application-consent-experience/consent_prompt_1a.png" alt-text="Consent prompt for scenario 1a":::
72
72
73
-
Non-admin users will be blocked from granting consent to the application, and they will be told to ask their admin for access to the app.
73
+
Non-admin users will be blocked from granting consent to the application, and they'll be told to ask their admin for access to the app. If admin consent workflow is enabled in the user's tenant, non-admin users are able to submit a request for admin approval from the consent prompt. For more information on admin consent workflow, see [Admin consent workflow](../manage-apps/admin-consent-workflow-overview.md).
74
74
75
75
:::image type="content" source="./media/application-consent-experience/consent_prompt_2b.png" alt-text="Screenshot of the consent prompt telling the user to ask an admin for access to the app.":::
76
76
77
-
## User is directed to the admin consent flow
77
+
###User is directed to the admin consent flow
78
78
79
-
Another common scenario is when the user navigates to or is directed to the admin consent flow.
79
+
In this consent scenario, the user navigates to or is directed to the admin consent flow.
80
80
81
81
Admin users will see the admin consent prompt. The title and the permission descriptions changed on this prompt, the changes highlight the fact that accepting this prompt will grant the app access to the requested data on behalf of the entire tenant.
82
82
83
83
:::image type="content" source="./media/application-consent-experience/consent_prompt_3a.png" alt-text="Consent prompt for scenario 3a":::
84
84
85
-
Non-admin users will be blocked from granting consent to the application, and they will be told to ask their admin for access to the app.
85
+
Non-admin users will be blocked from granting consent to the application, and they'll be told to ask their admin for access to the app.
86
86
87
87
:::image type="content" source="./media/application-consent-experience/consent_prompt_2b.png" alt-text="Screenshot of the consent prompt telling the user to ask an admin for access to the app.":::
88
88
89
+
### Admin consent through the Azure portal
90
+
91
+
In this scenario, an administrator consents to all of the permissions that an application requests, which can include delegated permissions on behalf of all users in the tenant. The Administrator grants consent through the **API permissions** page of the application registration in the [Azure portal](https://portal.azure.com).
92
+
93
+
:::image type="content" source="./media/consent-framework/grant-consent.png" alt-text="Screenshot of explicit admin consent through the Azure portal." lightbox="./media/consent-framework/grant-consent.png":::
94
+
95
+
All users in that tenant won't see the consent dialog unless the application requires new permissions. To learn which administrator roles can consent to delegated permissions, see [Administrator role permissions in Azure AD](../roles/permissions-reference.md).
96
+
97
+
> [!IMPORTANT]
98
+
> Granting explicit consent using the **Grant permissions** button is currently required for single-page applications (SPA) that use MSAL.js. Otherwise, the application fails when the access token is requested.
99
+
100
+
## Common Issues
101
+
This section outlines the common issues with the consent experience and possible troubleshooting tips.
102
+
103
+
- 403 error
104
+
105
+
- Is this a [delegated scenario](permissions-consent-overview.md)? What permissions does a user have?
106
+
- Are necessary permissions added to use the endpoint?
107
+
- Check the [token](https://jwt.ms/) to see if it has necessary claims to call the endpoint.
108
+
- What permissions have been consented to? Who consented?
109
+
110
+
- User is unable to consent
111
+
112
+
- Check if tenant admin has disabled user consent for your organization
113
+
- Confirm if the permissions you requesting are admin-restricted permissions.
114
+
115
+
- User is still blocked even after admin has consented
116
+
117
+
- Check if [static permissions](consent-types-developer.md) are configured to be a superset of permissions requested dynamically.
118
+
- Check if user assignment is required for the app.
119
+
120
+
## Troubleshoot known errors
121
+
122
+
For troubleshooting steps, see [Unexpected error when performing consent to an application](../manage-apps/application-sign-in-unexpected-user-consent-error.md).
89
123
## Next steps
90
124
91
125
- Get a step-by-step overview of [how the Azure AD consent framework implements consent](./quickstart-register-app.md).
0 commit comments