-> API connectors used in this step are in preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-|[API connectors](api-connectors-overview.md) | Preview | GA | |

-|[Secure with basic authentication](secure-rest-api.md#http-basic-authentication) | Preview | GA | |

-|[Secure with client certificate authentication](secure-rest-api.md#https-client-certificate-authentication) | Preview | GA | |

-|token_endpoint_auth_method| No | Specifies how Azure AD B2C sends the authentication header to the token endpoint. Possible values: `client_secret_post` (default), and `client_secret_basic` (public preview), `private_key_jwt` (public preview). For more information, see [OpenID Connect client authentication section](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). |

-

- ```XML

- <ValidationTechnicalProfiles>

- ....

- <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" />

- ....

- </ValidationTechnicalProfiles>

- ```

-

- "total": 300000

-You can request to increase the quota size by [contacting support](find-help-open-support-ticket.md)

-## April 2023

-### Updated articles

-[powershell-gallery]: https://www.powershellgallery.com/

-$currentAssignments = Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId

-<!-- EXTERNAL LINKS -->

-[naming-prefix]: /windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain#selecting-a-prefix

-> When a directory extension attribute in Azure AD doesn't show up automatically in your attribute mapping drop-down, you can manually add it to the "Azure AD attribute list". When manually adding Azure AD directory extension attributes to your provisioning app, note that directory extension attribute names are case-sensitive. For example: If you have a directory extension attribute named `extension_53c9e2c0exxxxxxxxxxxxxxxx_acmeCostCenter`, make sure you enter it in the same format as defined in the directory.

-> API-driven inbound provisioning is currently in public preview and is governed by [Preview Terms of Use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-> API-driven inbound provisioning is currently in public preview and is governed by [Preview Terms of Use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-1. Log in to the [Microsoft Entra portal](<https://entra.microsoft.com>).

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-1. Log in to Microsoft Entra portal with application administrator role.

-> If you'd like to add only a few additional attributes to the provisioning app, use Microsoft Entra Portal to extend the schema. If you'd like to add more custom attributes (let's say 20+ attributes), then we recommend using the [`UpdateSchema` mode of the CSV2SCIM PowerShell script](inbound-provisioning-api-powershell.md#extending-provisioning-job-schema) which automates the above manual process.

-1. Log in to Microsoft Entra portal (https://entra.microsoft.com) with global administrator or application administrator login credentials.

-You can verify the processing either from the Microsoft Entra portal or using Graph Explorer.

-### Verify processing from Microsoft Entra portal

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-You can verify the processing either from the Microsoft Entra portal or using Postman.

-### Verify processing from Microsoft Entra portal

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-1. Log in to your Entra portal as *Application Administrator* or *Global Administrator*.

-1. To associate this certificate with a valid service principal, log in to your Entra portal as *Application Administrator*.

-It doesn't refer to the attribute mappings that you perform in the Entra portal provisioning app between source SCIM schema elements and target Azure AD/on-premises AD attributes.

-description: This document describes how to configure Azure AD to provision users into SAP ECC 7.

-# Configuring Azure AD to provision users into SAP ECC 7.0

-The following documentation provides configuration and tutorial information demonstrating how to provision users from Azure AD into SAP ERP Central Component (SAP ECC) 7.0. If you are using other versions such as SAP R/3, you can still use the guides provided in the [download center](https://www.microsoft.com/download/details.aspx?id=51495) as a reference to build your own template and configure provisioning.

-* On-demand provisioning of groups supports updating up to five members at a time

-You can use Microsoft Graph and PowerShell to extend the user schema for users in Azure AD. This is necessary if you do not have any users who need that attribute and originate in on-premises Active Directory. (If you do have Active Directory, then continue reading below in the section on how to [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect).)

-Finally, verify the attribute for the user. To learn more, see [Get a user](/graph/api/user-get).

-Azure AD also supports provisioning users into applications hosted on-premises or in a virtual machine, without having to open up any firewalls. Your application must support [SCIM](https://aka.ms/scimoverview). Or, you must build a SCIM gateway to connect to your legacy application. If so, you can use the Azure AD Provisioning agent to [directly connect](./on-premises-scim-provisioning.md) with your application and automate provisioning and deprovisioning. If you have legacy applications that don't support SCIM and rely on an [LDAP](./on-premises-ldap-connector-configure.md) user store or a [SQL](./tutorial-ecma-sql-connector.md) database, Azure AD can support these applications as well.

-App provisioning lets you:

-6. Add CORS Rules (optional). For more information see [Configuring CORS Rule](/graph/api/resources/corsconfiguration_v2?view=graph-rest-beta).

-Your users wonΓÇÖt notice anything different when they sign in to use your corporate applications. They can still work from anywhere on any device. The Application Proxy connectors direct remote traffic to all apps without regard to their authentication type, so theyΓÇÖll still balance loads automatically.

-This article is for people to publish an application with this scenario for the first time. Besides detailing the publishing steps, it guides you in getting started with both Application Proxy and PingAccess. If youΓÇÖve already configured both services but want a refresher on the publishing steps, skip to the [Add your application to Azure AD with Application Proxy](#add-your-application-to-azure-ad-with-application-proxy) section.

- 1. **Internal URL**: Normally you provide the URL that takes you to the appΓÇÖs sign-in page when youΓÇÖre on the corporate network. For this scenario, the connector needs to treat the PingAccess proxy as the front page of the application. Use this format: `https://<host name of your PingAccess server>:<port>`. The port is 3000 by default, but you can configure it in PingAccess.

- > If this is your first application, use port 3000 to start and come back to update this setting if you change your PingAccess configuration. For subsequent applications, the port will need to match the Listener youΓÇÖve configured in PingAccess. Learn more about [listeners in PingAccess](https://docs.pingidentity.com/access/sources/dita/topic?category=pingaccess&Releasestatus_ce=Current&resourceid=pa_assigning_key_pairs_to_https_listeners).

-1. From the **App registrations** sidebar for your application, select **API permissions** > **Add a permission** > **Microsoft APIs** > **Microsoft Graph**. The **Request API permissions** page for **Microsoft Graph** appears, which contains the APIs for Windows Azure Active Directory.

-## Other access control considerations

-### Require user assignment

-The [Azure AD Exporter](https://github.com/microsoft/azureadexporter) can provide most of the documentation you need:

-> Settings in the legacy multifactor authentication portal for Application Proxy and federation settings might not be exported with the Azure AD Exporter, or with the Microsoft Graph API.

-* [Custom token cache serialization in MSAL for Java](../develop/msal-java-token-cache-serialization.md)

-* [Custom token cache serialization in MSAL for Python](../develop/msal-python-token-cache-serialization.md).

-

-In some rare instances where the relevant Google or Apple service responsible for push notifications is down, users may not receive their push notifications. In these cases users should manually navigate to the Microsoft Authenticator app (or relevant companion app like Outlook), refresh by either pulling down or hitting the refresh button, and approve the request.

-> [!NOTE]

-> If your organization has staff working in or traveling to China, the *Notification through mobile app* method on Android devices doesn't work in that country/region as Google play services(including push notifications) are blocked in the region. However iOS notification do work. For Android devices ,alternate authentication methods should be made available for those users.

-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-Then for ContosoΓÇÖs most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in **Passwordless MFA strength**.

-| 239 | Sao Tome and Principe |

-It might sound alarming to not ask for a user to sign back in, though any violation of IT policies revokes the session. Some examples include a password change, an incompliant device, or an account disable operation. You can also explicitly [revoke users' sessions using PowerShell](/powershell/module/azuread/revoke-azureaduserallrefreshtoken).

-Without any session lifetime settings, there are no persistent cookies in the browser session. Every time a user closes and open the browser, they get a prompt for reauthentication. In Office clients, the default time period is a rolling window of 90 days. With this default Office configuration, if the user has reset their password or there has been inactivity of over 90 days, the user is required to reauthenticate with all required factors (first and second factor).

-Under each sign-in log, go to the **Authentication Details** tab and explore **Session Lifetime Policies Applied**. For more information, see [Authentication details](../reports-monitoring/concept-sign-ins.md#authentication-details).

-| Firefox | &#10060; | &#10060; | &#10060; |

- Click **Authentication details** for [details about the MFA requirements](../reports-monitoring/concept-sign-ins.md#authentication-details).

->This is an important security enhancement for users authenticating via telecom transports. On June 26, the Microsoft managed value of this feature changed from ΓÇÿdisabledΓÇÖ to ΓÇÿenabledΓÇÖ. If you no longer wish for this feature to be enabled, move the state from 'default' toΓÇÿdisabledΓÇÖ or set users to include and exclude groups.

-By default, Authenticator Lite is [Microsoft managed](concept-authentication-default-enablement.md#microsoft-managed-settings). On June 26, the Microsoft managed value of this feature changed from ΓÇÿdisabledΓÇÖ to ΓÇÿenabledΓÇÖ

- 2. On the Enable and Target tab, click Yes and All users to enable the Authenticator policy for everyone or add selected users and groups. Set the Authentication mode for these users/groups to Any or Push.

- Only users who are enabled for Microsoft Authenticator here can be enabled to use Authenticator Lite for sign-in, or excluded from it. Users who aren't enabled for Microsoft Authenticator can't see the feature. Users who have Microsoft Authenticator downloaded on the same device Outlook is downloaded on will not be prompted to register for Authenticator Lite in Outlook. Android users utilizing a personal and work profile on their device may be prompted to register if Authenticator is present on a different profile from the Outlook application.

-<img width="1112" alt="Entra portal Authenticator settings" src="https://user-images.githubusercontent.com/108090297/228603771-52c5933c-f95e-4f19-82db-eda2ba640b94.png">

-**Phase 3** requires moving all clients that authenticate to the on-premises MFA Server (VPNs, password managers, and so on) to Azure AD federation via SAML/OAUTH. If modern authentication standards arenΓÇÖt supported, you're required to stand up NPS server(s) with the Azure AD MFA extension installed. Once dependencies are migrated, users should no longer use the User portal on the MFA Server, but rather should manage their authentication methods in Azure AD ([aka.ms/mfasetup](https://aka.ms/mfasetup)). Once users begin managing their authentication data in Azure AD, those methods won't be synced back to MFA Server. If you roll back to the on-premises MFA Server after users have made changes to their Authentication Methods in Azure AD, those changes will be lost. After user migrations are complete, change the [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0#federatedidpmfabehavior-values&preserve-view=true) domain federation setting. The change tells Azure AD to no longer perform MFA on-premises and to perform _all_ MFA requests with Azure AD MFA, regardless of group membership.

-^*When a PIN is used to provide proof-of-presence functionality, the functional equivalent is provided above. PINs that arenΓÇÖt cryptographically tied to a device don't sufficiently protect against scenarios where a device has been compromised. To protect against these scenarios, including [SIM swap attacks](https://wikipedia.org/wiki/SIM_swap_scam), move users to more secure methods according to Microsoft authentication methods [best practices](concept-authentication-methods.md).

-|**Passed Sessions tab**|All authentication method registration flows are managed by Azure AD and donΓÇÖt require configuration|

-For RADIUS deployments that canΓÇÖt be upgraded, youΓÇÖll need to deploy an NPS Server and install the [Azure AD MFA NPS extension](howto-mfa-nps-extension.md).

-For LDAP deployments that canΓÇÖt be upgraded or moved to RADIUS, [determine if Azure Active Directory Domain Services can be used](../architecture/auth-ldap.md). In most cases, LDAP was deployed to support in-line password changes for end users. Once migrated, end users can manage their passwords by using [self-service password reset in Azure AD](tutorial-enable-sspr.md).

-If you enabled the [MFA Server Authentication provider in AD FS 2.0](./howto-mfaserver-adfs-windows-server.md#secure-windows-server-ad-fs-with-azure-multi-factor-authentication-server) on any relying party trusts except for the Office 365 relying party trust, youΓÇÖll need to upgrade to [AD FS 3.0](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server) or federate those relying parties directly to Azure AD if they support modern authentication methods. Determine the best plan of action for each of the dependencies.

- - If the Windows API doesnΓÇÖt find the user or the SID isnΓÇÖt found in the MFA Server, then it will use the configured Active Directory attribute to find the user in the on-premises Active Directory, and then use the SID to search the MFA Server user list.

-1. You can migrate users even if they are unchanged. By default, the utility is set to **Only migrate users that have changed**. Click **Migrate all users** to re-migrate previously migrated users that are unchanged. Migrating unchanged users can be useful during testing if an administrator needs to reset a userΓÇÖs Azure MFA settings and wants to re-migrate them.

-MFA Methods will be updated based on what was migrated and the default method will be set. MFA Server will track the last migration timestamp and only migrate the user again if the userΓÇÖs MFA settings change or an admin modifies what to migrate in the **Settings** dialog.

-Ensure users know what to expect when they're moved to Azure MFA, including new authentication flows. You may also wish to instruct users to use the Azure AD Combined Registration portal ([aka.ms/mfasetup](https://aka.ms/mfasetup)) to manage their authentication methods rather than the User portal once migrations are complete. Any changes made to authentication methods in Azure AD won't propagate back to your on-premises environment. In a situation where you had to roll back to MFA Server, any changes users have made in Azure AD wonΓÇÖt be available in the MFA Server User portal.

-If you use third-party solutions that depend on Azure MFA Server for authentication (see [Authentication services](#authentication-services)), youΓÇÖll want users to continue to make changes to their MFA methods in the User portal. These changes will be synced to Azure AD automatically. Once you've migrated these third party solutions, you can move users to the Azure AD combined registration page.

-Once you've completed user migrations, and moved all of your [Authentication services](#authentication-services) off of MFA Server, itΓÇÖs time to update your domain federation settings. After the update, Azure AD no longer sends MFA request to your on-premises federation server.

-Users will no longer be redirected to your on-premises federation server for MFA, whether theyΓÇÖre targeted by the Staged Rollout tool or not. Note this can take up to 24 hours to take effect.

-> Sign-in to Azure AD with email as an alternate login ID is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-To enable **Report suspicious activity** from the Authentication Methods Settings:

-1. Set **Report suspicious activity** to **Enabled**.

-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms).

-| Turkey | +90 8505404893 |

-Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All

-1. Sign in to the [Entra portal](https://entra.microsoft.com/#home).

-description: Frequently asked questions (FAQs) about Microsoft Permissions Management.

-## What types of identities are supported by Permissions Management?

-Permissions Management allows users to right-size excessive permissions and automate least privilege policy enforcement with just a few clicks. The solution continuously analyzes historical permission usage data for each identity and gives customers the ability to right-size permissions of that identity to only the permissions that are being used for day-to-day operations. All unused and other risky permissions can be automatically removed.

-## What is the data destruction/decommission process?

-If a customer initiates a free Permissions Management 45-day trial, but does not follow up and convert to a paid license within 45 days of the free trial expiration, we will delete all collected data on or just before 45 days.

-If a customer decides to discontinue licensing the service, we will also delete all previously collected data within 45 days of license termination.

-We also have the ability to remove, export or modify specific data should the Global Administrator using the Entra Permissions Management service file an official Data Subject Request. This can be initiated by opening a ticket in the Azure portal [New support request - Microsoft Entra admin center](https://entra.microsoft.com/#blade/Microsoft_Azure_Support/NewSupportRequestV3Blade/callerName/ActiveDirectory/issueType/technical), or alternately contacting your local Microsoft representative.

-Although Permissions Management supports all resources, Microsoft only requires licenses for certain resources per cloud. To learn more about billable resources, visit [View billable resources listed in your authorization system](product-data-billable-resources.md)

-## How do I figure out how many resources I have?

-To find out how many resources you have across your multicloud infrastructure, select Settings (gear icon) and view the Billable Resources tab in Permissions Management.

- You have now completed onboarding AWS, and Permissions Management has started collecting and processing your data.

- You have now completed onboarding Azure, and Permissions Management has started collecting and processing your data.

-With the controller, you determine what level of access to provide Permissions Management.

-* Enable to grant read and write access to your environment(s). You can manage permissions and remediate through Permissions Management.

-* Disable to grant read-only access to your environment(s).

-> You can enable the controller in AWS if you disabled it during onboarding. Once you enable the controller, you canΓÇÖt disable it at this time.

- You've completed onboarding GCP, and Permissions Management has started collecting and processing your data.

-For more information about these authentication protocols and services, see [Sign-in activity reports in the Azure portal](../reports-monitoring/concept-sign-ins.md#filter-sign-in-activities).

-1. Navigate to the **Azure portal** > **Azure Active Directory** > **Sign-in logs**.

-Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-Target resources (formerly Cloud apps, actions, and authentication context) are key signals in a Conditional Access policy. Conditional Access policies allow administrators to assign controls to specific applications, actions, or authentication context.

-

-The following key applications are affected by the Office 365 cloud app:

-Other Microsoft admin portals will be added over time.

-> Microsoft Admin Poratls (preview) is not currently supported in Government clouds.

-Traffic forwarding profiles in Global Secure Access enable administrators to define and control how traffic is routed through Microsoft Entra Internet Access and Microsoft Entra Private Access. Traffic forwarding profiles can be assigned to devices and remote networks. For an example of how to configure these traffic profiles in Conditional Access policy, see the article [How to require a compliant network check](../../global-secure-access/how-to-compliant-network.md).

-Authentication contexts are managed in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **Authentication context**.

-

-Create new authentication context definitions by selecting **New authentication context** in the Azure portal. Organizations are limited to a total of 25 authentication context definitions. Configure the following attributes:

-| Visual Studio Team Services app | Visual Studio Team Services | Windows 10, Windows 8.1, Windows 7, iOS, and Android |

-Find these templates in the **[Microsoft Entra admin center](https://entra.microsoft.com)** > **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Create new policy from templates**. Select **Show more** to see all policy templates in each category.

-> Conditional Access template policies will exclude only the user creating the policy from the template. If your organization needs to [exclude other accounts](../roles/security-emergency-access.md), you will be able to modify the policy once they are created. Simply navigate to **Microsoft Entra admin center** > **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Policies**, select the policy to open the editor and modify the excluded users and groups to select accounts you want to exclude.

-If you do find yourself locked out, see [What to do if you're locked out of the Azure portal?](troubleshoot-conditional-access.md#what-to-do-if-youre-locked-out-of-the-azure-portal)

-1. Sign in to the **Azure portal** as at least a Global Reader.

-1. Browse to **Azure Active Directory** > **Sign-ins**.

-# Continuous access evaluation for workload identities (preview)

-The continuous access evaluation for workload identities public preview scope includes support for Microsoft Graph as a resource provider.

-The preview targets service principals for line of business (LOB) applications.

-1. Sign into the Azure portal as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Sign-in logs** > **Service Principal Sign-ins**. You can use filters to ease the debugging process.

-Customers who have configured CAE settings under Security before have to migrate settings to a new Conditional Access policy. Use the steps that follow to migrate your CAE settings to a Conditional Access policy.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Continuous access evaluation**.

-1. You have the option to **Migrate** your policy. This action is the only one that you have access to at this point.

-1. Browse to **Conditional Access** and you find a new policy named **Conditional Access policy created from CAE settings** with your settings configured. Administrators can choose to customize this policy or create their own to replace it.

-> Filter for applications is currently in public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

- For detailed steps, see [Assign Azure roles using the Azure portal](../../role-based-access-control/role-assignments-portal.md).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

-> Token protection is currently in public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Sign-in logs**.

-Customers interested in the public preview will need to opt-in using the [MAM for Windows Public Preview Sign Up Form](https://aka.ms/MAMforWindowsPublic).

-The following steps help create a Conditional Access policy requiring an app protection policy when using a Windows device. The app protection policy must also be configured and assigned to your users in Microsoft Intune. For more information about how to create the app protection policy, see the article [Preview: App protection policy settings for Windows](/mem/intune/apps/app-protection-policy-settings-windows).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

- 1. Select **Require app protection policy**

-After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.

-When users attempt to sign in to a site that is protected by an app protection policy for the first time, they're prompted: To access your service, app or website, you may need to sign in to Microsoft Edge using `username@domain.com` or register your device with `organization` if you are already signed in.

-> You must *CLEAR THE CHECKBOX* **Allow my organization to manage my device**. Leaving this checked enrolls your device in mobile device maangment (MDM) not mobile application management (MAM).

-After selecting **OK** you may see a progress window while policy is applied. After a few moments you should see a window saying "you're all set", app protection policies are applied.

-If there's a pre-existing, unregistered account, like `user@contoso.com` in Microsoft Edge, or if a user signs in without registering using the Heads Up Page, then the account isn't properly enrolled in MAM. This configuration blocks the user from being properly enrolled in MAM. This is a known issue that is currently being worked on.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **Azure portal**.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Insights and reporting**.

-1. Sign into the **Azure portal** as a Conditional Access Administrator, security administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

-In order to access the workbook, you need the proper Azure AD permissions and Log Analytics workspace permissions. To test whether you have the proper workspace permissions by running a sample log analytics query:

-1. Sign in to the **Azure portal**.

-1. Browse to **Azure Active Directory** > **Log Analytics**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **Azure portal** as a global administrator, security administrator, or Conditional Access administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Authentication strengths**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-> Misconfiguration of a block policy can lead to organizations being locked out of the Azure portal.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Named locations**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

- > Persistent Browser Session configuration in Azure AD Conditional Access overrides the ΓÇ£Stay signed in?ΓÇ¥ setting in the company branding pane in the Azure portal for the same user if you have configured both policies.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Sign-in logs**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Workbooks**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**. Here you can create or update trusted IP locations.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-Users will be blocked from accessing company resources when the device type is unknown or unsupported.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-Locations exist in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**. These named network locations may include locations like an organization's headquarters network ranges, VPN network ranges, or ranges that you wish to block. Named locations are defined by IPv4 and IPv6 address ranges or by countries/regions.

-

-

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-description: Learn how Conditional Access is at the heart of the new identity-driven control plane.

-Microsoft is providing Conditional Access templates to organizations in report-only mode starting in January of 2023. We may add more policies as new threats emerge.

-> [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RE4MwZs]

-Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action. Example: A payroll manager wants to access the payroll application and is required to do multifactor authentication to access it.

- - Users attempting to access specific applications can trigger different Conditional Access policies.

- - Signals integration with [Azure AD Identity Protection](../identity-protection/overview-identity-protection.md) allows Conditional Access policies to identify and remediate risky users and sign-in behavior.

-Administrators with the [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator) role can manage policies in Azure AD.

-Conditional Access is found in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access**.

-Risk-based policies require access to [Identity Protection](../identity-protection/overview-identity-protection.md), which is an Azure AD P2 feature.

-> Be very careful in using block and all apps in a single policy. This could lock admins out of the Azure portal, and exclusions cannot be configured for important endpoints such as Microsoft Graph.

-This article shows how to migrate a classic policy that requires **multifactor authentication** for a cloud app. Although it isn't a prerequisite, we recommend that you read [Migrate classic policies in the Azure portal](policy-migration.md) before you start migrating your classic policies.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Navigate to **Azure Active Directory** > **Security** > **Conditional Access**.

-For examples of common policies and their configuration in the Azure portal, see the article [Common Conditional Access policies](concept-conditional-access-policy-common.md).

-1. Sign in to the [Azure portal](https://portal.azure.com) as your test user.

-1. Sign in to the [Azure portal](https://portal.azure.com) as a Conditional Access Administrator, Security Administrator, or a Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

- :::image type="content" source="media/require-tou/terms-of-use-azure-ad-conditional-access.png" alt-text="Screenshot of terms of use shown in the Azure portal highlighting the new terms button." lightbox="media/require-tou/terms-of-use-azure-ad-conditional-access.png":::

- :::image type="content" source="media/require-tou/new-terms-of-use-creation.png" alt-text="Screenshot that shows creating a new terms of use policy in the Azure portal." lightbox="media/require-tou/new-terms-of-use-creation.png":::

-1. Navigate to the **Azure portal** > **Security** > **Conditional Access**

-1. Sign in to the **Azure portal** as a Conditional Access Administrator or Security Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. In the **Name** box, enter a name for the terms of use policy used in the Azure portal.

-1. Sign in to Azure and navigate to **Terms of use** at [https://aka.ms/catou](https://aka.ms/catou).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-1. Sign in to the **Azure portal** as a Global Administrator, Security Administrator, or Global Reader.

-1. Browse to **Azure Active Directory** > **Sign-ins**.

-## What to do if you're locked out of the Azure portal?

-If you're locked out of the Azure portal due to an incorrect setting in a Conditional Access policy:

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Browse to **Azure Active Directory** > **Audit logs**.

-You can find the **What If** tool in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **What If**.

-Conditional Access policies have historically applied only to users when they access apps and services like SharePoint online or the Azure portal. We're now extending support for Conditional Access policies to be applied to service principals owned by the organization. We call this capability Conditional Access for workload identities.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-1. Under **Grant**, **Block access** is the only available option. Access is blocked when a token request is made from outside the allowed range.

-1. Browse to **Azure Active Directory** > **Sign-in logs** > **Service principal sign-ins**.

-1. Browse to the **Azure portal** > **Azure Active Directory** > **Enterprise Applications**, find the application you registered.

-description: How to configure the permissions you need to access a particular API in your custom developed Azure AD application

-# How to find a specific API needed for a custom-developed application

-Access to APIs require configuration of access scopes and roles. If you want to expose your resource application web APIs to client applications, configure access scopes and roles for the API. If you want a client application to access a web API, configure permissions to access the API in the app registration.

-## Configuring a resource application to expose web APIs

-When you expose your web API, the API be displayed in the **Select an API** list when adding permissions to an app registration. To add access scopes, follow the steps outlined in [Configure an application to expose web APIs](quickstart-configure-app-expose-web-apis.md).

-## Configuring a client application to access web APIs

-When you add permissions to your app registration, you can **add API access** to exposed web APIs. To access web APIs, follow the steps outlined in [Configure a client application to access web APIs](quickstart-configure-app-access-web-apis.md).

-## Next steps

-To delegate identity and access management functions to Azure AD, an application must be registered with an Azure AD tenant. When you register your application with Azure AD, you're creating an identity configuration for your application that allows it to integrate with Azure AD. When you register an app in the Azure portal, you choose whether it's a [single tenant](single-and-multi-tenant-apps.md#who-can-sign-in-to-your-app), or [multi-tenant](single-and-multi-tenant-apps.md#who-can-sign-in-to-your-app), and can optionally set a [redirect URI](reply-url.md). For step-by-step instructions on registering an app, see the [app registration quickstart](quickstart-register-app.md).

-When you've completed the app registration, you have a globally unique instance of the app (the application object) that lives within your home tenant or directory. You also have a globally unique ID for your app (the app/client ID). In the portal, you can then add secrets or certificates and scopes to make your app work, customize the branding of your app in the sign-in dialog, and more.

-If you register an application in the portal, an application object and a service principal object are automatically created in your home tenant. If you register/create an application using the Microsoft Graph APIs, creating the service principal object is a separate step.

-You can use the **App registrations** page in the [Azure portal] to list and manage the application objects in your home tenant.

- When an application is given permission to access resources in a tenant (upon registration or consent), a service principal object is created. When you register an application using the Azure portal, a service principal is created automatically. You can also create service principal objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, and other tools.

-You can use the **Enterprise applications** page in the Azure portal to list and manage the service principals in a tenant. You can see the service principal's permissions, user consented permissions, which users have done that consent, sign in information, and more.

-In the [Azure portal](https://portal.azure.com), navigate to the application registration overview. Select **Managed application in local directory**.

-[Azure portal]: https://portal.azure.com

-Additional Apple's URLs that may need to be allowed are documented here: https://support.apple.com/en-us/HT210060

-| 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. |

-#Customer intent: As an app developer, I want to learn about authentication flows and application scenarios so I can create applications protected by the Microsoft identity platform.

-# Authentication flows and application scenarios

-Tokens can be acquired from several types of applications, including:

-## Application scenarios

-Applications running on a device without a browser can still call an API on behalf of a user. To authenticate, the user must sign in on another device that has a web browser. This scenario requires that you use the [device code flow](https://aka.ms/msal-net-device-code-flow).

-Some scenarios, like those that involve Conditional Access related to a device ID or a device enrollment, require a broker to be installed on the device. Examples of brokers are Microsoft Company Portal on Android and Microsoft Authenticator on Android and iOS. MSAL can now interact with brokers. For more information about brokers, see [Leveraging brokers on Android and iOS](https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS).

-The individual national clouds and the global Azure cloud are cloud _instances_. Each cloud instance is separate from the others and has its own environment and _endpoints_. Cloud-specific endpoints include OAuth 2.0 access token and OpenID Connect ID token request endpoints, and URLs for app management and deployment, like the Azure portal.

-You can find the authentication endpoints for your application in the Azure portal.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. Select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**, and then select **Endpoints** in the top menu.

- The **Endpoints** page is displayed showing the authentication endpoints for the application registered in your Azure AD tenant.

-description: An overview of the authentication protocols supported by the Microsoft identity platform

-# Microsoft identity platform authentication protocols

-The Microsoft identity platform supports several of the most widely used authentication and authorization protocols. The topics in this section describe the supported protocols and their implementation in Microsoft identity platform. The topics included a review of supported claim types, an introduction to the use of federation metadata, detailed OAuth 2.0. and SAML 2.0 protocol reference documentation, and a troubleshooting section.

-## Authentication protocols articles and reference

-* [Important Information About Signing Key Rollover in Microsoft identity platform](./signing-key-rollover.md) ΓÇô Learn about Microsoft identity platformΓÇÖs signing key rollover cadence, changes you can make to update the key automatically, and discussion for how to update the most common application scenarios.

-* [Supported Token and Claim Types](id-tokens.md) - Learn about the claims in the tokens that the Microsoft identity platform issues.

-* [OAuth 2.0 in Microsoft identity platform](v2-oauth2-auth-code-flow.md) - Learn about the implementation of OAuth 2.0 in Microsoft identity platform.

-* [OpenID Connect 1.0](v2-protocols-oidc.md) - Learn how to use OAuth 2.0, an authorization protocol, for authentication.

-* [Service to Service Calls with Client Credentials](v2-oauth2-client-creds-grant-flow.md) - Learn how to use OAuth 2.0 client credentials grant flow for service to service calls.

-* [Service to Service Calls with On-Behalf-Of Flow](v2-oauth2-on-behalf-of-flow.md) - Learn how to use OAuth 2.0 On-Behalf-Of flow for service to service calls.

-* [SAML Protocol Reference](./saml-protocol-reference.md) - Learn about the Single Sign-On and Single Sign-out SAML profiles of Microsoft identity platform.

-## See also

-* [Microsoft identity platform overview](v2-overview.md)

-* [Active Directory Code Samples](sample-v2-code.md)

-description: Learn more about how the Azure AD consent framework works to see how you can use it when developing applications on Azure AD

-# How application consent works

-This article is to help you learn more about how the Azure AD consent framework works so you can develop applications more effectively.

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Go to **Azure Active Directory** and then **Enterprise applications**. Select **New application** and then **Create your own application**.

-This article describes how to configure and setup a custom claims provider with the [token issuance start event](custom-claims-provider-overview.md#token-issuance-start-event-listener) type. This event is triggered right before the token is issued, and allows you to call a REST API to add claims to the token.

-# [Azure portal](#tab/azure-portal)

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Under **Azure services**, select **Azure Active Directory**.

-1. Ensure your user account has the Global Administrator or Application Administrator and Authentication Extensibility Administrator role. Otherwise, learn how to [assign a role](../roles/manage-roles-portal.md).

-1. From the menu, select **Enterprise applications**.

-1. Under **Manage**, select the **Custom authentication extensions**.

-1. Select **Create a custom authentication extension**.

-Create an Application Registration to authenticate your custom authentication extension to your Azure Function.

-1. Sign in to the [Microsoft Graph Explorer](https://aka.ms/ge) using an account whose home tenant is the tenant you wish to manage your custom authentication extension in.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/applications`

-1. Select **Request Body** and paste the following JSON:

- ```json

- "displayName": "authenticationeventsAPI"

-1. Select **Run Query** to submit the request.

-1. Copy the **Application ID** value (*appId*) from the response. You need this value later, which is referred to as the `{authenticationeventsAPI_AppId}`. Also get the object ID of the app (*ID*), which is referred to as `{authenticationeventsAPI_ObjectId}` from the response.

-Create a service principal in the tenant for the authenticationeventsAPI app registration:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals`

-1. Select **Request Body** and paste the following JSON:

- ```json

- {

- "appId": "{authenticationeventsAPI_AppId}"

- }

- ```

-1. Select **Run Query** to submit the request.

-1. Set the HTTP method to **PATCH**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/applications/{authenticationeventsAPI_ObjectId}`

-1. Select **Request Body** and paste the following JSON:

- Set the application ID URI value in the *identifierUris* property. Replace `{Function_Url_Hostname}` with the hostname of the `{Function_Url}` you recorded earlier.

-

- Set the `{authenticationeventsAPI_AppId}` value with the App ID generated from the app registration created in the previous step.

-

- An example value would be `api://authenticationeventsAPI.azurewebsites.net/f4a70782-3191-45b4-b7e5-dd415885dd80`. Take note of this value as it is used in following steps and is referenced as `{functionApp_IdentifierUri}`.

-

- ```json

- "identifierUris": [

- "api://{Function_Url_Hostname}/{authenticationeventsAPI_AppId}"

- ],

- "api": {

- "requestedAccessTokenVersion": 2,

- "acceptMappedClaims": null,

- "knownClientApplications": [],

- "oauth2PermissionScopes": [],

- "preAuthorizedApplications": []

- },

- "requiredResourceAccess": [

- "resourceAppId": "00000003-0000-0000-c000-000000000000",

- "resourceAccess": [

- {

- "id": "214e810f-fda8-4fd7-a475-29461495eb00",

- "type": "Role"

- }

- ]

- ```

-1. Select **Run Query** to submit the request.

-Next, you register the custom authentication extension. You register the custom authentication extension by associating it with the App Registration for the Azure Function, and your Azure Function endpoint `{Function_Url}`.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/beta/identity/customAuthenticationExtensions`

-1. Select **Request Body** and paste the following JSON:

- Replace `{Function_Url}` with the hostname of your Azure Function app. Replace `{functionApp_IdentifierUri}` with the identifierUri used in the previous step.

- ```json

-1. Select **Run Query** to submit the request.

-Record the ID value of the created custom claims provider object. The ID is needed in a later step and is referred to as the `{customExtensionObjectId}`.

-After your custom authentication extension is created, you'll be taken to the **Overview** tab of the new custom authentication extension.

-1. Sign in to the [Azure portal](https://portal.azure.com) and navigate to **Azure Active Directory**.

-1. Select **App registrations**, and then select **New registration**.

-In your app registration, under **Overview**, copy the **Application (client) ID**. The app ID is referred to as the `{App_to_enrich_ID}` in later steps.

-# [Azure portal](#tab/azure-portal)

-1. Sign in to the [Azure portal](https://portal.azure.com) and navigate to **Azure Active Directory**.

-1. Select **App registrations**, and find the *My Test application* registration you created.

-First create an event listener to trigger a custom authentication extension using the token issuance start event:

-1. Sign in to the [Microsoft Graph Explorer](https://aka.ms/ge) using an account whose home tenant is the tenant you wish to manage your custom authentication extension in.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/beta/identity/authenticationEventListeners`

-1. Select **Request Body** and paste the following JSON:

- Replace `{App_to_enrich_ID}` with the app ID of *My Test application* recorded earlier. Replace `{customExtensionObjectId}` with the custom authentication extension ID recorded earlier.

- ```json

-1. Select **Run Query** to submit the request.

-Next, create the claims mapping policy, which describes which claims can be issued to an application from a custom claims provider:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/policies/claimsmappingpolicies`

-1. Select **Request Body** and paste the following JSON:

- ```json

-1. Record the `ID` generated in the response, later it's referred to as `{claims_mapping_policy_ID}`.

-1. Select **Run Query** to submit the request.

-Get the `servicePrincipal` objectId:

-1. Set the HTTP method to **GET**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals(appId='{App_to_enrich_ID}')/claimsMappingPolicies/$ref`. Replace `{App_to_enrich_ID}` with *My Test Application* App ID.

-1. Record the `id` value, later it's referred to as `{test_App_Service_Principal_ObjectId}`.

-Assign the claims mapping policy to the `servicePrincipal` of *My Test Application*:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals/{test_App_Service_Principal_ObjectId}/claimsMappingPolicies/$ref`

-1. Select **Request Body** and paste the following JSON:

- ```json

-1. Select **Run Query** to submit the request.

-1. Go to your Azure AD tenant in which your custom authentication extension is registered, and select **Azure Active Directory** > **App registrations**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the **Enterprise apps** experience for your given application, select on the **Sign-in** logs tab.

-1. Select the latest sign-in log.

-1. Sign in to the [Azure portal](https://portal.azure.com) with your Azure administrator account.

-1. Select **Azure Active Directory** > **App registrations**.

-description: Learn about delegated and application permissions, how they are used by clients and exposed by resources for applications you are developing with Azure AD

-# How to recognize differences between delegated and application permissions

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-1. Sign into the [Entra admin portal](https://entra.microsoft.com/).

-1. Select **App registrations** in the left navigation pane, and then the **All applications**.

-1. Sign into the [Entra admin portal](https://entra.microsoft.com/).

-1. In the left navigation pane, select **Roles & admins**.

-View the deployed website on App Service. Navigate to your App Service in Azure portal and select the instance's **Default domain**: `https://pipelinetestwebapp.azurewebsites.net`.

-To verify that access to your app is limited to users in your organization, navigate to your App Service in the [Azure portal](https://portal.azure.com) and select the instance's **Default domain**: `https://pipelinetestwebapp.azurewebsites.net`.

-In the Azure portal, select **Resource groups** from the menu and select the resource group that contains your deployed web app.

-In the [Entra admin center](https://entra.microsoft.com/), select **Applications** > **App registrations** > **All applications**.

-description: Definitions of terms commonly found in Microsoft identity platform documentation, Azure portal, and authentication SDKs like the Microsoft Authentication Library (MSAL).

-You see these terms when you use our documentation, the Azure portal, our authentication libraries, and the Microsoft Graph API. Some terms are Microsoft-specific while others are related to protocols like OAuth or other technologies you use with the Microsoft identity platform.

-A feature provided by the [Azure portal], which produces a JSON representation of the application's identity configuration, used as a mechanism for updating its associated [Application][Graph-App-Resource] and [ServicePrincipal][Graph-Sp-Resource] entities. See [Understanding the Azure Active Directory application manifest][AAD-App-Manifest] for more details.

-When you register/update an application in the [Azure portal], the portal creates/updates both an application object and a corresponding [service principal object](#service-principal-object) for that tenant. The application object _defines_ the application's identity configuration globally (across all tenants where it has access), providing a template from which its corresponding service principal object(s) are _derived_ for use locally at run-time (in a specific tenant).

-Permission requests are configured on the **API permissions** page for an application in the [Azure portal], by selecting the desired "Delegated Permissions" and "Application Permissions" (the latter requires membership in the Global Administrator role). Because a [public client](#client-application) can't securely maintain credentials, it can only request delegated permissions, while a [confidential client](#client-application) has the ability to request both delegated and application permissions. The client's [application object](#application-object) stores the declared permissions in its [requiredResourceAccess property][Graph-App-Resource].

-Roles are resource-defined strings (for example "Expense approver", "Read-only", "Directory.ReadWrite.All"), managed in the [Azure portal] via the resource's [application manifest](#application-manifest), and stored in the resource's [appRoles property][Graph-Sp-Resource]. The Azure portal is also used to assign users to "user" assignable roles, and configure client [application permissions](#permissions) to request "application" assignable roles.

-For a detailed discussion of the application roles exposed by the Microsoft Graph API, see [Graph API Permission Scopes][Graph-Perm-Scopes]. For a step-by-step implementation example, see [Add or remove Azure role assignments using the Azure portal][AAD-RBAC].

-Scopes are resource-defined strings (for example "Mail.Read", "Directory.ReadWrite.All"), managed in the [Azure portal] via the resource's [application manifest](#application-manifest), and stored in the resource's [oauth2Permissions property][Graph-Sp-Resource]. The Azure portal is also used to configure client application [delegated permissions](#permissions) to access a scope.

-When you register/update an application in the [Azure portal], the portal creates/updates both an [application object](#application-object) and a corresponding service principal object for that tenant. The application object _defines_ the application's identity configuration globally (across all tenants where the associated application has been granted access), and is the template from which its corresponding service principal object(s) are _derived_ for use locally at run-time (in a specific tenant).

-Azure AD tenants are created/associated with Azure and Microsoft 365 subscriptions during sign-up, providing Identity & Access Management features for the subscription. Azure subscription administrators can also create additional Azure AD tenants via the Azure portal. See [How to get an Azure Active Directory tenant][AAD-How-To-Tenant] for details on the various ways you can get access to a tenant. See [Associate or add an Azure subscription to your Azure Active Directory tenant][AAD-How-Subscriptions-Assoc] for details on the relationship between subscriptions and an Azure AD tenant, and for instructions on how to associate or add a subscription to an Azure AD tenant.

-[Azure portal]: https://portal.azure.com

-Explore the range of [Azure support options and choose the plan](https://azure.microsoft.com/support/plans) that best fits you. There are two options to create and manage support requests in the Azure portal:

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the left pane, select **Azure Active Directory**.

-1. Select **Enterprise applications**, and then select **All applications**.

- :::image type="content" source="media/enterprise-app-role-management/record-objectid.png" alt-text="Screenshot that shows how to locate and record the object identifier for the application.":::

-1. Locate the application in the Azure portal, and then select **Single sign-on** in the left menu.

- :::image type="content" source="media/enterprise-app-role-management/attributes-summary.png" alt-text="Screenshot that shows a display of the list of attributes and claims defined for the application.":::

-1. In the Azure portal, locate the application to which the role was added.

- :::image type="content" source="media/enterprise-app-role-management/assign-role.png" alt-text="Screenshot that shows how to assign a role to a user of an application.":::

-* [Through the Azure portal](#azure-portal)

-### <a name="azure-portal"></a>Using the Azure portal

-Follow these steps in the Azure portal.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a> and select the correct Azure AD tenant(not B2C).

-2. Navigate to the **App registrations** section and select your app.

-3. Under **Manage**, select **Branding & properties**.

-4. Fill out the **Terms of service URL** and **Privacy statement URL** fields.

-5. Select **Save**.

- 

-If you prefer to modify the app object JSON directly, you can use the manifest editor in the Azure portal or Application Registration Portal to include links to your app's terms of service and privacy statement.

-This article shows you how to call a protected ASP.NET Core web API using Client URL (cURL). cURL is a command line tool that developers use to transfer data to and from a server. In this article, you'll register a web app and a web API in a tenant on the Azure portal. The web app is used to get an access token generated by the Microsoft identity platform. Next, you'll use the token to make an authorized call to the web API using cURL.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations > New registration**.

-1. Select **Home** to return to the home page. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. If access to multiple tenants is available, use the Directories + subscriptions filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-When registration is complete, the Azure portal displays the app registration's **Overview** pane. Record the **Directory (tenant) ID** and the **Application (client) ID** to be used in later steps.

-1. From the **Overview** pane in the Azure portal, under **Manage**, select **Certificates & secrets** > **Client secrets** > **New client secret**.

-1. From the **Overview** pane of your web application in the Azure portal (*web-app-that-calls-web-api*), under **Manage**, select **API permissions** > **Add a permission** > **My APIs**.

-You may also notice the **User.Read** permission for the Microsoft Graph API. This permission is added automatically when you register an app in the Azure portal.

- - `{APPLICATION_CLIENT_ID}` is the web API **Application (client) ID** on the app's **Overview** pane **App registrations** in the Azure portal.

- - `{DIRECTORY_TENANT_ID}` is the web API **Directory (tenant) ID** on the app's **Overview** pane **App registrations** in the Azure portal.

- - `{tenant_id}` is the web app **Directory (tenant) ID**. This should be the same value across both of the applications's **Overview** pane **App registrations** in the Azure portal.

- - `{web-app-calls-web-api_application_client_id}` is the **Application (client) ID** on the web app's (*web-app-calls-web-api*) **Overview** pane in the Azure portal.

- - `{web_API_application_client_id}` is the **Application (client) ID** on the web API's (*NewWebAPI1*) **Overview** pane in the Azure portal.

- - `{tenant_id}` is the web app **Directory (tenant) ID**. This should be the same value across both of the applications's **Overview** pane **App registrations** in the Azure portal.

- - `client_id={web-app-calls-web-api_application_client_id}`, and `session_state={web-app-calls-web-api_application_client_id}` is the **Application (client) ID** on the web application's (*web-app-calls-web-api*) **Overview** pane in the Azure portal.

- - `api://{web_API_application_client_id}/Forecast.Read` is the **Application (client) ID** on the web API's (*NewWebAPI1*) **Overview** pane in the Azure portal.

-This article shows you how to call a protected ASP.NET Core web API using [Postman](https://www.postman.com/). Postman is an application that lets you send HTTP requests to a web API to test its authorization and access control (authentication) policies. In this article, you'll register a web app and a web API in a tenant on the Azure portal. The web app is used to get an access token generated by the Microsoft identity platform. Next, you'll use the token to make an authorized call to the web API using Postman.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations > New registration**.

-1. Select **Home** to return to the home page. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. If access to multiple tenants is available, use the Directories + subscriptions filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-When registration is complete, the Azure portal displays the app registration's **Overview** pane. Record the **Directory (tenant) ID** and the **Application (client) ID** to be used in later steps.

-1. From the **Overview** pane in the Azure portal, under **Manage**, select **Certificates & secrets** > **Client secrets** > **New client secret**.

-1. From the **Overview** pane of your application in the Azure portal, under **Manage**, select **API permissions** > **Add a permission** > **My APIs**.

-You may also notice the **User.Read** permission for the Microsoft Graph API. This permission is added automatically when you register an app in the Azure portal.

- - `{APPLICATION_CLIENT_ID}` is the web API **Application (client) ID** on the app's **Overview** pane **App registrations** in the Azure portal.

- - `{DIRECTORY_TENANT_ID}` is the web API **Directory (tenant) ID** on the app's **Overview** pane **App registrations** in the Azure portal.

-# How to configure app instance property lock for your applications (Preview)

-To configure an app instance lock using the Azure portal:

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant that contains the app registration you want to configure.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**, and then select the application you want to configure.

- :::image type="content" source="media/howto-configure-app-instance-property-locks/app-instance-lock-configure-overview.png" alt-text="Screenshot of an app registration's app instance lock in the Azure portal.":::

- :::image type="content" source="media/howto-configure-app-instance-property-locks/app-instance-lock-configure-properties.png" alt-text="Screenshot of an app registration's app instance property lock context pane in the Azure portal.":::

-In an elevated PowerShell prompt, run the following command and leave the PowerShell console session open. Replace `{certificateName}` with the name that you wish to give to your certificate.

-In the following sections, you learn how to modify your app's registration in the Azure portal to change who, or what types of accounts, can access the application.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which the app is registered.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**, select your application, and then select **Manifest** to use the manifest editor.

-If youΓÇÖre just getting started, check out the [Microsoft identity platform documentation](index.yml) to learn about authentication basics, application scenarios in the Microsoft identity platform, and more.

-> The *Integration assistant* in the Azure portal can help you apply many of these best practices and recommendations. Select any of your [app registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade) in the Azure portal, and then select the **Integration assistant** menu item to get started with the assistant.

-. Make sure your name and logo are representative of your company/product so that users can make informed decisions. Ensure that you're not violating any trademarks.

-.

- apps.

- For mobile apps, configure each platform using the application registration experience. In order for your application to take advantage of the Microsoft Authenticator or Microsoft Company Portal for single sign-in, your app needs a ΓÇ£broker redirect URIΓÇ¥ configured. This allows Microsoft to return control to your application after authentication. When configuring each platform, the app registration experience will guide you through the process. Use the quickstart to download a working example. On iOS, use brokers and system webview whenever possible.

- Don't use ΓÇ£prompt=consentΓÇ¥ for every sign-in. Only use prompt=consent if youΓÇÖve determined that you need to ask for consent for additional permissions (for example, if youΓÇÖve changed your appΓÇÖs required permissions).

- Implement a [clean single sign-out experience](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/1-WebApp-OIDC/1-6-SignOut). ItΓÇÖs a privacy and a security requirement, and makes for a good user experience.

- Test for [Conditional Access policies](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/1-WebApp-OIDC/1-6-SignOut) that may affect your usersΓÇÖ ability to use your application.

-[auth-fund-01-img]: ./media/identity-videos/aad-auth-fund-01.jpg

-[auth-fund-02-img]: ./media/identity-videos/aad-auth-fund-02.jpg

-[auth-fund-03-img]: ./media/identity-videos/aad-auth-fund-03.jpg

-[auth-fund-04-img]: ./media/identity-videos/aad-auth-fund-04.jpg

-[auth-fund-05-img]: ./media/identity-videos/aad-auth-fund-05.jpg

-[auth-fund-06-img]: ./media/identity-videos/aad-auth-fund-06.jpg

-To view or edit the claims issued in the JWT to the application, open the application in Azure portal. Then select **Single sign-on** blade in the left-hand menu and open the **Attributes & Claims** section.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the **Attributes & Claims** section, Select **Edit** to edit the claims.

-1. Select the required claim that you want to modify.

- :::image type="content" source="./media/jwt-claims-customization/sso-saml-multiple-claims-transformation.png" alt-text="Screenshot of claims transformation.":::

-| **EndWith()** | Outputs an attribute or constant if the input ends with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the employee ID ends with "000", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.employeeid<br/>*Value*: "000"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

-| **StartWith()** | Outputs an attribute or constant if the input starts with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the country/region starts with "US", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.country<br/>*Value*: "US"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

-Applications that receive tokens rely on claim values that are authoritatively issued by Azure AD and can't be tampered with. When you modify the token contents through claims customization, these assumptions may no longer be correct. Applications must explicitly acknowledge that tokens have been modified by the creator of the customization to protect themselves from customizations created by malicious actors. This can be done in one the following ways:

-For multi-tenant apps, a custom signing key should be used. Don't set `acceptMappedClaims` in the app manifest. when setting up an app in the Azure portal, you get an app registration object and a service principal in your tenant. That app is using the Azure global sign-in key, which can't be used for customizing claims in tokens. To get custom claims in tokens, create a custom sign-in key from a certificate and add it to service principal. For testing purposes, you can use a self-signed certificate. After configuring the custom signing key, your application code needs to validate the token signing key.

-The following example shows the format of the HTTP PATCH request to add a custom signing key to a service principal. The "key" value in the `keyCredentials` property is shortened for readability. The value is base-64 encoded. For the private key, the property usage is "Sign". For the public key, the property usage is "Verify".

-Use PowerShell to [instantiate an MSAL Public Client Application](msal-net-initializing-client-applications.md#initializing-a-public-client-application-from-code) and use the [Authorization Code Grant](v2-oauth2-auth-code-flow.md) flow to obtain a delegated permission access token for Microsoft Graph. Use the access token to call Microsoft Graph and configure a custom signing key for the service principal. After configuring the custom signing key, your application code needs to [validate the token signing key](#validate-token-signing-key).

-To run this script you need:

-For single tenant apps, you can set the `acceptMappedClaims` property to `true` in the [application manifest](reference-app-manifest.md). As documented on the [apiApplication resource type](/graph/api/resources/apiapplication?view=graph-rest-1.0&preserve-view=true#properties), this allows an application to use claims mapping without specifying a custom signing key.

-description: Describes how to mark an app as publisher verified. When an application is marked as publisher verified, it means that the publisher (application developer) has verified the authenticity of their organization using a Microsoft Partner Network (MPN) account that has completed the verification process and has associated this MPN account with that application registration.

-When an app registration has a verified publisher, it means that the publisher of the app has [verified](/partner-center/verification-responses) their identity using their Microsoft Partner Network (MPN) account and has associated this MPN account with their app registration. This article describes how to complete the [publisher verification](publisher-verification-overview.md) process.

-If you are already enrolled in the Microsoft Partner Network (MPN) and have met the [pre-requisites](publisher-verification-overview.md#requirements), you can get started right away:

-1. Click **Add MPN ID to verify publisher** and review the listed requirements.

-1. Enter your MPN ID and click **Verify and save**.

-1. Sign in using [multi-factor authentication](../fundamentals/concept-fundamentals-mfa-get-started.md) to an organizational (Azure AD) account authorized to make changes to the app you want to mark as Publisher Verified and on the MPN Account in Partner Center.

- - The user in Partner Center must have the following [roles](/partner-center/permissions-overview): MPN Admin, Accounts Admin, or a Global Administrator (a shared role mastered in Azure AD).

-1. Ensure that either the publisher domain or a DNS-verified [custom domain](../fundamentals/add-custom-domain.md) on the tenant matches the domain of the email address used during the verification process for your MPN account.

-1. Click **Add MPN ID to verify publisher** near the bottom of the page.

-1. Enter the **MPN ID** for:

- - A valid Microsoft Partner Network account that has completed the verification process.

-description: Learn how to migrate your Azure Active Directory Authentication Library (ADAL) Java app to the Microsoft Authentication Library (MSAL).

-#Customer intent: As a Java application developer, I want to learn how to migrate my v1 ADAL app to v2 MSAL.

-# ADAL to MSAL migration guide for Java

-This article highlights changes you need to make to migrate an app that uses the Azure Active Directory Authentication Library (ADAL) to use the Microsoft Authentication Library (MSAL).

-Both the Microsoft Authentication Library for Java (MSAL4J) and Azure AD Authentication Library for Java (ADAL4J) are used to authenticate Azure AD entities and request tokens from Azure AD. Until now, most developers have worked with Azure AD for developers platform (v1.0) to authenticate Azure AD identities (work and school accounts) by requesting tokens using Azure AD Authentication Library (ADAL).

-MSAL offers the following benefits:

-MSAL for Java is the auth library we recommend you use with the Microsoft identity platform. No new features will be implemented on ADAL4J. All efforts going forward are focused on improving MSAL.

-You can learn more about MSAL and get started with an [overview of the Microsoft Authentication Library](msal-overview.md).

-## Scopes not resources

-ADAL4J acquires tokens for resources whereas MSAL for Java acquires tokens for scopes. Many MSAL for Java classes require a scopes parameter. This parameter is a list of strings that declare the desired permissions and resources that are requested. See [Microsoft Graph's scopes](/graph/permissions-reference) to see example scopes.

-You can add the `/.default` scope suffix to the resource to help migrate your apps from the ADAL to MSAL. For example, for the resource value of `https://graph.microsoft.com`, the equivalent scope value is `https://graph.microsoft.com/.default`. If the resource isn't in the URL form, but a resource ID of the form `XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX`, you can still use the scope value as `XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX/.default`.

-For more details about the different types of scopes, refer

-[Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md) and the [Scopes for a Web API accepting v1.0 tokens](./msal-v1-app-scopes.md) articles.

-## Core classes

-In ADAL4J, the `AuthenticationContext` class represents your connection to the Security Token Service (STS), or authorization server, through an Authority. However, MSAL for Java is designed around client applications. It provides two separate classes: `PublicClientApplication` and `ConfidentialClientApplication` to represent client applications. The latter, `ConfidentialClientApplication`, represents an application that is designed to securely maintain a secret such as an application identifier for a daemon app.

-The following table shows how ADAL4J functions map to the new MSAL for Java functions:

-| ADAL4J method| MSAL4J method|

-||-|

-|acquireToken(String resource, ClientCredential credential, AuthenticationCallback callback) | acquireToken(ClientCredentialParameters)|

-|acquireToken(String resource, ClientAssertion assertion, AuthenticationCallback callback)|acquireToken(ClientCredentialParameters)|

-|acquireToken(String resource, AsymmetricKeyCredential credential, AuthenticationCallback callback)|acquireToken(ClientCredentialParameters)|

-|acquireToken(String resource, String clientId, String username, String password, AuthenticationCallback callback)| acquireToken(UsernamePasswordParameters)|

-|acquireToken(String resource, String clientId, String username, String password=null, AuthenticationCallback callback)|acquireToken(IntegratedWindowsAuthenticationParameters)|

-|acquireToken(String resource, UserAssertion userAssertion, ClientCredential credential, AuthenticationCallback callback)| acquireToken(OnBehalfOfParameters)|

-|acquireTokenByAuthorizationCode() | acquireToken(AuthorizationCodeParameters) |

-| acquireDeviceCode() and acquireTokenByDeviceCode()| acquireToken(DeviceCodeParameters)|

-|acquireTokenByRefreshToken()| acquireTokenSilently(SilentParameters)|

-## IAccount instead of IUser

-ADAL4J manipulated users. Although a user represents a single human or software agent, it can have one or more accounts in the Microsoft identity system. For example, a user may have several Azure AD, Azure AD B2C, or Microsoft personal accounts.

-MSAL for Java defines the concept of Account via the `IAccount` interface. This is a breaking change from ADAL4J, but it's a good one because it captures the fact that the same user can have several accounts, and perhaps even in different Azure AD directories. MSAL for Java provides better information in guest scenarios because home account information is provided.

-## Cache persistence

-ADAL4J didn't have support for token cache.

-MSAL for Java adds a [token cache](msal-acquire-cache-tokens.md) to simplify managing token lifetimes by automatically refreshing expired tokens when possible and preventing unnecessary prompts for the user to provide credentials when possible.

-## Common Authority

-In v1.0, if you use the `https://login.microsoftonline.com/common` authority, users can sign in with any Azure Active Directory (Azure AD) account (for any organization).

-If you use the `https://login.microsoftonline.com/common` authority in v2.0, users can sign in with any Azure AD organization, or even a Microsoft personal account (MSA). In MSAL for Java, if you want to restrict login to any Azure AD account, use the `https://login.microsoftonline.com/organizations` authority (which is the same behavior as with ADAL4J). To specify an authority, set the `authority` parameter in the [PublicClientApplication.Builder](https://javadoc.io/doc/com.microsoft.azure/msal4j/1.0.0/com/microsoft/aad/msal4j/PublicClientApplication.Builder.html) method when you create your `PublicClientApplication` class.

-## v1.0 and v2.0 tokens

-The v1.0 endpoint (used by ADAL) only emits v1.0 tokens.

-The v2.0 endpoint (used by MSAL) can emit v1.0 and v2.0 tokens. A property of the application manifest of the web API enables developers to choose which version of token is accepted. See `accessTokenAcceptedVersion` in the [application manifest](./reference-app-manifest.md) reference documentation.

-For more information about v1.0 and v2.0 tokens, see [Azure Active Directory access tokens](./access-tokens.md).

-## ADAL to MSAL migration

-In ADAL4J, the refresh tokens were exposed--which allowed developers to cache them. They would then use `AcquireTokenByRefreshToken()` to enable solutions such as implementing long-running services that refresh dashboards on behalf of the user when the user is no longer connected.

-MSAL for Java doesn't expose refresh tokens for security reasons. Instead, MSAL handles refreshing tokens for you.

-MSAL for Java has an API that allows you to migrate refresh tokens you acquired with ADAL4j into the ClientApplication: [acquireToken(RefreshTokenParameters)](https://javadoc.io/static/com.microsoft.azure/msal4j/1.0.0/com/microsoft/aad/msal4j/PublicClientApplication.html#acquireToken-com.microsoft.aad.msal4j.RefreshTokenParameters-). With this method, you can provide the previously used refresh token along with any scopes (resources) you desire. The refresh token will be exchanged for a new one and cached for use by your application.

-The following code snippet shows some migration code in a confidential client application:

-```java

-String rt = GetCachedRefreshTokenForSignedInUser(); // Get refresh token from where you have them stored

-Set<String> scopes = Collections.singleton("SCOPE_FOR_REFRESH_TOKEN");

-RefreshTokenParameters parameters = RefreshTokenParameters.builder(scopes, rt).build();

-PublicClientApplication app = PublicClientApplication.builder(CLIENT_ID) // ClientId for your application

- .authority(AUTHORITY) //plug in your authority

- .build();

-IAuthenticationResult result = app.acquireToken(parameters);

-```

-The `IAuthenticationResult` returns an access token and ID token, while your new refresh token is stored in the cache.

-The application will also now contain an IAccount:

-```java

-Set<IAccount> accounts = app.getAccounts().join();

-```

-To use the tokens that are now in the cache, call:

-```java

-SilentParameters parameters = SilentParameters.builder(scope, accounts.iterator().next()).build();

-IAuthenticationResult result = app.acquireToken(parameters);

-```

-description: Learn how to migrate your Azure Active Directory Authentication Library (ADAL) Python app to the Microsoft Authentication Library (MSAL) for Python.

-#Customer intent: As a Python application developer, I want to learn how to migrate my v1 ADAL app to v2 MSAL.

-# ADAL to MSAL migration guide for Python

-This article highlights changes you need to make to migrate an app that uses the Azure Active Directory Authentication Library (ADAL) to use the Microsoft Authentication Library (MSAL).

-You can learn more about MSAL and get started with an [overview of the Microsoft Authentication Library](msal-overview.md).

-## Difference highlights

-ADAL works with the Azure Active Directory (Azure AD) v1.0 endpoint. The Microsoft Authentication Library (MSAL) works with the Microsoft identity platform--formerly known as the Azure Active Directory v2.0 endpoint. The Microsoft identity platform differs from Azure AD v1.0 in that it:

-Supports:

- - OAuth v2.0

- - OpenID Connect (OIDC)

-For more information about MSAL, see [MSAL overview](./msal-overview.md).

-### Scopes not resources

-ADAL Python acquires tokens for resources, but MSAL Python acquires tokens for scopes. The API surface in MSAL Python doesn't have resource parameter anymore. You would need to provide scopes as a list of strings that declare the desired permissions and resources that are requested. To see some example of scopes, see [Microsoft Graph's scopes](/graph/permissions-reference).

-You can add the `/.default` scope suffix to the resource to help migrate your apps from the v1.0 endpoint (ADAL) to the Microsoft identity platform (MSAL). For example, for the resource value of `https://graph.microsoft.com`, the equivalent scope value is `https://graph.microsoft.com/.default`. If the resource isn't in the URL form, but a resource ID of the form `XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX`, you can still use the scope value as `XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX/.default`.

-For more details about the different types of scopes, refer to [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md) and the [Scopes for a Web API accepting v1.0 tokens](./msal-v1-app-scopes.md) articles.

-### Error handling

-ADAL for Python uses the exception `AdalError` to indicate that there's been a problem. MSAL for Python typically uses error codes, instead. For more information, see [MSAL for Python error handling](msal-error-handling-python.md).

-### API changes

-The following table lists an API in ADAL for Python, and the one to use in its place in MSAL for Python:

-| ADAL for Python API | MSAL for Python API |

-| -- | - |

-| [AuthenticationContext](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext) | [PublicClientApplication](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.__init__) or [ConfidentialClientApplication](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.__init__) |

-| N/A | [PublicClientApplication.acquire_token_interactive()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_interactive) |

-| N/A | [ConfidentialClientApplication.initiate_auth_code_flow()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.initiate_auth_code_flow) |

-| [acquire_token_with_authorization_code()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_authorization_code) | [ConfidentialClientApplication.acquire_token_by_auth_code_flow()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_by_auth_code_flow) |

-| [acquire_token()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token) | [PublicClientApplication.acquire_token_silent()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_silent) or [ConfidentialClientApplication.acquire_token_silent()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_silent) |

-| [acquire_token_with_refresh_token()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_refresh_token) | These two helpers are intended to be used during [migration](#migrate-existing-refresh-tokens-for-msal-python) only: [PublicClientApplication.acquire_token_by_refresh_token()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_by_refresh_token) or [ConfidentialClientApplication.acquire_token_by_refresh_token()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_by_refresh_token) |

-| [acquire_user_code()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_user_code) | [initiate_device_flow()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.initiate_device_flow) |

-| [acquire_token_with_device_code()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_device_code) and [cancel_request_to_get_token_with_device_code()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.cancel_request_to_get_token_with_device_code) | [acquire_token_by_device_flow()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_by_device_flow) |

-| [acquire_token_with_username_password()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_username_password) | [acquire_token_by_username_password()](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_by_username_password) |

-| [acquire_token_with_client_credentials()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_client_credentials) and [acquire_token_with_client_certificate()](https://adal-python.readthedocs.io/en/latest/#adal.AuthenticationContext.acquire_token_with_client_certificate) | [acquire_token_for_client()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_for_client) |

-| N/A | [acquire_token_on_behalf_of()](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_on_behalf_of) |

-| [TokenCache()](https://adal-python.readthedocs.io/en/latest/#adal.TokenCache) | [SerializableTokenCache()](https://msal-python.readthedocs.io/en/latest/#msal.SerializableTokenCache) |

-| N/A | Cache with persistence, available from [MSAL Extensions](https://github.com/marstr/original-microsoft-authentication-extensions-for-python) |

-## Migrate existing refresh tokens for MSAL Python

-MSAL abstracts the concept of refresh tokens. MSAL Python provides an in-memory token cache by default so that you don't need to store, lookup, or update refresh tokens. Users will also see fewer sign-in prompts because refresh tokens can usually be updated without user intervention. For more information about the token cache, see [Custom token cache serialization in MSAL for Python](msal-python-token-cache-serialization.md).

-The following code will help you migrate your refresh tokens managed by another OAuth2 library (including but not limited to ADAL Python) to be managed by MSAL for Python. One reason for migrating those refresh tokens is to prevent existing users from needing to sign in again when you migrate your app to MSAL for Python.

-The method for migrating a refresh token is to use MSAL for Python to acquire a new access token using the previous refresh token. When the new refresh token is returned, MSAL for Python will store it in the cache.

-Since MSAL Python 1.3.0, we provide an API inside MSAL for this purpose.

-Please refer to the following code snippet, quoted from

-[a completed sample of migrating refresh tokens with MSAL Python](https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/1.3.0/sample/migrate_rt.py#L28-L67)

-```python

-import msal

-def get_preexisting_rt_and_their_scopes_from_elsewhere():

- # Maybe you have an ADAL-powered app like this

- # https://github.com/AzureAD/azure-activedirectory-library-for-python/blob/1.2.3/sample/device_code_sample.py#L72

- # which uses a resource rather than a scope,

- # you need to convert your v1 resource into v2 scopes

- # See https://learn.microsoft.com/azure/active-directory/develop/migrate-python-adal-msal#scopes-not-resources

- # You may be able to append "/.default" to your v1 resource to form a scope

- # See https://learn.microsoft.com/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope

- # Or maybe you have an app already talking to the Microsoft identity platform,

- # powered by some 3rd-party auth library, and persist its tokens somehow.

- # Either way, you need to extract RTs from there, and return them like this.

- return [

- ("old_rt_1", ["scope1", "scope2"]),

- ("old_rt_2", ["scope3", "scope4"]),

- ]

-# We will migrate all the old RTs into a new app powered by MSAL

-app = msal.PublicClientApplication(

- "client_id", authority="...",

- # token_cache=... # Default cache is in memory only.

- # You can learn how to use SerializableTokenCache from

- # https://msal-python.readthedocs.io/en/latest/#msal.SerializableTokenCache

- )

-# We choose a migration strategy of migrating all RTs in one loop

-for old_rt, scopes in get_preexisting_rt_and_their_scopes_from_elsewhere():

- result = app.acquire_token_by_refresh_token(old_rt, scopes)

- if "error" in result:

- print("Discarding unsuccessful RT. Error: ", json.dumps(result, indent=2))

-print("Migration completed")

-```

-You can use [keytool](https://manpages.debian.org/buster/openjdk-11-jre-headless/keytool.1.en.html) to generate a Base64-encoded signature hash using your app's signing keys, and then use the Azure portal to generate your redirect URI using that hash.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="/azure/active-directory/develop/media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you registered your application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Under **Manage**, select **App registrations**, then select your application.

-1. Under **Manage**, select **Authentication** > **Add a platform** > **Android**.

-The Azure portal generates the redirect URI for you and displays it in the **Android configuration** pane's **Redirect URI** field.

-For more iOS details, see [Migrate iOS applications that use Microsoft Authenticator from ADAL.NET to MSAL.NET](msal-net-migration-ios-broker.md) and [Leveraging the broker on iOS](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Leveraging-the-broker-on-iOS).

- - [Logging in MSAL for Java](msal-logging-java.md)

- - [Logging in MSAL for Python](msal-logging-python.md)

-description: Learn how to handle errors and exceptions, Conditional Access claims challenges, and retries in MSAL4J applications.

-# Handle errors and exceptions in MSAL for Java

-## Error handling in MSAL for Java

-In MSAL for Java, there are three types of exceptions: `MsalClientException`, `MsalServiceException`, and `MsalInteractionRequiredException`; all which inherit from `MsalException`.

-### MsalServiceException

-`MsalServiceException` exposes HTTP headers returned in the requests to the STS. Access them via `MsalServiceException.headers()`

-### MsalInteractionRequiredException

-One of common status codes returned from MSAL for Java when calling `AcquireTokenSilently()` is `InvalidGrantError`. This means that additional user interaction is required before an authentication token can be issued. Your application should call the authentication library again, but in interactive mode by sending `AuthorizationCodeParameters` or `DeviceCodeParameters` for public client applications.

-Most of the time when `AcquireTokenSilently` fails, it's because the token cache doesn't have a token matching your request. Access tokens expire in one hour, and `AcquireTokenSilently` will try to get a new one based on a refresh token. In OAuth2 terms, this is the Refresh Token flow. This flow can also fail for various reasons such as when a tenant admin configures more stringent login policies.

-Some conditions that result in this error are easy for users to resolve. For example, they may need to accept Terms of Use or the request can't be fulfilled with the current configuration because the machine needs to connect to a specific corporate network.

-MSAL exposes a `reason` field, which you can use to provide a better user experience. For example, the `reason` field may lead you to tell the user that their password expired or that they'll need to provide consent to use some resources. The supported values are part of the `InteractionRequiredExceptionReason` enum:

-| Reason | Meaning | Recommended Handling |

-||--|--|

-| `BasicAction` | Condition can be resolved by user interaction during the interactive authentication flow. | Call `acquireToken` with interactive parameters. |

-| `AdditionalAction` | Condition can be resolved by additional remedial interaction with the system outside of the interactive authentication flow. | Call `acquireToken` with interactive parameters to show a message that explains the remedial action to take. The calling app may choose to hide flows that require additional action if the user is unlikely to complete the remedial action. |

-| `MessageOnly` | Condition can't be resolved at this time. Launch interactive authentication flow to show a message explaining the condition. | Call `acquireToken` with interactive parameters to show a message that explains the condition. `acquireToken` will return the `UserCanceled` error after the user reads the message and closes the window. The app may choose to hide flows that result in message if the user is unlikely to benefit from the message. |

-| `ConsentRequired`| User consent is missing, or has been revoked. |Call `acquireToken` with interactive parameters so that the user can give consent. |

-| `UserPasswordExpired` | User's password has expired. | Call `acquireToken` with interactive parameter so the user can reset their password. |

-| `None` | Further details are provided. The condition may be resolved by user interaction during the interactive authentication flow. | Call `acquireToken` with interactive parameters. |

-### Code Example

-```java

- IAuthenticationResult result;

- try {

- PublicClientApplication application = PublicClientApplication

- .builder("clientId")

- .b2cAuthority("authority")

- .build();

- SilentParameters parameters = SilentParameters

- .builder(Collections.singleton("scope"))

- .build();

- result = application.acquireTokenSilently(parameters).join();

- }

- catch (Exception ex){

- if(ex instanceof MsalInteractionRequiredException){

- // AcquireToken by either AuthorizationCodeParameters or DeviceCodeParameters

- } else{

- // Log and handle exception accordingly

- }

- }

-```

-## Next steps

-Consider enabling [Logging in MSAL for Java](msal-logging-java.md) to help you diagnose and debug issues.

-The methods for pop-up experience (`loginPopup`, `acquireTokenPopup`) return promises, so you can use the promise pattern (.then and .catch) to handle them as shown:

-description: Learn how to handle errors and exceptions, Conditional Access claims challenges, and retries in MSAL for Python applications.

-# Handle errors and exceptions in MSAL for Python

-## Error handling in MSAL for Python

-In MSAL for Python, most errors are conveyed as a return value from the API call. The error is represented as a dictionary containing the JSON response from the Microsoft identity platform.

-* A successful response contains the `"access_token"` key. The format of the response is defined by the OAuth2 protocol. For more information, see [5.1 Successful Response](https://tools.ietf.org/html/rfc6749#section-5.1)

-* An error response contains `"error"` and usually `"error_description"`. The format of the response is defined by the OAuth2 protocol. For more information, see [5.2 Error Response](https://tools.ietf.org/html/rfc6749#section-5.2)

-When an error is returned, the `"error"` key contains a machine-readable code. If the `"error"` is, for example, an `"interaction_required"`, you may prompt the user to provide additional information to complete the authentication process. If the `"error"` is `"invalid_grant"`, you may prompt the user to reenter their credentials. The following snippet is an example of error handling in MSAL for Python.

-```python

-from msal import ConfidentialClientApplication

-authority_url = "https://login.microsoftonline.com/your_tenant_id"

-client_id = "your_client_id"

-client_secret = "your_client_secret"

-scopes = ["https://graph.microsoft.com/.default"]

-app = ConfidentialClientApplication(client_id, authority=authority_url, client_credential=client_secret)

-result = app.acquire_token_silent(scopes=scopes, account=None)

-if not result:

- result = app.acquire_token_silent(scopes=scopes)

-if "access_token" in result:

- print("Access token: %s" % result["access_token"])

-else:

- print("Error: %s" % result.get("error"))

-```

-When an error is returned, the `"error_description"` key also contains a human-readable message, and there is typically also an `"error_code"` key which contains a machine-readable Microsoft identity platform error code. For more information about the various Microsoft identity platform error codes, see [Authentication and authorization error codes](./reference-error-codes.md).

-In MSAL for Python, exceptions are rare because most errors are handled by returning an error value. The `ValueError` exception is only thrown when there's an issue with how you're attempting to use the library, such as when API parameter(s) are malformed.

-## Retrying after errors and exceptions

-MSAL makes HTTP calls to the Azure AD service, and occasionally failures can occur.

-For example the network can go down or the server is overloaded.

-MSAL Python 1.11+ automatically performs one retry attempt for you.

-You may customize this behavior by following

-[this instruction](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.params.http_client).

-### HTTP 429

-When the Service Token Server (STS) is overloaded with too many requests,

-it returns HTTP error 429 with a hint about how long until you can try again in the `Retry-After` response field.

-Your app was expected to throttle the subsequent requests, and only retry after the specified period.

-That was not an easy task.

-MSAL Python 1.16+ made it easy for you, in that your app could blindly retry in any given time

-(say, whenever the end user clicks the sign-in button again),

-MSAL Python 1.16+ would automatically throttle those retry attempts by returning same error response from an HTTP cache,

-and only sending out a real HTTP call when that call is attempted after the specified period.

-By default, this throttle mechanism works by saving throttle information into a built-in in-memory HTTP cache.

-You may provide your own `dict`-like object as the HTTP cache, which you can control how to persist its content.

-See [MSAL Python's API document](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.params.http_cache)

-for more details.

-## Next steps

-Consider enabling [Logging in MSAL for Python](msal-logging-python.md) to help you diagnose and debug issues.

-> Public preview is provided without a service-level agreement and isn't recommended for production workloads. Some features might be unsupported or have constrained capabilities. For more information, see [Supplemental terms of use for Microsoft Azure previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-description: Learn about Active Directory Federation Services (AD FS) support in the Microsoft Authentication Library for Java (MSAL4j).

-#Customer intent: As an application developer, I want to learn about AD FS support in MSAL for Java so I can decide if this platform meets my application development needs and requirements.

-# Active Directory Federation Services support in MSAL for Java

-Active Directory Federation Services (AD FS) in Windows Server enables you to add OpenID Connect and OAuth 2.0 based authentication and authorization to your Microsoft Authentication Library for Java (MSAL for Java) app. Once integrated, your app can authenticate users in AD FS, federated through Azure AD. For more information about scenarios, see [AD FS Scenarios for Developers](/windows-server/identity/ad-fs/ad-fs-development).

-An app that uses MSAL for Java will talk to Azure Active Directory (Azure AD), which then federates to AD FS.

-MSAL for Java connects to Azure AD, which signs in users that are managed in Azure AD (managed users) or users managed by another identity provider such as AD FS (federated users). MSAL for Java doesn't know that a user is federated. It simply talks to Azure AD.

-The [authority](msal-client-application-configuration.md#authority) you use in this case is the usual authority (authority host name + tenant, common, or organizations).

-## Acquire a token interactively for a federated user

-When you call `ConfidentialClientApplication.AcquireToken()` or `PublicClientApplication.AcquireToken()` with `AuthorizationCodeParameters` or `DeviceCodeParameters`, the user experience is typically:

-1. The user enters their account ID.

-2. Azure AD briefly displays "Taking you to your organization's page", and the user is redirected to the sign-in page of the identity provider. The sign-in page is usually customized with the logo of the organization.

-The supported AD FS versions in this federated scenario are:

-## Acquire a token via username and password

-When you acquire a token using `ConfidentialClientApplication.AcquireToken()` or `PublicClientApplication.AcquireToken()` with `IntegratedWindowsAuthenticationParameters` or `UsernamePasswordParameters`, MSAL for Java gets the identity provider to contact based on the username. MSAL for Java gets a [SAML 1.1 token](reference-saml-tokens.md) token from the identity provider, which it then provides to Azure AD which returns the JSON Web Token (JWT).

-## Next steps

-For the federated case, see [Configure Azure Active Directory sign-in behavior for an application by using a Home Realm Discovery policy](../manage-apps/configure-authentication-for-federated-users-portal.md)

-description: Learn how to view and remove accounts from the token cache using the Microsoft Authentication Library for Java.

-#Customer intent: As an application developer using the Microsoft Authentication Library for Java (MSAL4J), I want to learn how to get and remove accounts stored in the token cache.

-# Get and remove accounts from the token cache using MSAL for Java

-MSAL for Java provides an in-memory token cache by default. The in-memory token cache lasts the duration of the application instance.

-## See which accounts are in the cache

-You can check what accounts are in the cache by calling `PublicClientApplication.getAccounts()` as shown in the following example:

-```java

-PublicClientApplication pca = new PublicClientApplication.Builder(

- labResponse.getAppId()).

- authority(TestConstants.ORGANIZATIONS_AUTHORITY).

- build();

-Set<IAccount> accounts = pca.getAccounts().join();

-```

-## Remove accounts from the cache

-To remove an account from the cache, find the account that needs to be removed and then call `PublicClientApplication.removeAccount()` as shown in the following example:

-```java

-Set<IAccount> accounts = pca.getAccounts().join();

-IAccount accountToBeRemoved = accounts.stream().filter(

- x -> x.username().equalsIgnoreCase(

- UPN_OF_USER_TO_BE_REMOVED)).findFirst().orElse(null);

-pca.removeAccount(accountToBeRemoved).join();

-```

-## Learn more

-If you are using MSAL for Java, learn about [Custom token cache serialization in MSAL for Java](msal-java-token-cache-serialization.md).

-description: Learn how to serialize the token cache for MSAL for Java

-#Customer intent: As an application developer using the Microsoft Authentication Library for Java (MSAL4J), I want to learn how to persist the token cache so that it is available to a new instance of my application.

-# Custom token cache serialization in MSAL for Java

-To persist the token cache between instances of your application, you will need to customize the serialization. The Java classes and interfaces involved in token cache serialization are the following:

-Below is a naive implementation of custom serialization of token cache serialization/deserialization. Do not copy and paste this into a production environment.

-```Java

-static class TokenPersistence implements ITokenCacheAccessAspect {

-String data;

-TokenPersistence(String data) {

- this.data = data;

-}

-@Override

-public void beforeCacheAccess(ITokenCacheAccessContext iTokenCacheAccessContext) {

- iTokenCacheAccessContext.tokenCache().deserialize(data);

-}

-@Override

-public void afterCacheAccess(ITokenCacheAccessContext iTokenCacheAccessContext) {

- data = iTokenCacheAccessContext.tokenCache().serialize();

-}

-```

-```Java

-// Loads cache from file

-String dataToInitCache = readResource(this.getClass(), "/cache_data/serialized_cache.json");

-ITokenCacheAccessAspect persistenceAspect = new TokenPersistence(dataToInitCache);

-// By setting *TokenPersistence* on the PublicClientApplication, MSAL will call *beforeCacheAccess()* before accessing the cache and *afterCacheAccess()* after accessing the cache.

-PublicClientApplication app =

-PublicClientApplication.builder("my_client_id").setTokenCacheAccessAspect(persistenceAspect).build();

-```

-## Learn more

-Learn about [Get and remove accounts from the token cache using MSAL for Java](msal-java-get-remove-accounts-token-cache.md).

-description: Learn how to log errors and exceptions in MSAL for Java

-# Logging in MSAL for Java

-## MSAL for Java logging

-MSAL for Java allows you to use the logging library that you're already using with your app, as long as it's compatible with SLF4J. MSAL for Java uses the [Simple Logging Facade for Java](http://www.slf4j.org/) (SLF4J) as a simple facade or abstraction for various logging frameworks, such as [java.util.logging](https://docs.oracle.com/javase/7/docs/api/java/util/logging/package-summary.html), [Logback](http://logback.qos.ch/) and [Log4j](https://logging.apache.org/log4j/2.x/). SLF4J allows the user to plug in the desired logging framework at deployment time and automatically binds to Logback at deployment time. MSAL logs will be written to the console.

-This article shows how to enable MSAL4J logging using the logback framework in a spring boot web application. You can refer to the [code sample](https://github.com/Azure-Samples/ms-identity-java-webapp/tree/master/msal-java-webapp-sample) for reference.

-1. To implement logging, include the `logback` package in the *pom.xml* file.

- ```xml

- <dependency>

- <groupId>ch.qos.logback</groupId>

- <artifactId>logback-classic</artifactId>

- <version>1.2.3</version>

- </dependency>

- ```

-2. Navigate to the *resources* folder, and add a file called *logback.xml*, and insert the following code. This will append logs to the console. You can change the appender `class` to write logs to a file, database or any appender of your choosing.

- ```xml

- <?xml version="1.0" encoding="UTF-8"?>

- <configuration>

- <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">

- <encoder>

- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

- </encoder>

- </appender>

- <root level="debug">

- <appender-ref ref="STDOUT" />

- </root>

- </configuration>

- ```

-3. Next, you should set the *logging.config* property to the location of the *logback.xml* file before the main method. Navigate to *MsalWebSampleApplication.java* and add the following code to the `MsalWebSampleApplication` public class.

- ```java

- @SpringBootApplication

- public class MsalWebSampleApplication {

- static { System.setProperty("logging.config", "C:\Users\<your path>\src\main\resources\logback.xml"); }

- public static void main(String[] arrgs) {

- // Console.log("main");

- // System.console().printf("Hello");

- // System.out.printf("Hello %s!%n", "World");

- System.out.printf("%s%n", "Hello World");

- SpringApplication.run(MsalWebSampleApplication.class, args);

- }

- }

- ```

-

-In your tenant, you'll need separate app registrations for the web app and the web API. For app registration and exposing the web API scope, follow the steps in the scenario [A web app that authenticates users and calls web APIs](./scenario-web-app-call-api-overview.md).

-For instructions on how to bind to other logging frameworks, see the [SLF4J manual](http://www.slf4j.org/manual.html).

-### Personal and organization information

-By default, MSAL logging doesn't capture or log any personal or organizational data. In the following example, logging personal or organizational data is off by default:

-```java

- PublicClientApplication app2 = PublicClientApplication.builder(PUBLIC_CLIENT_ID)

- .authority(AUTHORITY)

- .build();

-```

-Turn on personal and organizational data logging by setting `logPii()` on the client application builder. If you turn on personal or organizational data logging, your app must take responsibility for safely handling highly-sensitive data and complying with any regulatory requirements.

-In the following example, logging personal or organizational data is enabled:

-```java

-PublicClientApplication app2 = PublicClientApplication.builder(PUBLIC_CLIENT_ID)

- .authority(AUTHORITY)

- .logPii(true)

- .build();

-```

-## Next steps

-For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).

-description: Learn how to log errors and exceptions in MSAL for Python

-# Logging in MSAL for Python

-## MSAL for Python logging

-Logging in MSAL for Python leverages the [logging module in the Python standard library](https://docs.python.org/3/library/logging.html). You can configure MSAL logging as follows (and see it in action in the [username_password_sample](https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/1.0.0/sample/username_password_sample.py#L31L32)):

-### Enable debug logging for all modules

-By default, the logging in any Python script is turned off. If you want to enable verbose logging for **all** Python modules in your script, use `logging.basicConfig` with a level of `logging.DEBUG`:

-```python

-import logging

-logging.basicConfig(level=logging.DEBUG)

-```

-This will print all log messages given to the logging module to the standard output.

-### Configure MSAL logging level

-You can configure the logging level of the MSAL for Python log provider by using the `logging.getLogger()` method with the logger name `"msal"`:

-```python

-import logging

-logging.getLogger("msal").setLevel(logging.WARN)

-```

-### Configure MSAL logging with Azure App Insights

-Python logs are given to a log handler, which by default is the `StreamHandler`. To send MSAL logs to an Application Insights with an Instrumentation Key, use the `AzureLogHandler` provided by the `opencensus-ext-azure` library.

-To install, `opencensus-ext-azure` add the `opencensus-ext-azure` package from PyPI to your dependencies or pip install:

-```console

-pip install opencensus-ext-azure

-```

-Then change the default handler of the `"msal"` log provider to an instance of `AzureLogHandler` with an instrumentation key set in the `APP_INSIGHTS_KEY` environment variable:

-```python

-import logging

-import os

-from opencensus.ext.azure.log_exporter import AzureLogHandler

-APP_INSIGHTS_KEY = os.getenv('APP_INSIGHTS_KEY')

-logging.getLogger("msal").addHandler(AzureLogHandler(connection_string='InstrumentationKey={0}'.format(APP_INSIGHTS_KEY)))

-```

-### Personal and organizational data in Python

-MSAL for Python does not log personal data or organizational data. There is no property to turn personal or organization data logging on or off.

-You can use standard Python logging to log whatever you want, but you are responsible for safely handling sensitive data and following regulatory requirements.

-For more information about logging in Python, please refer to Python's [Logging: how-to](https://docs.python.org/3/howto/logging.html#logging-basic-tutorial).

-## Next steps

-For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).

-Add the redirect URI to the app's registration in the [Azure portal](https://portal.azure.com). To generate a properly formatted redirect URI, use **App registrations** in the Azure portal to generate the brokered redirect URI from the bundle ID.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. Select **Azure Active Directory** > **App registrations** > your registered app

- :::image type="content" source="media/msal-net-use-brokers-with-xamarin-apps/portal-01-ios-platform-settings.png" alt-text="iOS platform settings with generated redirect URI in Azure portal":::

-MSAL uses URLs to invoke the broker and then return to your app. To complete that round trip, register a **Redirect URI** for your app by using the [Azure portal](https://portal.azure.com).

-The last part of the URI, `hgbUYHVBYUTvuvT&Y6tr554365466=`, is the Base64-encoded version of the signature that the APK is signed with. While developing your app in Visual Studio, if you're debugging your code without signing the APK with a specific certificate, Visual Studio signs the APK for you for debugging purposes. When Visual Studio signs the APK for you in this way, it gives it a unique signature for the machine it's built on. Thus, each time you build your app on a different machine, you'll need to update the redirect URI in the application's code and the application's registration in the Azure portal in order to authenticate with MSAL.

-While debugging, you may encounter an MSAL exception (or log message) stating the redirect URI provided is incorrect. **The exception or log message also indicates the redirect URI you should be using** with the current machine you're debugging on. You can use the provided redirect URI to continue developing your app as long as you update redirect URI in code and add the provided redirect URI to the app's registration in the Azure portal.

-Once you're ready to finalize your code, update the redirect URI in the code and the application's registration in the Azure portal to use the signature of the certificate you sign the APK with.

-The Microsoft identity platform does not allow you to get a token for several resources at once. When using the Microsoft Authentication Library for .NET (MSAL.NET), the scopes parameter in the acquire token method should only contain scopes for a single resource. However, you can pre-consent to several resources upfront by specifying additional scopes using the `.WithExtraScopeToConsent` builder method.

-You should use the `.WithExtraScopeToConsent` modifier which has the *extraScopesToConsent* parameter as shown in the following example:

- .WithExtraScopeToConsent(scopesForVendorApi)

-This will get you an access token for the first web API. Then, to access the second web API you can silently acquire the token from the token cache:

-AcquireTokenSilent(scopesForVendorApi, accounts.FirstOrDefault()).ExecuteAsync();

-description: Learn how to serialize token cache using MSAL for Python

-#Customer intent: As an application developer using the Microsoft Authentication Library (MSAL) for Python, I want to learn how to persist the token cache so that it is available to a new instance of my application.

-# Custom token cache serialization in MSAL for Python

-In Microsoft Authentication Library (MSAL) for Python, an in-memory token cache that persists for the duration of the app session, is provided by default when you create an instance of [ClientApplication](/python/api/msal/msal.application.confidentialclientapplication).

-Serialization of the token cache, so that different sessions of your app can access it, isn't provided "out of the box." MSAL for Python can be used in app types that don't have access to the file system--such as Web apps. To have a persistent token cache in an app that uses MSAL for Python, you must provide custom token cache serialization.

-The strategies for serializing the token cache differ depending on whether you're writing a public client application (Desktop), or a confidential client application (web app, web API, or daemon app).

-## Token cache for a public client application

-Public client applications run on a user's device and manage tokens for a single user. In this case, you could serialize the entire cache into a file. Remember to provide file locking if your app, or another app, can access the cache concurrently. For a simple example of how to serialize a token cache to a file without locking, see the example in the [SerializableTokenCache](/python/api/msal/msal.token_cache.serializabletokencache) class reference documentation.

-## Token cache for a Web app (confidential client application)

-For web apps or web APIs, you might use the session, or a Redis cache, or a database to store the token cache. There should be one token cache per user (per account) so ensure that you serialize the token cache per account.

-## Next steps

-See [ms-identity-python-webapp](https://github.com/Azure-Samples/ms-identity-python-webapp/blob/0.3.0/app.py#L66-L74) for an example of how to use the token cache for a Windows or Linux Web app or web API. The example is for a web app that calls the Microsoft Graph API.

-When you enabled the App Service authentication/authorization module, an app registration was created in your Azure AD tenant. The app registration has the same display name as your web app. To check the settings, select **Azure Active Directory** from the portal menu, and select **App registrations**. Select the app registration that was created. In the overview, verify that **Supported account types** is set to **My organization only**.

-From the portal menu, select **Azure Active Directory** > **App registrations**. Then select the application you created.

-In the app registration overview, select **Delete**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Select the application you want to configure optional claims for in the list.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. After you've authenticated, choose your Azure AD tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Select the application you want to configure optional claims for in the list.

- - idToken for the OIDC ID token

- - accessToken for the OAuth access token

- - Saml2Token for SAML tokens.

- The Saml2Token type applies to both SAML1.1 and SAML2.0 format tokens.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Find the application you want to configure optional claims for in the list and select it.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Find the application you want to configure optional claims for in the list and select it.

-## Next steps

-description: Learn about how permissions requests work for client and resource applications for applications you are developing

-# How to select permissions for a given API

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-When an app has a verified publisher, this means that the organization that publishes the app has been verified as authentic by Microsoft. Verifying an app includes using a Microsoft Cloud Partner Program (MCPP), formerly known as Microsoft Partner Network (MPN), account that's been [verified](/partner-center/verification-responses) and associating the verified PartnerID with an app registration.

- > The MPN account you use for publisher verification can't be your partner location MPN ID. Currently, location MPN IDs aren't supported for the publisher verification process.

- - In Partner Center, this user must have one of the following [roles](/partner-center/permissions-overview): MPN Partner Admin, Account Admin, or Global Administrator (a shared role that's mastered in Azure AD).

-In this quickstart, you'll register a web API with the Microsoft identity platform and expose it to client apps by adding a scope. By registering your web API and exposing it through scopes, you can provide permissions-based access to its resources to authorized users and client apps that access your API.

-With the web API registered, you can add scopes to the API's code so it can provide granular permission to consumers.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/quickstart-configure-app-expose-web-apis/portal-01-directory-subscription-filter.png" border="false"::: in the top menu to select the tenant containing your client app's registration.

-1. Select **Azure Active Directory** > **App registrations**, and then select your API's app registration.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>. Use the account you'll use to manage your application.

-> * Search and select **Azure Active Directory** > **Overview** > **Tenant ID** in the Azure portal.

-If you don't already have an Azure AD tenant or if you want to create a new one for development, see [Create a new tenant in Azure AD](../fundamentals/create-new-tenant.md) or use the [directory creation experience](https://portal.azure.com/#create/Microsoft.AzureActiveDirectory) in the Azure portal. If you want to create a tenant for app testing, see [build a test environment](test-setup-environment.md).

-You have two options to start your quickstart application: Express (Option 1 below), and Manual (Option 2)

-### Option 1: Register and auto configure your app and then download your code sample

-1. Go to the [Azure portal - App registrations](https://portal.azure.com/?Microsoft_AAD_RegisteredApps=true#blade/Microsoft_AAD_RegisteredApps/applicationsListBlade/quickStartType/JavaDaemonQuickstartPage/sourceType/docs) quickstart experience.

-1. Enter a name for your application and select **Register**.

-1. Follow the instructions to download and automatically configure your new application with just one click.

-### Option 2: Register and manually configure your application and code sample

-#### Step 1: Register your application

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-#### Step 2: Download the Java project

-#### Step 3: Configure the Java project

->To find the values of **Application (client) ID**, **Directory (tenant) ID**, go to the app's **Overview** page in the Azure portal. To generate a new key, go to **Certificates & secrets** page.

-#### Step 4: Admin consent

-##### Global tenant administrator

-If you are a global tenant administrator, go to **API Permissions** page in **App registrations** in the Azure portal and select **Grant admin consent for {Tenant Name}** (Where {Tenant Name} is the name of your directory).

-##### Standard user

-#### Step 5: Run the application

-| `CLIENT_SECRET` | Is the client secret created for the application in Azure portal. |

-| `CLIENT_ID` | Is the **Application (client) ID** for the application registered in the Azure portal. You can find this value in the app's **Overview** page in the Azure portal. |

-| `SCOPE` | Contains the scopes requested. For confidential clients, this should use the format similar to `{Application ID URI}/.default` to indicate that the scopes being requested are the ones statically defined in the app object set in the Azure portal (for Microsoft Graph, `{Application ID URI}` points to `https://graph.microsoft.com`). For custom web APIs, `{Application ID URI}` is defined under the **Expose an API** section in **App registrations** in the Azure portal.|

-## Register and download your quickstart app

-You have two options to start your quickstart application:

-* [Express] [Option 1: Register and auto configure your app and then download your code sample](#option-1-register-and-auto-configure-your-app-and-then-download-the-code-sample)

-* [Manual] [Option 2: Register and manually configure your application and code sample](#option-2-register-and-manually-configure-your-application-and-code-sample)

-### Option 1: Register and auto configure your app and then download the code sample

-#### Step 1: Register your application

-To register your app,

-1. Go to the [Azure portal - App registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/applicationsListBlade/quickStartType/IosQuickstartPage/sourceType/docs) quickstart experience.

-1. Enter a name for your application and select **Register**.

-1. Follow the instructions to download and automatically configure your new application with just one click.

-### Option 2: Register and manually configure your application and code sample

-#### Step 1: Register your application

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-1. Edit **ViewController.swift** and replace the line starting with 'let kClientID' with the following code snippet. Remember to update the value for `kClientID` with the clientID that you saved when you registered your app in the portal earlier in this quickstart:

-3. Open the project settings. In the **Identity** section, enter the **Bundle Identifier** that you entered into the portal.

-## Register and download your quickstart application

-To start your quickstart application, use either of the following options.

-### Option 1 (Express): Register and auto configure your app and then download your code sample

-1. Go to the [Azure portal - App registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade/quickStartType/AngularSpaQuickstartPage/sourceType/docs) quickstart experience.

-1. Enter a name for your application.

-1. Under **Supported account types**, select **Accounts in any organizational directory and personal Microsoft accounts**.

-1. Select **Register**.

-1. Go to the quickstart pane and follow the instructions to download and automatically configure your new application.

-### Option 2 (Manual): Register and manually configure your application and code sample

-#### Step 1: Register your application

-1. Sign in to the [Azure portal](https://portal.azure.com/).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

- To find the value of **Application (client) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of the **Directory (tenant) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of **Supported account types**, go to the app registration's **Overview** page in the Azure portal.

-To start your quickstart application, use either of the following options.

-### Option 1 (Express): Register and auto configure your app and then download your code sample

-1. Go to the [Azure portal - App registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade/quickStartType/AngularSpaQuickstartPage/sourceType/docs) quickstart experience.

-1. Enter a name for your application.

-1. Under **Supported account types**, select **Accounts in any organizational directory and personal Microsoft accounts**.

-1. Select **Register**.

-1. Go to the quickstart pane and follow the instructions to download and automatically configure your new application.

-### Option 2 (Manual): Register and manually configure your application and code sample

-#### Step 1: Register your application

-1. Sign in to the [Azure portal](https://portal.azure.com/).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-#### Step 2: Download the project

-#### Step 3: Configure your JavaScript app

- To find the value of **Application (client) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of the **Directory (tenant) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of **Supported account types**, go to the app registration's **Overview** page in the Azure portal.

-#### Step 4: Run the project

-To start your quickstart application, use either of the following options.

-### Option 1 (Express): Register and auto configure your app and then download your code sample

-1. Go to the [Azure portal - App registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade/quickStartType/AngularSpaQuickstartPage/sourceType/docs) quickstart experience.

-1. Enter a name for your application.

-1. Under **Supported account types**, select **Accounts in any organizational directory and personal Microsoft accounts**.

-1. Select **Register**.

-1. Go to the quickstart pane and follow the instructions to download and automatically configure your new application.

-### Option 2 (Manual): Register and manually configure your application and code sample

-#### Step 1: Register your application

-1. Sign in to the [Azure portal](https://portal.azure.com/).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-Under **Manage**, select **App registrations** > **New registration**.

-#### Step 2: Download the project

-#### Step 3: Configure your JavaScript app

- To find the value of **Application (client) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of the **Directory (tenant) ID**, go to the app registration's **Overview** page in the Azure portal.

- To find the value of **Supported account types**, go to the app registration's **Overview** page in the Azure portal.

-#### Step 4: Run the project

-You can configure an app's attributes through the Azure portal or programmatically using [Microsoft Graph API](/graph/api/resources/application) or [Microsoft Graph PowerShell SDK](/powershell/module/microsoft.graph.applications/?view=graph-powershell-1.0&preserve-view=true). However, there are some scenarios where you'll need to edit the app manifest to configure an app's attribute. These scenarios include:

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>. Search for and select the **Azure Active Directory** service.

-1. Select **App registrations**.

-1. From the app's **Overview** page, select the **Manifest** section. A web-based manifest editor opens, allowing you to edit the manifest within the portal. Optionally, you can select **Download** to edit the manifest locally, and then use **Upload** to reapply it to your application.

-At this time, apps that support both personal accounts and Azure AD (registered through the app registration portal) cannot use optional claims. However, apps registered for just Azure AD using the v2.0 endpoint can get the optional claims they requested in the manifest. For more info, see [Optional claims](./optional-claims.md).

-Read only value that points to the CDN URL to logo that was uploaded in the portal.

-| AADSTS50053 | This error can result from two different reasons: <br><ul><li>IdsLocked - The account is locked because the user tried to sign in too many times with an incorrect user ID or password. The user is blocked due to repeated sign-in attempts. See [Remediate risks and unblock users](../identity-protection/howto-identity-protection-remediate-unblock.md).</li><li>Or, sign-in was blocked because it came from an IP address with malicious activity.</li></ul> <br>To determine which failure reason caused this error, sign in to the [Azure portal](https://portal.azure.com). Navigate to your Azure AD tenant and then **Monitoring** -> **Sign-ins**. Find the failed user sign-in with **Sign-in error code** 50053 and check the **Failure reason**.|

-| AADSTS501241 | Mandatory Input '{paramName}' missing from transformation ID '{transformId}'. This error is returned while Azure AD is trying to build a SAML response to the application. NameID claim or NameIdentifier is mandatory in SAML response and if Azure AD failed to get source attribute for NameID claim, it will return this error. As a resolution, ensure you add claim rules in *Azure portal* > *Azure Active Directory* > *Enterprise Applications* > *Select your application* > *Single Sign-On* > *User Attributes & Claims* > *Unique User Identifier (Name ID)*. |

-| AADSTS53003 | BlockedByConditionalAccess - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. If this is unexpected, see the Conditional Access policy that applied to this request in the Azure portal or contact your administrator. For additional information, please visit [troubleshooting sign-in with Conditional Access](../conditional-access/troubleshoot-conditional-access.md). |

-| AADSTS65002 | Consent between first party application '{applicationId}' and first party resource '{resourceId}' must be configured via preauthorization - applications owned and operated by Microsoft must get approval from the API owner before requesting tokens for that API. A developer in your tenant may be attempting to reuse an App ID owned by Microsoft. This error prevents them from impersonating a Microsoft application to call other APIs. They must move to another app ID they register in the [Azure portal](https://portal.azure.com).|

-| AADSTS700054 | Response_type 'id_token' isn't enabled for the application. The application requested an ID token from the authorization endpoint, but did not have ID token implicit grant enabled. Go to Azure portal > Azure Active Directory > App registrations > Select your application > Authentication > Under 'Implicit grant and hybrid flows', make sure 'ID tokens' is selected.|

-| AADSTS90056 | BadResourceRequest - To redeem the code for an access token, the app should send a POST request to the `/token` endpoint. Also, prior to this, you should provide an authorization code and send it in the POST request to the `/token` endpoint. Refer to this article for an overview of [OAuth 2.0 authorization code flow](v2-oauth2-auth-code-flow.md). Direct the user to the `/authorize` endpoint, which will return an authorization_code. By posting a request to the `/token` endpoint, the user gets the access token. Log in the Azure portal, and check **App registrations > Endpoints** to confirm that the two endpoints were configured correctly. |

-| AADSTS7000222 | InvalidClientSecretExpiredKeysProvided - The provided client secret keys are expired. Visit the Azure portal to create new keys for your app, or consider using certificate credentials for added security: [https://aka.ms/certCreds](./certificate-credentials.md) |

-[preview-tos]: https://azure.microsoft.com/support/legal/preview-supplemental-terms/

-description: How to find the authentication endpoints for a custom application you're developing or registering with Azure AD.

-# How to discover endpoints

-You can find the authentication endpoints for your application in the [Azure portal](https://portal.azure.com).

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. Select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**, and then select **Endpoints** in the top menu.

- The **Endpoints** page is displayed, showing the authentication endpoints for your tenant.

-

- Use the endpoint that matches the authentication protocol you're using in conjunction with the **Application (client) ID** to craft the authentication request specific to your application.

-**National clouds** (for example Azure AD China, Germany, and US Government) have their own app registration portal and Azure AD authentication endpoints. Learn more in the [National clouds overview](authentication-national-cloud.md).

-## Next steps

-For more information about endpoints in the different Azure environments, see the [National clouds overview](authentication-national-cloud.md).

-description: Guidance for registering a custom developed application with Azure AD

-# Azure portal registration fields for custom-developed apps

-This article gives you a brief description of all the available fields in the application registration form in the [Azure portal](https://portal.azure.com).

-## Register a new application

-## Fields in the application registration form

-| Field | Description |

-|||

-| Name | The name of the application. It should have a minimum of four characters. |

-| Supported account types| Select which accounts you would like your application to support: accounts in this organizational directory only, accounts in any organizational directory, or accounts in any organizational directory and personal Microsoft accounts. |

-| Redirect URI (optional) | Select the type of app you're building, **Web** or **Public client (mobile & desktop)**, and then enter the redirect URI (or reply URL) for your application. For web applications, provide the base URL of your app. For example, http://localhost:31544 might be the URL for a web app running on your local machine. Users would use this URL to sign in to a web client application. For public client applications, provide the URI used by Azure AD to return token responses. Enter a value specific to your application, such as myapp://auth. To see specific examples for web applications or native applications, check out our [quickstarts](./index.yml).|

-Once you have filled the above fields, the application is registered in the Azure portal, and you are redirected to the application overview page. The settings pages in the left pane under **Manage** have more fields for you to customize your application. The tables below describe all the fields. You would only see a subset of these fields, depending on whether you created a web application or a public client application.

-### Overview

-| Field | Description |

-|--|--|

-| Application ID | When you register an application, Azure AD assigns your application an Application ID. The application ID can be used to uniquely identify your application in authentication requests to Azure AD, as well as to access resources like the Graph API. |

-| App ID URI | This should be a unique URI, usually of the form **https://&lt;tenant\_name&gt;/&lt;application\_name&gt;.** This is used during the authorization grant flow, as a unique identifier to specify the resource that the token should be issued for. It also becomes the 'aud' claim in the issued access token. |

-### Branding

-| Field | Description |

-|--|--|

-| Upload new logo | You can use this to upload a logo for your application. The logo must be in .bmp, .jpg or .png format, and the file size should be less than 100 KB. The dimensions for the image should be 215x215 pixels, with central image dimensions of 94x94 pixels.|

-| Home page URL | This is the sign-on URL specified during application registration.|

-### Authentication

-| Field | Description |

-|--|--|

-| Front-channel logout URL | This is the single sign-out logout URL. Azure AD sends a logout request to this URL when the user clears their session with Azure AD using any other registered application.|

-| Supported account types | This switch specifies whether the application can be used by multiple tenants. Typically, this means that external organizations can use your application by registering it in their tenant and granting access to their organization's data.|

-| Redirect URLs | The redirect, or reply, URLs are the endpoints where Azure AD returns any tokens that your application requests. For native applications, this is where the user is sent after successful authorization. Azure AD checks that the redirect URI your application supplies in the OAuth 2.0 request matches one of the registered values in the portal.|

-### Certificates and secrets

-| Field | Description |

-|--|--|

-| Client secrets | You can create client secrets, or keys, to programmatically access web APIs secured by Azure AD without any user interaction. From the **New client secret** page, enter a key description and the expiration date and save to generate the key. Make sure to save it somewhere secure, as you won't be able to access it later. |

-## Next steps

-[Managing Applications with Azure Active Directory](../manage-apps/what-is-application-management.md)

-description: How to configure single sign-on for a custom application you are developing and registering with Azure AD.

-# How to configure single sign-on for an application

-Enabling federated single sign-on (SSO) in your app is automatically enabled when federating through Azure AD for OpenID Connect, SAML 2.0, or WS-Fed. If your end users are having to sign in despite already having an existing session with Azure AD, itΓÇÖs likely your app may be misconfigured.

-* If youΓÇÖre using Microsoft Authentication Library (MSAL), make sure you have **PromptBehavior** set to **Auto** rather than **Always**.

-* If youΓÇÖre building a mobile app, you may need additional configurations to enable brokered or non-brokered SSO.

-For Android, see [Enabling Cross App SSO in Android](msal-android-single-sign-on.md).

-For iOS, see [Enabling Cross App SSO in iOS](single-sign-on-macos-ios.md).

-## Next steps

-[Azure AD SSO](../manage-apps/what-is-single-sign-on.md)<br>

-[Enabling Cross App SSO in Android](msal-android-single-sign-on.md)<br>

-[Enabling Cross App SSO in iOS](single-sign-on-macos-ios.md)<br>

-[Integrating Apps to AzureAD](./quickstart-register-app.md)<br>

-[Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md)<br>

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-The maximum number of redirect URIS can't be raised for [security reasons](#restrictions-on-wildcards-in-redirect-uris). If your scenario requires more redirect URIs than the maximum limit allowed, consider the following [state parameter approach](#use-a-state-parameter) as the solution.

-To view or edit the claims issued in the SAML token to the application, open the application in Azure portal. Then open the **Attributes & Claims** section.

- :::image type="content" source="./media/saml-claims-customization/saml-sso-manage-user-claims.png" alt-text="Screenshot of editing the nameID (name identifier) value in the Azure portal.":::

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the **User Attributes & Claims** section, select **Edit** to edit the claims.

-1. Select the required claim that you want to modify.

-1. Enter the constant value without quotes in the **Source attribute** as per your organization and select **Save**.

- :::image type="content" source="./media/saml-claims-customization/organization-attribute.png" alt-text="Screenshot of the organization Attributes & Claims section in the Azure portal.":::

-1. The constant value is displayed as shown in the following image.

- :::image type="content" source="./media/saml-claims-customization/edit-attributes-claims.png" alt-text="Screenshot of editing in the Attributes & Claims section in the Azure portal.":::

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the **User Attributes & Claims** section, select **Edit** to edit the claims.

-1. Select **Add new claim** or edit an existing claim.

- :::image type="content" source="./media/saml-claims-customization/mv-extension-1.jpg" alt-text="Screenshot of the MultiValue extension configuration section in the Azure portal.":::

- :::image type="content" source="./media/saml-claims-customization/mv-extension-2.jpg" alt-text="Screenshot of the source application selection in MultiValue extension configuration section in the Azure portal.":::

-1. In **User Attributes & Claims**, select **Add new claim** to open the **Manage user claims** page.

- :::image type="content" source="./media/saml-claims-customization/mv-extension-4.png" alt-text="Screenshot of claims transformation.":::

-The `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` claim is part of the [SAML restricted claim set](reference-claims-mapping-policy-type.md), so you can't add it in the **Attributes & Claims** section. As a workaround, you can add it as an [optional claim](./optional-claims.md) through **App registrations** in the Azure portal.

-When you build a mobile app that uses interactive authentication, the most critical registration step is the redirect URI. You can set interactive authentication through the [platform configuration on the **Authentication** blade](https://aka.ms/MobileAppReg).

-This experience will enable your app to get single sign-on (SSO) through Microsoft Authenticator (and Intune Company Portal on Android). It will also support device management policies.

-The app registration portal provides a preview experience to help you compute the brokered reply URI for iOS and Android applications:

-1. In the app registration portal, select **Authentication** > **Try out the new experience**.

- 

-2. Select **Add a platform**.

-3. When the list of platforms is supported, select **iOS**.

-4. Enter your bundle ID, and then select **Register**.

-1. Still in the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>, select your app in **App registrations**, and then select **Authentication**.

-*Microsoft.Identity.Web* adds extension methods to the Controller that provide convenience services to call Microsoft Graph or a downstream web API, or to get an authorization header, or even a token. The methods used to call an API directly are explained in detail in [A web app that calls web APIs: Call an API](scenario-web-app-call-api-call-api.md). With these helper methods, you don't need to manually acquire a token.

-If, however, you do want to manually acquire a token or build an authorization header, the following code shows how to use *Microsoft.Identity.Web* to do so in a controller. It calls an API (Microsoft Graph) using the REST API instead of the Microsoft Graph SDK.

-The controller methods are protected by an `[Authorize]` attribute that ensures only authenticated users can use the web app.

-In the Java sample, the code that calls an API is in the getUsersFromGraph method in [AuthPageController.java#L62](https://github.com/Azure-Samples/ms-identity-java-webapp/blob/d55ee4ac0ce2c43378f2c99fd6e6856d41bdf144/src/main/java/com/microsoft/azure/msalwebsample/AuthPageController.java#L62).

-In the Node.js sample, the code that acquires a token is in the *acquireToken* method of the **AuthProvider** class.

-In the Python sample, the code that calls the API is in `app.py`.

-description: Learn how to configure an application as multi-tenant, and how multi-tenant applications work

-# How to configure a new multi-tenant application

-Here is a list of recommended topics to learn more about multi-tenant applications:

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

- AllowedAudience = "[Your App ID URI goes here, as registered in the Azure Portal]",

-1. Pick any of the key thumbprints and configure Azure Active Directory to use that key with your application (get the app ID from the [Azure portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps)):

-1. Get the latest signing key (get the tenant ID from the [Azure portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview)):

-1. Configure Azure Active Directory to use that latest key with your application (get the app ID from the [portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps)):

-When it comes to developing apps, developers can choose to configure their app to be either single-tenant or multi-tenant during app registration in the [Azure portal](https://portal.azure.com).

-In the Azure portal, you can configure your app to be single-tenant or multi-tenant by setting the audience as follows.

-| Audience | Single/multi-tenant | Who can sign in |

-| -- | - | |

-| Accounts in this directory only | Single tenant | All user and guest accounts in your directory can use your application or API.<br>_Use this option if your target audience is internal to your organization._ |

-| Accounts in any Azure AD directory | Multi-tenant | All users and guests with a work or school account from Microsoft can use your application or API. This includes schools and businesses that use Microsoft 365.<br>_Use this option if your target audience is business or educational customers._ |

-| Accounts in any Azure AD directory and personal Microsoft accounts (such as Skype, Xbox, Outlook.com) | Multi-tenant | All users with a work or school, or personal Microsoft account can use your application or API. It includes schools and businesses that use Microsoft 365 as well as personal accounts that are used to sign in to services like Xbox and Skype.<br>_Use this option to target the widest set of Microsoft accounts._ |

-| ID | Required | Azure AD uses this attribute to populate the `InResponseTo` attribute of the returned response. ID must not begin with a number, so a common strategy is to prepend a string like "ID" to the string representation of a GUID. For example, `id6c1c178c166d486687be4aaf5e482730` is a valid ID. |

-| Version | Required | This parameter should be set to **2.0**. |

-| IssueInstant | Required | This is a DateTime string with a UTC value and [round-trip format ("o")](/dotnet/standard/base-types/standard-date-and-time-format-strings). Azure AD expects a DateTime value of this type, but doesn't evaluate or use the value. |

-| AssertionConsumerServiceURL | Optional | If provided, this parameter must match the `RedirectUri` of the cloud service in Azure AD. |

-| ForceAuthn | Optional | This is a boolean value. If true, it means that the user will be forced to re-authenticate, even if they have a valid session with Azure AD. |

-| IsPassive | Optional | This is a boolean value that specifies whether Azure AD should authenticate the user silently, without user interaction, using the session cookie if one exists. If this is true, Azure AD will attempt to authenticate the user using the session cookie. |

-All other `AuthnRequest` attributes, such as Consent, Destination, AssertionConsumerServiceIndex, AttributeConsumerServiceIndex, and ProviderName are **ignored**.

-| API permissions (`requiredResourceAccess`) | No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs. | No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs. | Maximum of 50 resources per application and 30 permissions per resource (for example, Microsoft Graph). Total limit of 200 per application (resources x permissions). |

-1. Sign in to the [Azure portal](https://portal.azure.com), then select **Azure Active Directory**.

-2. Go to **Users**.

-3. Click on **New guest user** and invite your work account email address.

-4. Repeat for other members of the development and/or testing team for your application.

-1. Sign in to the [Azure portal](https://portal.azure.com), then select on **Azure Active Directory**.

-2. Go to **Users**.

-3. Click **New user** and create some new test users in your directory.

-1. Sign in to the [Azure portal](https://portal.azure.com) using your production tenant account.

-1. Go to **Azure Active Directory** > **Enterprise applications** > **Conditional Access**.

-1. Click on **New policy**

-1. Sign in to the [Azure portal](https://portal.azure.com) using your production tenant account.

-1. Click on **Azure Active Directory**.

-1. Go to **Enterprise applications**.

-1. From your production tenant, go to **Azure Active Directory** > **Enterprise applications** > **Consent and permissions** > **User consent** settings. Copy the settings there to your test tenant.

-1. Sign in to the [Azure portal](https://portal.azure.com), then select **Azure Active Directory**.

-2. Go to **Users**.

-3. Select **New user** and create some new test users in your directory.

-1. Sign in to the [Azure portal](https://portal.azure.com), then select **Azure Active Directory**.

-2. Go to **Groups**.

-3. Click **New group**.

-4. Select either **Security** or **Microsoft 365** for group type.

-5. Name your group.

-6. Add the test users created in the previous step.

-2. Review the instructions to [mark an app as publisher verified](mark-app-as-publisher-verified.md) and ensure all steps have been performed successfully.

-3. Review the list of [common issues](#common-issues).

-4. Reproduce the request using [Graph Explorer](#making-microsoft-graph-api-calls) to gather more info and rule out any issues in the UI.

- 1. Navigate to the [MPN enrollment page](https://partner.microsoft.com/dashboard/account/v3/enrollment/joinnow/basicpartnernetwork/new).

- 2. Sign in with a user account in the org's primary Azure AD tenant.

- 3. If an MPN account already exists, this is recognized and you are added to the account.

- 4. Navigate to the [partner profile page](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) where the MPN ID and primary account contact will be listed.

- 1. Sign in to the [Azure portal](https://portal.azure.com) using a user account in your organization's primary tenant.

- 1. Browse to **Azure Active Directory** > [Roles and administrators](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RolesAndAdministrators).

- 3. Select the desired admin role.

- 4. The list of users assigned that role will be displayed.

- Go to the [MPN User Management page](https://partner.microsoft.com/pcv/users) and filter the user list to see what users are in various admin roles.

-> *verifiedPublisherID* is your MPN ID.

-The MPN ID you provided (`MPNID`) doesn't exist, or you don't have access to it. Provide a valid MPN ID and try again.

-Most commonly caused by the signed-in user not being a member of the proper role for the MPN account in Partner Center- see [requirements](publisher-verification-overview.md#requirements) for a list of eligible roles and see [common issues](#common-issues) for more information. Can also be caused by the tenant the app is registered in not being added to the MPN account, or an invalid MPN ID.

- - The MPN ID is correct.

- - There are no errors or ΓÇ£pending actionsΓÇ¥ shown, and the verification status under Legal business profile and Partner info both say ΓÇ£authorizedΓÇ¥ or ΓÇ£successΓÇ¥.

-2. Go to the [MPN tenant management page](https://partner.microsoft.com/dashboard/account/v3/tenantmanagement) and confirm that the tenant the app is registered in and that you're signing with a user account from is on the list of associated tenants. To add another tenant, follow the [multi-tenant-account instructions](/partner-center/multi-tenant-account). All Global Admins of any tenant you add will be granted Global Administrator privileges on your Partner Center account.

-3. Go to the [MPN User Management page](https://partner.microsoft.com/pcv/users) and confirm the user you're signing in as is either a Global Administrator, MPN Admin, or Accounts Admin. To add a user to a role in Partner Center, follow the instructions for [creating user accounts and setting permissions](/partner-center/create-user-accounts-and-set-permissions).

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused when an MPN ID is provided which corresponds to a Partner Location Account (PLA). Only Partner Global Accounts are supported. See [Partner Center account structure](/partner-center/account-structure) for more details.

-1. Navigate to your [partner profile](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) > Identifiers blade > Microsoft Cloud Partners Program Tab

-2. Use the Partner ID with type PartnerGlobal

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-1. Navigate to your [partner profile](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) > Identifiers blade > Microsoft Cloud Partners Program Tab

-2. Use the Partner ID with type PartnerGlobal

-The MPN ID (`MPNID`) you provided hasn't completed the vetting process. Complete this process in Partner Center and try again.

-Most commonly caused by when the MPN account hasn't completed the [verification](/partner-center/verification-responses) process.

-2. If not, view pending action items in Partner Center and troubleshoot with [here](/partner-center/verification-responses)

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-1. Navigate to your [partner profile](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) > Identifiers blade > Microsoft Cloud Partners Program Tab

-2. Use the Partner ID with type PartnerGlobal

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-1. Navigate to your [partner profile](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) > Identifiers blade > Microsoft Cloud Partners Program Tab

-2. Use the Partner ID with type PartnerGlobal

-The target application (`AppId`) canΓÇÖt be found. Provide a valid application ID and try again.

-1. The Object ID of the application must be provided, not the AppId/ClientId. See **id** on the list of application properties [here](/graph/api/resources/application)

-2. Log in to [Azure Active Directory](https://aad.portal.azure.com/) with a user account in your organization's primary tenant > Azure Active Directory > App Registrations blade

-3. Find your app's registration to view the Object ID

-1. The Object ID of the application must be provided, not the AppId/ClientId. See **id** on the list of application properties [here](/graph/api/resources/application)

-2. Log in to [Azure Active Directory](https://aad.portal.azure.com/) with a user account in your organization's primary tenant > Azure Active Directory > App Registrations blade

-3. Find your app's registration to view the Object ID

-1. Follow the directions [here](./howto-configure-publisher-domain.md#set-a-publisher-domain-in-the-azure-portal) to set a Publisher Domain

-2. The domain used to perform email verification in Partner Center is the portion after the ΓÇ£@ΓÇ¥ in the Primary ContactΓÇÖs email

-3. Log in to [Azure Active Directory](https://aad.portal.azure.com/) > Azure Active Directory > App Registrations blade > (`Your App`) > Branding and Properties

-4. Select **Update Publisher Domain** and follow the instructions to **Verify a New Domain**.

-5. Add the domain used to perform email verification in Partner Center as a New Domain

-Most commonly caused by the signed-in user not being a member of the proper role for the MPN account in Azure AD- see [requirements](publisher-verification-overview.md#requirements) for a list of eligible roles and see [common issues](#common-issues) for more information.

-1. Sign in to the [Azure AD Portal](https://aad.portal.azure.com) using a user account in your organization's primary tenant.

-2. Navigate to [Role Management](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RolesAndAdministrators).

-3. Select the desired admin role and click ΓÇ£Add AssignmentΓÇ¥ if you have sufficient permissions.

-4. If you do not have sufficient permissions, contact an admin role for assistance

-The MPN ID wasn't provided in the request body or the request content type wasn't "application/json".

-Most commonly caused when the verification is being performed via Graph API, and the MPN ID wasnΓÇÖt provided in the request.

-1. Navigate to your [partner profile](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) > Identifiers blade > Microsoft Cloud Partners Program Tab

-2. Use the Partner ID with type PartnerGlobal in the request

-2. Retry Publisher Verification

-## Register the app in the Azure portal

-| Placeholder | Azure portal name | Example |

-| - | -- | -- |

-| `{APP NAME}` | &mdash; | `BlazorWASMSample` |

-| `{TENANT ID}` | Directory (tenant) ID | `e86c78e2-0000-0000-0000-918e0565a45e` |

-1. In the Azure portal, select your app in **App registrations**.

-> - Register the app in the Azure portal

-4. Record the package name to be used in the Azure portal in later steps.

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

- - Use your Azure portal **Package name** to replace `android:host=.` value. It should look like `com.azuresamples.msalandroidapp`.

- - Use your Azure portal **Signature Hash** to replace `android:path=` value. Ensure that there's a leading `/` at the beginning of your Signature Hash. It should look like `/1wIqXSqBj7w+h11ZifsnqwgyKrY=`.

-> - Register the application in the Azure portal

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. If access to multiple tenants is available, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations > New registration**.

-1. Replace the following values with the values obtained from the Azure portal. For more information about available configurable options, see [Initialize client applications](msal-js-initializing-client-applications.md).

-The Microsoft Graph API requires the _User.Read_ scope to read a user's profile. The _User.Read_ scope is added automatically to every app registration you create in the Azure portal. Other APIs for Microsoft Graph, and custom APIs for your back-end server, might require other scopes. For example, the Microsoft Graph API requires the _Mail.Read_ scope in order to list the user's email.

-If you donΓÇÖt have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-### Choose the Azure AD tenant

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-### Register the client app (dotnet-web-daemon-v2)

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-## Configure the sample to use your Azure AD tenant

-1. Find the app key **ida:ClientId**. Replace the existing value with the application ID of the **dotnet-web-daemon-v2** application copied from the Azure portal.

-1. Find the app key **ida:ClientSecret**. Replace the existing value with the key that you saved during the creation of the **dotnet-web-daemon-v2** app in the Azure portal.

-1. Go back to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. In the left pane, select the **Azure Active Directory** service, and then select **App registrations**.

-1. Select the **dotnet-web-daemon-v2** application.

-> - Register the app in the Azure portal

-## Register your application

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-## Add your app registration

-// Update the below to your client ID you received in the portal. The below is for running the demo only

-The only value you modify is the value assigned to `kClientID` to be your [Application ID](./developer-glossary.md#application-client-id). This value is part of the MSAL Configuration data that you saved during the step at the beginning of this tutorial to register the application in the Azure portal.

-In Xcode, open _Info.plist_ as a source code file, and add the following inside of the `<dict>` section. Replace `[BUNDLE_ID]` with the value you used in the Azure portal. If you downloaded the code, the bundle identifier is `com.microsoft.identitysample.MSALiOS`. If you're creating your own project, select your project in Xcode and open the **General** tab. The bundle identifier appears in the **Identity** section.

-The first time a user signs into your app, they'll be prompted by Microsoft identity to consent to the permissions requested. While most users are capable of consenting, some Azure AD tenants have disabled user consent, which requires admins to consent on behalf of all users. To support this scenario, register your app's scopes in the Azure portal.

-> - Set up tenant and register the application in the Azure portal

-The following steps describe setting up your application in the Azure portal and putting your device into shared-device mode.

-### Register your application in Azure Active Directory

-First, register your application within your organizational tenant. Then provide these values below in auth_config.json in order for your application to run correctly.

-For information on how to do this, refer to [Register your application](./tutorial-v2-android.md#register-your-application-with-azure-ad).

-You should select **Make this change for me** and then provide the values the quickstart asks for in the Azure portal. When that's done, we'll generate all the configuration files you need.

-For testing purposes, set up the following in your tenant: at least two employees, one Cloud Device Administrator, and one Global Administrator. In the Azure portal, set the Cloud Device Administrator by modifying Organizational Roles. In the Azure portal, access your Organizational Roles by selecting **Azure Active Directory** > **Roles and Administrators** > **Cloud Device Administrator**. Add the users that can put a device into shared mode.

-## View the shared device in the Azure portal

-Once you've put a device in shared-mode, it becomes known to your organization and is tracked in your organizational tenant. You can view your shared devices by looking at the **Join Type** in the Azure Active Directory blade of your Azure portal.

-> - Register the application in the Azure portal

-APIs such as Microsoft Graph require a token to allow access to specific resources. For example, a token is required to read a userΓÇÖs profile, access a userΓÇÖs calendar, or send email. Your application can request an access token by using MSAL to access these resources by specifying API scopes. This access token is then added to the HTTP Authorization header for every call that's made against the protected resource.

-| Library | Description |

-| - | - |

-You can register your application in either of two ways.

-### Option 1: Express mode

-Use the following steps to register your application:

-1. Sign in to the <a href="https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/applicationsListBlade/quickStartType/WinDesktopQuickstartPage/sourceType/docs" target="_blank">Azure portal - App registrations</a> quickstart experience.

-1. Enter a name for your application and select **Register**.

-1. Follow the instructions to download and automatically configure your new application.

-### Option 2: Advanced mode

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which you want to register the application.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-Calling the `AcquireTokenInteractive` method results in a window that prompts users to sign in. Applications usually require users to sign in interactively the first time they need to access a protected resource. They might also need to sign in when a silent operation to acquire a token fails (for example, when a userΓÇÖs password is expired).

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations** > **New registration**.

-1. Back in the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>, under **Manage**, select **Authentication** > **Add a platform**, and then select **Mobile and desktop applications**.

-1. Under **Manage**, select **API permissions** > **Add a permission**.

-3. In the app registration portal, add the returned value in **RedirectUri** in the **Authentication** pane.

-The Microsoft identity platform supports authentication for various modern app architectures, all of them based on industry-standard protocols [OAuth 2.0 or OpenID Connect](./v2-protocols.md). This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. The information is designed to help you understand high-level scenarios before you start working with the code in the [application scenarios](authentication-flows-app-scenarios.md#application-scenarios).

-1. Set `Multi-Tenanted` property to `Yes` on your application registration's information in the [Azure portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps). By default, applications created in the Azure portal are configured as *[single-tenant](#single-tenant-applications)*.

-# Microsoft identity platform and implicit grant flow

-> To successfully request an ID token and/or an access token, the app registration in the [Azure portal - App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) page must have the corresponding implicit grant flow enabled, by selecting **ID tokens** and **access tokens** in the **Implicit grant and hybrid flows** section. If it's not enabled, an `unsupported_response` error will be returned: `The provided value for the input parameter 'response_type' is not allowed for this client. Expected value is 'code'`

-| `response_type` | required |Must include `id_token` for OpenID Connect sign-in. It may also include the response_type `token`. Using `token` here will allow your app to receive an access token immediately from the authorize endpoint without having to make a second request to the authorize endpoint. If you use the `token` response_type, the `scope` parameter must contain a scope indicating which resource to issue the token for (for example, user.read on Microsoft Graph). It can also contain `code` in place of `token` to provide an authorization code, for use in the [authorization code flow](v2-oauth2-auth-code-flow.md). This id_token+code response is sometimes called the hybrid flow. |

-| `redirect_uri` | recommended |The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect_uris you registered in the portal, except it must be URL-encoded. |

-| `scope` | required |A space-separated list of [scopes](./permissions-consent-overview.md). For OpenID Connect (id_tokens), it must include the scope `openid`, which translates to the "Sign you in" permission in the consent UI. Optionally you may also want to include the `email` and `profile` scopes for gaining access to additional user data. You may also include other scopes in this request for requesting consent to various resources, if an access token is requested. |

-| `nonce` | required |A value included in the request, generated by the app, that will be included in the resulting id_token as a claim. The app can then verify this value to mitigate token replay attacks. The value is typically a randomized, unique string that can be used to identify the origin of the request. Only required when an id_token is requested. |

-| `prompt` | optional |Indicates the type of user interaction that is required. The only valid values at this time are 'login', 'none', 'select_account', and 'consent'. `prompt=login` will force the user to enter their credentials on that request, negating single-sign on. `prompt=none` is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform will return an error. `prompt=select_account` sends the user to an account picker where all of the accounts remembered in the session will appear. `prompt=consent` will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app. |

-| `token_type` |Included if `response_type` includes `token`. Will always be `Bearer`. |

-| `id_token` | A signed JSON Web Token (JWT). The app can decode the segments of this token to request information about the user who signed in. The app can cache the values and display them, but it shouldn't rely on them for any authorization or security boundaries. For more information about id_tokens, see the [`id_token reference`](id-tokens.md). <br> **Note:** Only provided if `openid` scope was requested and `response_type` included `id_tokens`. |

->`https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&response_mode=fragment&state=12345&nonce=678910&prompt=none&login_hint={your-username}`

-| `token_type` | Will always be `Bearer`. |

-| `scope` | Indicates the scope(s) for which the access_token will be valid. May not include all of the scopes requested, if they weren't applicable to the user (in the case of Azure AD-only scopes being requested when a personal account is used to log in). |

-The implicit grant does not provide refresh tokens. Both `id_token`s and `access_token`s will expire after a short period of time, so your app must be prepared to refresh these tokens periodically. To refresh either type of token, you can perform the same hidden iframe request from above using the `prompt=none` parameter to control the identity platform's behavior. If you want to receive a new `id_token`, be sure to use `id_token` in the `response_type` and `scope=openid`, as well as a `nonce` parameter.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations > New registration**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations > New registration**.

-## May 2023

-### New articles

-### Updated articles

-By adding Azure AD roles to the local administrators group, you can update the users that can manage a device anytime in Azure AD without modifying anything on the device. Azure AD also adds the Azure AD joined device local administrator role to the local administrators group to support the principle of least privilege (PoLP). In addition to the global administrators, you can also enable users that have been *only* assigned the device administrator role to manage a device.

-## Manage the global administrators role

-To view and update the membership of the Global Administrator role, see:

-## Manage the device administrator role

-In the Azure portal, you can manage the device administrator role from **Device settings**.

-1. Sign in to the [Azure portal](https://portal.azure.com) as a Global Administrator.

-1. Browse to **Azure Active Directory** > **Devices** > **Device settings**.

-To modify the device administrator role, configure **Additional local administrators on all Azure AD joined devices**.

-Device administrators are assigned to all Azure AD joined devices. You canΓÇÖt scope device administrators to a specific set of devices. Updating the device administrator role doesn't necessarily have an immediate impact on the affected users. On devices where a user is already signed into, the privilege elevation takes place when *both* the below actions happen:

-Users won't be listed in the local administrator group, the permissions are received through the Primary Refresh Token.

-Starting with Windows 10 version 20H2, you can use Azure AD groups to manage administrator privileges on Azure AD joined devices with the [Local Users and Groups](/windows/client-management/mdm/policy-csp-localusersandgroups) MDM policy. This policy allows you to assign individual users or Azure AD groups to the local administrators group on an Azure AD joined device, providing you the granularity to configure distinct administrators for different groups of devices.

- 1. Windows registers the device in the organizationΓÇÖs directory in Azure AD and enrolls it in mobile device management, if applicable.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Browse to **Azure Active Directory** > **Devices** > **Enterprise State Roaming**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Browse to **Azure Active Directory** > **Users** > **All users**.

-**Potential issue**: The field for **SettingsUrl** is empty and the device doesn't sync. The user may have last logged in to the device before Enterprise State Roaming was enabled in the Azure portal. Restart the device and have the user login. Optionally, in the portal, try having the IT Admin navigate to **Azure Active Directory** > **Devices** > **Enterprise State Roaming** disable and re-enable **Users may sync settings and app data across devices**. Once re-enabled, restart the device and have the user login. If this doesn't resolve the issue, **SettingsUrl** may be empty if there's a bad device certificate. In this case, running ΓÇ£*dsregcmd.exe /leave*ΓÇ¥ in an elevated command prompt window, rebooting, and trying registration again may help with this issue.

-1. Go to the devices page using a [direct link](https://portal.azure.com/#blade/Microsoft_AAD_IAM/DevicesMenuBlade/Devices).

-2. Information on how to locate a device can be found in [How to manage device identities using the Azure portal](./manage-device-identities.md).

-3. If the **Registered** column says **Pending**, then hybrid Azure AD join hasn't completed. In federated environments, this state happens only if it failed to register and Azure AD Connect is configured to sync the devices. Wait for Azure AD Connect to complete a sync cycle.

-4. If the **Registered** column contains a **date/time**, then hybrid Azure AD join has completed.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-1. Sign in to the **Azure portal** as a [Cloud Device Administrator](../roles/permissions-reference.md#cloud-device-administrator).

-1. Browse to **Azure Active Directory** > **Devices** > **Device settings**

- 

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

-> If a device object with the same displayMame as the hostname of a VM where an extension is installed exists, the VM fails to join Azure AD with a hostname duplication error. Avoid duplication by [modifying the hostname](../../virtual-network/virtual-networks-viewing-and-modifying-hostnames.md#modify-a-hostname).

- 

- > Replace `<TenantID>` with the Azure AD tenant ID that's associated with the Azure subscription. If you need to find the tenant ID, you can hover over your account name or select **Azure Active Directory** > **Properties** > **Directory ID** in the Azure portal.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

-* If you have multiple verified domain names (as shown in the Azure portal or via the **Get-MsolDomain** cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing **issuerid** claim that might have been created by Azure AD Connect or via other means. Here's an example for this rule:

-Beginning with version 1.1.819.0, Azure AD Connect provides you with a wizard to configure hybrid Azure AD join. The wizard enables you to significantly simplify the configuration process. If installing the required version of Azure AD Connect isn't an option for you, see [how to manually configure device registration](hybrid-join-manual.md).

-[](./media/manage-device-identities/devices-azure-portal.png#lightbox)

-1. Sign in to the [Azure portal](https://portal.azure.com).

-[](./media/manage-device-identities/all-devices-azure-portal.png#lightbox)

-1. Sign in to the [Azure portal](https://portal.azure.com).

-2. Go to **Azure Active Directory** > **Devices** > **All devices**.

-3. Select the **Preview features** button.

-4. Turn on the toggle that says **Enhanced devices list experience**. Select **Apply**.

-5. Refresh your browser.

-You must be assigned one of the following roles to view device settings in the Azure portal:

-You must be assigned one of the following roles to manage device settings in the Azure portal:

-#Customer intent: As an IT admin, I want to understand how I can get rid of stale devices, so that I can I can cleanup my device registration data.

- :::image type="content" source="./media/manage-stale-devices/01.png" alt-text="Screenshot of a page in the Azure portal listing the name, owner, and other information on devices. One column lists the activity time stamp." border="false":::

-To get an overview of how to manage device in the Azure portal, see [managing devices using the Azure portal](manage-device-identities.md)

-1. Sign in to the **Azure portal**.

-1. Browse to **Azure Active Directory** > **Devices** > **Diagnose and solve problems**.

-| **AADSTS50155: Device authentication failed** | <li>Azure AD is unable to authenticate the device to issue a PRT.<li>Confirm that the device hasn't been deleted or disabled in the Azure portal. For more information about this issue, see [Azure Active Directory device management FAQ](faq.yml#why-do-my-users-see-an-error-message-saying--your-organization-has-deleted-the-device--or--your-organization-has-disabled-the-device--on-their-windows-10-11-devices). | Follow the instructions for this issue in [Azure Active Directory device management FAQ](faq.yml#i-disabled-or-deleted-my-device-in-the-azure-portal-or-by-using-windows-powershell--but-the-local-state-on-the-device-says-it-s-still-registered--what-should-i-do) to re-register the device based on the device join type. |

-If the device wasn't hybrid Azure AD joined, you can attempt to do hybrid Azure AD join by clicking on the "Join" button. If the attempt to do hybrid Azure AD join fails, the details about the failure will be shown.

- - If your organization uses Azure AD Seamless Single Sign-On, `https://autologon.microsoftazuread-sso.com` or `https://aadg.windows.net.nsatc.net` aren't present on the device's IE intranet settings.

-Re-register the device based on the device join type. For instructions, see [I disabled or deleted my device in the Azure portal or by using Windows PowerShell. But the local state on the device says it's still registered. What should I do?](./faq.yml#i-disabled-or-deleted-my-device-in-the-azure-portal-or-by-using-windows-powershell--but-the-local-state-on-the-device-says-it-s-still-registered--what-should-i-do).