+If you're testing this POST HTTP request, you can use any HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview) or [Postman](https://www.postman.com/).

+

+If you're testing this POST HTTP request, you can use any HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview) or [Postman](https://www.postman.com/).

+To use your own web application firewall in front of Azure Front Door, you need to configure and validate that everything works correctly with your Azure AD B2C user flows, or custom policies.

+| [Groups](../active-directory/fundamentals/active-directory-groups-create-azure-portal.md) | Groups can be used to manage administrative and user accounts.| Groups can be used to manage administrative accounts. [Consumer accounts](user-overview.md#consumer-user) can't be member of any group, so you can't perform [group-based assignment of enterprise applications](../active-directory/manage-apps/assign-user-or-group-access-portal.md).|

+| [Premium P1](https://azure.microsoft.com/pricing/details/active-directory) | Fully supported for Azure AD premium P1 features. For example, [Password Protection](../active-directory/authentication/concept-password-ban-bad.md), [Hybrid Identities](../active-directory/hybrid/whatis-hybrid-identity.md), [Conditional Access](../active-directory/roles/permissions-reference.md#), [Dynamic groups](../active-directory/enterprise-users/groups-create-rule.md), and more. | Azure AD B2C uses [Azure AD B2C Premium P1 license](https://azure.microsoft.com/pricing/details/active-directory/external-identities/), which is different from Azure AD premium P1. A subset of Azure AD Conditional Access features is supported with [consumer accounts](user-overview.md#consumer-user). Learn how to configure Azure AD B2C [Conditional Access](conditional-access-user-flow.md).|

+| [Premium P2](https://azure.microsoft.com/pricing/details/active-directory/) | Fully supported for Azure AD premium P2 features. For example, [Identity Protection](../active-directory/identity-protection/overview-identity-protection.md), and [Identity Governance](../active-directory/governance/identity-governance-overview.md). | Azure AD B2C uses [Azure AD B2C Premium P2 license](https://azure.microsoft.com/pricing/details/active-directory/external-identities/), which is different from Azure AD premium P2. A subset of Azure AD Identity Protection features is supported with [consumer accounts](user-overview.md#consumer-user). Learn how to [Investigate risk with Identity Protection](identity-protection-investigate-risk.md) and configure Azure AD B2C [Conditional Access](conditional-access-user-flow.md). |

+> **Other Azure resources in your tenant:** <br>In an Azure AD B2C tenant, you can't provision other Azure resources such as virtual machines, Azure web apps, or Azure functions. You must create these resources in your Azure AD tenant.

+ - Azure Event Hubs

+ - Azure Service Bus

+ - [Azure SQL Database](../../azure-sql/database/conditional-access-configure.md)

+ - SQL Managed Instance

+ - Azure Synapse

+ - Visual Studio subscriptions administrator portal

+> The Microsoft Azure Management application applies to [Azure PowerShell](/powershell/azure/what-is-azure-powershell), which calls the [Azure Resource Manager API](../../azure-resource-manager/management/overview.md). It does not apply to [Azure AD PowerShell](/powershell/azure/active-directory/overview), which calls the [Microsoft Graph API](/graph/overview).

+For more information on how to set up a sample policy for Microsoft Azure Management, see [Conditional Access: Require MFA for Azure management](howto-conditional-access-policy-azure-management.md).

+For Azure Government, you should target the Azure Government Cloud Management API application.

+> [!CAUTION]

+> Make sure you understand how Conditional Access works before setting up a policy to manage access to Microsoft Azure Management. Make sure you don't create conditions that could block your own access to the portal.

+Applications that are only accessing resources (for example, Microsoft Graph, KeyVault, Outlook API, and other Microsoft APIs) generally only obtain a token and pass it along to the resource owner. Given that they are not protecting any resources, they do not inspect the token and therefore do not need to ensure it is properly signed.

+Applications that are only accessing resources (such as Microsoft Graph, KeyVault, Outlook API, and other Microsoft APIs) generally only obtain a token and pass it along to the resource owner. Given that they are not protecting any resources, they do not inspect the token and therefore do not need to ensure it is properly signed.

+ Title: "Learn about Microsoft Authentication Extensions for Node | Azure"

+description: The Microsoft Authentication Extensions for Node enables application developers to perform cross-platform token cache serialization and persistence. It gives extra support to the Microsoft Authentication Library for Node (MSAL Node).

+#Customer intent: As an application developer, I want to learn how to use the Microsoft Authentication Extensions for Node to perform cross-platform token cache serialization and persistence.

+# Microsoft Authentication Extensions for Node

+The Microsoft Authentication Extensions for Node enables developers to perform cross-platform token cache serialization and persistence to disk. It gives extra support to the Microsoft Authentication Library (MSAL) for Node.

+The [MSAL for Node](tutorial-v2-nodejs-webapp-msal.md) supports an in-memory cache by default and provides the ICachePlugin interface to perform cache serialization, but doesn't provide a default way of storing the token cache to disk. The Microsoft Authentication Extensions for Node is the default implementation for persisting cache to disk across different platforms.

+The Microsoft Authentication Extensions for Node support the following platforms:

+- Windows - Data protection API (DPAPI) is used for protection.

+- Mac - The Mac Keychain is used.

+- Linux - LibSecret is used for storing to "Secret Service".

+## Installation

+The `msal-node-extensions` package is available on Node Package Manager (NPM).

+```bash

+npm i @azure/msal-node-extensions --save

+```

+## Configure the token cache

+Here's an example of code that uses Microsoft Authentication Extensions for Node to configure the token cache.

+```javascript

+const {

+ DataProtectionScope,

+ Environment,

+ PersistenceCreator,

+ PersistenceCachePlugin,

+} = require("@azure/msal-node-extensions");

+// You can use the helper functions provided through the Environment class to construct your cache path

+// The helper functions provide consistent implementations across Windows, Mac and Linux.

+const cachePath = path.join(Environment.getUserRootDirectory(), "./cache.json");

+const persistenceConfiguration = {

+ cachePath,

+ dataProtectionScope: DataProtectionScope.CurrentUser,

+ serviceName: "<SERVICE-NAME>",

+ accountName: "<ACCOUNT-NAME>",

+ usePlaintextFileOnLinux: false,

+};

+// The PersistenceCreator obfuscates a lot of the complexity by doing the following actions for you :-

+// 1. Detects the environment the application is running on and initializes the right persistence instance for the environment.

+// 2. Performs persistence validation for you.

+// 3. Performs any fallbacks if necessary.

+PersistenceCreator.createPersistence(persistenceConfiguration).then(

+ async (persistence) => {

+ const publicClientConfig = {

+ auth: {

+ clientId: "<CLIENT-ID>",

+ authority: "<AUTHORITY>",

+ },

+ // This hooks up the cross-platform cache into MSAL

+ cache: {

+ cachePlugin: new PersistenceCachePlugin(persistence),

+ },

+ };

+ const pca = new msal.PublicClientApplication(publicClientConfig);

+ // Use the public client application as required...

+ }

+);

+```

+The following table provides an explanation for all the arguments for the persistence configuration.

+| Field Name | Description | Required For |

+| -- | | - |

+| cachePath | The path to the lock file the library uses to synchronize the reads and the writes | Windows, Mac, and Linux |

+| dataProtectionScope | Specifies the scope of the data protection on Windows either the current user or the local machine. | Windows |

+| serviceName | Specifies the service name to be used on Mac and/or Linux | Mac and Linux |

+| accountName | Specifies the account name to be used on Mac and/or Linux | Mac and Linux |

+| usePlaintextFileOnLinux | The flag to default to plain text on linux if LibSecret fails. Defaults to `false` | Linux |

+## Next steps

+For more information about Microsoft Authentication Extensions for Node and MSAL Node, see:

+- [Microsoft Authentication Extensions for Node](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/extensions/msal-node-extensions)

+- [Microsoft Authentication Library for Node](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. We're currently working on a fix, but for now, please use the link below - it should take you to the right article:

+>

+> > [Quickstart: Android app with user sign-in](mobile-app-quickstart.md?pivots=devlang-android)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how an Android application can sign in users and get an access token to call the Microsoft Graph API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> Applications must be represented by an app object in Azure Active Directory so that the Microsoft identity platform can provide tokens to your application.

+>

+> ## Prerequisites

+>

+> * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> * Android Studio

+> * Android 16+

+>

+> ### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work, add a **Redirect URI** compatible with the Auth broker.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes

+>

+> ### Step 2: Download the project

+>

+> Run the project using Android Studio.

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-android-java/archive/master.zip)

+>

+>

+> ### Step 3: Your app is configured and ready to run

+>

+> We have configured your project with values of your app's properties and it's ready to run.

+> The sample app starts on the **Single Account Mode** screen. A default scope, **user.read**, is provided by default, which is used when reading your own profile data during the Microsoft Graph API call. The URL for the Microsoft Graph API call is provided by default. You can change both of these if you wish.

+>

+> 

+>

+> Use the app menu to change between single and multiple account modes.

+>

+> In single account mode, sign in using a work or home account:

+>

+> 1. Select **Get graph data interactively** to prompt the user for their credentials. You'll see the output from the call to the Microsoft Graph API in the bottom of the screen.

+> 2. Once signed in, select **Get graph data silently** to make a call to the Microsoft Graph API without prompting the user for credentials again. You'll see the output from the call to the Microsoft Graph API in the bottom of the screen.

+>

+> In multiple account mode, you can repeat the same steps. Additionally, you can remove the signed-in account, which also removes the cached tokens for that account.

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> ## How the sample works

+> 

+>

+>

+> The code is organized into fragments that show how to write a single and multiple accounts MSAL app. The code files are organized as follows:

+>

+> | File | Demonstrates |

+> |||

+> | MainActivity | Manages the UI |

+> | MSGraphRequestWrapper | Calls the Microsoft Graph API using the token provided by MSAL |

+> | MultipleAccountModeFragment | Initializes a multi-account application, loads a user account, and gets a token to call the Microsoft Graph API |

+> | SingleAccountModeFragment | Initializes a single-account application, loads a user account, and gets a token to call the Microsoft Graph API |

+> | res/auth_config_multiple_account.json | The multiple account configuration file |

+> | res/auth_config_single_account.json | The single account configuration file |

+> | Gradle Scripts/build.grade (Module:app) | The MSAL library dependencies are added here |

+>

+> We'll now look at these files in more detail and call out the MSAL-specific code in each.

+>

+> ### Adding MSAL to the app

+>

+> MSAL ([com.microsoft.identity.client](https://javadoc.io/doc/com.microsoft.identity.client/msal)) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. Gradle 3.0+ installs the library when you add the following to **Gradle Scripts** > **build.gradle (Module: app)** under **Dependencies**:

+>

+> ```java

+> dependencies {

+> ...

+> implementation 'com.microsoft.identity.client:msal:2.+'

+> ...

+> }

+> ```

+>

+> This instructs Gradle to download and build MSAL from maven central.

+>

+> You must also add references to maven to the **allprojects** > **repositories** portion of the **build.gradle (Module: app)** like so:

+>

+> ```java

+> allprojects {

+> repositories {

+> mavenCentral()

+> google()

+> mavenLocal()

+> maven {

+> url 'https://pkgs.dev.azure.com/MicrosoftDeviceSDK/DuoSDK-Public/_packaging/Duo-SDK-Feed/maven/v1'

+> }

+> maven {

+> name "vsts-maven-adal-android"

+> url "https://identitydivision.pkgs.visualstudio.com/_packaging/AndroidADAL/maven/v1"

+> credentials {

+> username System.getenv("ENV_VSTS_MVN_ANDROIDADAL_USERNAME") != null ? System.getenv("ENV_VSTS_MVN_ANDROIDADAL_USERNAME") : project.findProperty("vstsUsername")

+> password System.getenv("ENV_VSTS_MVN_ANDROIDADAL_ACCESSTOKEN") != null ? System.getenv("ENV_VSTS_MVN_ANDROIDADAL_ACCESSTOKEN") : project.findProperty("vstsMavenAccessToken")

+> }

+> }

+> jcenter()

+> }

+> }

+> ```

+>

+> ### MSAL imports

+>

+> The imports that are relevant to the MSAL library are `com.microsoft.identity.client.*`. For example, you'll see `import > com.microsoft.identity.client.PublicClientApplication;` which is the namespace for the `PublicClientApplication` class, which represents your public client application.

+>

+> ### SingleAccountModeFragment.java

+>

+> This file demonstrates how to create a single account MSAL app and call a Microsoft Graph API.

+>

+> Single account apps are only used by a single user. For example, you might just have one account that you sign into your mapping app with.

+>

+> #### Single account MSAL initialization

+>

+> In `auth_config_single_account.json`, in `onCreateView()`, a single account `PublicClientApplication` is created using the config information stored in the `auth_config_single_account.json` file. This is how you initialize the MSAL library for use in a single-account MSAL app:

+>

+> ```java

+> ...

+> // Creates a PublicClientApplication object with res/raw/auth_config_single_account.json

+> PublicClientApplication.createSingleAccountPublicClientApplication(getContext(),

+> R.raw.auth_config_single_account,

+> new IPublicClientApplication.ISingleAccountApplicationCreatedListener() {

+> @Override

+> public void onCreated(ISingleAccountPublicClientApplication application) {

+> /**

+> * This test app assumes that the app is only going to support one account.

+> * This requires "account_mode" : "SINGLE" in the config json file.

+> **/

+> mSingleAccountApp = application;

+> loadAccount();

+> }

+>

+> @Override

+> public void onError(MsalException exception) {

+> displayError(exception);

+> }

+> });

+> ```

+>

+> #### Sign in a user

+>

+> In `SingleAccountModeFragment.java`, the code to sign in a user is in `initializeUI()`, in the `signInButton` click handler.

+>

+> Call `signIn()` before trying to acquire tokens. `signIn()` behaves as though `acquireToken()` is called, resulting in an interactive prompt for the user to sign in.

+>

+> Signing in a user is an asynchronous operation. A callback is passed that calls the Microsoft Graph API and update the UI once the user signs in:

+>

+> ```java

+> mSingleAccountApp.signIn(getActivity(), null, getScopes(), getAuthInteractiveCallback());

+> ```

+>

+> #### Sign out a user

+>

+> In `SingleAccountModeFragment.java`, the code to sign out a user is in `initializeUI()`, in the `signOutButton` click handler. Signing a user out is an asynchronous operation. Signing the user out also clears the token cache for that account. A callback is created to update the UI once the user account is signed out:

+>

+> ```java

+> mSingleAccountApp.signOut(new ISingleAccountPublicClientApplication.SignOutCallback() {

+> @Override

+> public void onSignOut() {

+> updateUI(null);

+> performOperationOnSignOut();

+> }

+>

+> @Override

+> public void onError(@NonNull MsalException exception) {

+> displayError(exception);

+> }

+> });

+> ```

+>

+> #### Get a token interactively or silently

+>

+> To present the fewest number of prompts to the user, you'll typically get a token silently. Then, if there's an error, attempt to get to token interactively. The first time the app calls `signIn()`, it effectively acts as a call to `acquireToken()`, which will prompt the user for credentials.

+>

+> Some situations when the user may be prompted to select their account, enter their credentials, or consent to the permissions your app has requested are:

+>

+> * The first time the user signs in to the application

+> * If a user resets their password, they'll need to enter their credentials

+> * If consent is revoked

+> * If your app explicitly requires consent

+> * When your application is requesting access to a resource for the first time

+> * When MFA or other Conditional Access policies are required

+>

+> The code to get a token interactively, that is with UI that will involve the user, is in `SingleAccountModeFragment.java`, in `initializeUI()`, in the `callGraphApiInteractiveButton` click handler:

+>

+> ```java

+> /**

+> * If acquireTokenSilent() returns an error that requires an interaction (MsalUiRequiredException),

+> * invoke acquireToken() to have the user resolve the interrupt interactively.

+> *

+> * Some example scenarios are

+> * - password change

+> * - the resource you're acquiring a token for has a stricter set of requirement than your Single Sign-On refresh token.

+> * - you're introducing a new scope which the user has never consented for.

+> **/

+> mSingleAccountApp.acquireToken(getActivity(), getScopes(), getAuthInteractiveCallback());

+> ```

+>

+> If the user has already signed in, `acquireTokenSilentAsync()` allows apps to request tokens silently as shown in > `initializeUI()`, in the `callGraphApiSilentButton` click handler:

+>

+> ```java

+> /**

+> * Once you've signed the user in,

+> * you can perform acquireTokenSilent to obtain resources without interrupting the user.

+> **/

+> mSingleAccountApp.acquireTokenSilentAsync(getScopes(), AUTHORITY, getAuthSilentCallback());

+> ```

+>

+> #### Load an account

+>

+> The code to load an account is in `SingleAccountModeFragment.java` in `loadAccount()`. Loading the user's account is an asynchronous operation, so callbacks to handle when the account loads, changes, or an error occurs is passed to MSAL. The following code also handles `onAccountChanged()`, which occurs when an account is removed, the user changes to another account, and so on.

+>

+> ```java

+> private void loadAccount() {

+> ...

+>

+> mSingleAccountApp.getCurrentAccountAsync(new ISingleAccountPublicClientApplication.CurrentAccountCallback() {

+> @Override

+> public void onAccountLoaded(@Nullable IAccount activeAccount) {

+> // You can use the account data to update your UI or your app database.

+> updateUI(activeAccount);

+> }

+>

+> @Override

+> public void onAccountChanged(@Nullable IAccount priorAccount, @Nullable IAccount currentAccount) {

+> if (currentAccount == null) {

+> // Perform a cleanup task as the signed-in account changed.

+> performOperationOnSignOut();

+> }

+> }

+>

+> @Override

+> public void onError(@NonNull MsalException exception) {

+> displayError(exception);

+> }

+> });

+> ```

+>

+> #### Call Microsoft Graph

+>

+> When a user is signed in, the call to Microsoft Graph is made via an HTTP request by `callGraphAPI()` which is defined in `SingleAccountModeFragment.java`. This function is a wrapper that simplifies the sample by doing some tasks such as getting the access token from the `authenticationResult` and packaging the call to the MSGraphRequestWrapper, and displaying the results of the call.

+>

+> ```java

+> private void callGraphAPI(final IAuthenticationResult authenticationResult) {

+> MSGraphRequestWrapper.callGraphAPIUsingVolley(

+> getContext(),

+> graphResourceTextView.getText().toString(),

+> authenticationResult.getAccessToken(),

+> new Response.Listener<JSONObject>() {

+> @Override

+> public void onResponse(JSONObject response) {

+> /* Successfully called graph, process data and send to UI */

+> ...

+> }

+> },

+> new Response.ErrorListener() {

+> @Override

+> public void onErrorResponse(VolleyError error) {

+> ...

+> }

+> });

+> }

+> ```

+>

+> ### auth_config_single_account.json

+>

+> This is the configuration file for a MSAL app that uses a single account.

+>

+> See [Understand the Android MSAL configuration file ](msal-configuration.md) for an explanation of these fields.

+>

+> Note the presence of `"account_mode" : "SINGLE"`, which configures this app to use a single account.

+>

+> `"client_id"` is preconfigured to use an app object registration that Microsoft maintains.

+> `"redirect_uri"`is preconfigured to use the signing key provided with the code sample.

+>

+> ```json

+> {

+> "client_id" : "0984a7b6-bc13-4141-8b0d-8f767e136bb7",

+> "authorization_user_agent" : "DEFAULT",

+> "redirect_uri" : "msauth://com.azuresamples.msalandroidapp/1wIqXSqBj7w%2Bh11ZifsnqwgyKrY%3D",

+> "account_mode" : "SINGLE",

+> "broker_redirect_uri_registered": true,

+> "authorities" : [

+> {

+> "type": "AAD",

+> "audience": {

+> "type": "AzureADandPersonalMicrosoftAccount",

+> "tenant_id": "common"

+> }

+> }

+> ]

+> }

+> ```

+>

+> ### MultipleAccountModeFragment.java

+>

+> This file demonstrates how to create a multiple account MSAL app and call a Microsoft Graph API.

+>

+> An example of a multiple account app is a mail app that allows you to work with multiple user accounts such as a work account and a personal account.

+>

+> #### Multiple account MSAL initialization

+>

+> In the `MultipleAccountModeFragment.java` file, in `onCreateView()`, a multiple account app object (`IMultipleAccountPublicClientApplication`) is created using the config information stored in the `auth_config_multiple_account.json file`:

+>

+> ```java

+> // Creates a PublicClientApplication object with res/raw/auth_config_multiple_account.json

+> PublicClientApplication.createMultipleAccountPublicClientApplication(getContext(),

+> R.raw.auth_config_multiple_account,

+> new IPublicClientApplication.IMultipleAccountApplicationCreatedListener() {

+> @Override

+> public void onCreated(IMultipleAccountPublicClientApplication application) {

+> mMultipleAccountApp = application;

+> loadAccounts();

+> }

+>

+> @Override

+> public void onError(MsalException exception) {

+> ...

+> }

+> });

+> ```

+>

+> The created `MultipleAccountPublicClientApplication` object is stored in a class member variable so that it can be used to interact with the MSAL library to acquire tokens and load and remove the user account.

+>

+> #### Load an account

+>

+> Multiple account apps usually call `getAccounts()` to select the account to use for MSAL operations. The code to load an account is in the `MultipleAccountModeFragment.java` file, in `loadAccounts()`. Loading the user's account is an asynchronous operation. So a callback handles the situations when the account is loaded, changes, or an error occurs.

+>

+> ```java

+> /**

+> * Load currently signed-in accounts, if there's any.

+> **/

+> private void loadAccounts() {

+> if (mMultipleAccountApp == null) {

+> return;

+> }

+>

+> mMultipleAccountApp.getAccounts(new IPublicClientApplication.LoadAccountsCallback() {

+> @Override

+> public void onTaskCompleted(final List<IAccount> result) {

+> // You can use the account data to update your UI or your app database.

+> accountList = result;

+> updateUI(accountList);

+> }

+>

+> @Override

+> public void onError(MsalException exception) {

+> displayError(exception);

+> }

+> });

+> }

+> ```

+>

+> #### Get a token interactively or silently

+>

+> Some situations when the user may be prompted to select their account, enter their credentials, or consent to the permissions your app has requested are:

+>

+> * The first time users sign in to the application

+> * If a user resets their password, they'll need to enter their credentials

+> * If consent is revoked

+> * If your app explicitly requires consent

+> * When your application is requesting access to a resource for the first time

+> * When MFA or other Conditional Access policies are required

+>

+> Multiple account apps should typically acquire tokens interactively, that is with UI that involves the user, with a call to `acquireToken()`. The code to get a token interactively is in the `MultipleAccountModeFragment.java` file in `initializeUI> ()`, in the `callGraphApiInteractiveButton` click handler:

+>

+> ```java

+> /**

+> * Acquire token interactively. It will also create an account object for the silent call as a result (to be obtained by > getAccount()).

+> *

+> * If acquireTokenSilent() returns an error that requires an interaction,

+> * invoke acquireToken() to have the user resolve the interrupt interactively.

+> *

+> * Some example scenarios are

+> * - password change

+> * - the resource you're acquiring a token for has a stricter set of requirement than your SSO refresh token.

+> * - you're introducing a new scope which the user has never consented for.

+> **/

+> mMultipleAccountApp.acquireToken(getActivity(), getScopes(), getAuthInteractiveCallback());

+> ```

+>

+> Apps shouldn't require the user to sign in every time they request a token. If the user has already signed in, `acquireTokenSilentAsync()` allows apps to request tokens without prompting the user, as shown in the `MultipleAccountModeFragment.java` file, in`initializeUI()` in the `callGraphApiSilentButton` click handler:

+>

+> ```java

+> /**

+> * Performs acquireToken without interrupting the user.

+> *

+> * This requires an account object of the account you're obtaining a token for.

+> * (can be obtained via getAccount()).

+> */

+> mMultipleAccountApp.acquireTokenSilentAsync(getScopes(),

+> accountList.get(accountListSpinner.getSelectedItemPosition()),

+> AUTHORITY,

+> getAuthSilentCallback());

+> ```

+>

+> #### Remove an account

+>

+> The code to remove an account, and any cached tokens for the account, is in the `MultipleAccountModeFragment.java` file in `initializeUI()` in the handler for the remove account button. Before you can remove an account, you need an account object, which you obtain from MSAL methods like `getAccounts()` and `acquireToken()`. Because removing an account is an asynchronous operation, the `onRemoved` callback is supplied to update the UI.

+>

+> ```java

+> /**

+> * Removes the selected account and cached tokens from this app (or device, if the device is in shared mode).

+> **/

+> mMultipleAccountApp.removeAccount(accountList.get(accountListSpinner.getSelectedItemPosition()),

+> new IMultipleAccountPublicClientApplication.RemoveAccountCallback() {

+> @Override

+> public void onRemoved() {

+> ...

+> /* Reload account asynchronously to get the up-to-date list. */

+> loadAccounts();

+> }

+>

+> @Override

+> public void onError(@NonNull MsalException exception) {

+> displayError(exception);

+> }

+> });

+> ```

+>

+> ### auth_config_multiple_account.json

+>

+> This is the configuration file for a MSAL app that uses multiple accounts.

+>

+> See [Understand the Android MSAL configuration file ](msal-configuration.md) for an explanation of the various fields.

+>

+> Unlike the [auth_config_single_account.json](#auth_config_single_accountjson) configuration file, this config file has `"account_mode" : "MULTIPLE"` instead of `"account_mode" : "SINGLE"` because this is a multiple account app.

+>

+> `"client_id"` is preconfigured to use an app object registration that Microsoft maintains.

+> `"redirect_uri"`is preconfigured to use the signing key provided with the code sample.

+>

+> ```json

+> {

+> "client_id" : "0984a7b6-bc13-4141-8b0d-8f767e136bb7",

+> "authorization_user_agent" : "DEFAULT",

+> "redirect_uri" : "msauth://com.azuresamples.msalandroidapp/1wIqXSqBj7w%2Bh11ZifsnqwgyKrY%3D",

+> "account_mode" : "MULTIPLE",

+> "broker_redirect_uri_registered": true,

+> "authorities" : [

+> {

+> "type": "AAD",

+> "audience": {

+> "type": "AzureADandPersonalMicrosoftAccount",

+> "tenant_id": "common"

+> }

+> }

+> ]

+> }

+> ```

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Move on to the Android tutorial in which you build an Android app that gets an access token from the Microsoft identity platform and uses it to call the Microsoft Graph API.

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial: Sign in users and call the Microsoft Graph from an Android application](tutorial-v2-android.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart:Protect an ASP.NET Core web API](web-api-quickstart.md?pivots=devlang-aspnet-core)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download an ASP.NET Core web API code sample and review the way it restricts resource access to authorized accounts only. The sample supports authorization of personal Microsoft accounts and accounts in any Azure Active Directory (Azure AD) organization.

+>

+>

+> ## Prerequisites

+>

+> - Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> - [Azure Active Directory tenant](quickstart-create-new-tenant.md)

+> - [.NET Core SDK 3.1+](https://dotnet.microsoft.com/)

+> - [Visual Studio 2019](https://visualstudio.microsoft.com/vs/) or [Visual Studio Code](https://code.visualstudio.com/)

+>

+> ## Step 1: Register the application

+>

+> First, register the web API in your Azure AD tenant and add a scope by following these steps:

+>

+> 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. For **Name**, enter a name for your application. For example, enter **AspNetCoreWebApi-Quickstart**. Users of your app will see this name, and you can change it later.

+> 1. Select **Register**.

+> 1. Under **Manage**, select **Expose an API** > **Add a scope**. For **Application ID URI**, accept the default by selecting **Save and continue**, and then enter the following details:

+> - **Scope name**: `access_as_user`

+> - **Who can consent?**: **Admins and users**

+> - **Admin consent display name**: `Access AspNetCoreWebApi-Quickstart`

+> - **Admin consent description**: `Allows the app to access AspNetCoreWebApi-Quickstart as the signed-in user.`

+> - **User consent display name**: `Access AspNetCoreWebApi-Quickstart`

+> - **User consent description**: `Allow the application to access AspNetCoreWebApi-Quickstart on your behalf.`

+> - **State**: **Enabled**

+> 1. Select **Add scope** to complete the scope addition.

+>

+> ## Step 2: Download the ASP.NET Core project

+>

+> [Download the ASP.NET Core solution](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/archive/aspnetcore3-1.zip) from GitHub.

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+>

+> ## Step 3: Configure the ASP.NET Core project

+>

+> In this step, configure the sample code to work with the app registration that you created earlier.

+>

+> 1. Extract the .zip archive into a folder near the root of your drive. For example, extract into *C:\Azure-Samples*.

+>

+> We recommend extracting the archive into a directory near the root of your drive to avoid errors caused by path length limitations on Windows.

+>

+> 1. Open the solution in the *webapi* folder in your code editor.

+> 1. Open the *appsettings.json* file and modify the following code:

+>

+> ```json

+> "ClientId": "Enter_the_Application_Id_here",

+> "TenantId": "Enter_the_Tenant_Info_Here"

+> ```

+>

+> - Replace `Enter_the_Application_Id_here` with the application (client) ID of the application that you registered in the Azure portal. You can find the application (client) ID on the app's **Overview** page.

+> - Replace `Enter_the_Tenant_Info_Here` with one of the following:

+> - If your application supports **Accounts in this organizational directory only**, replace this value with the directory (tenant) ID (a GUID) or tenant name (for example, `contoso.onmicrosoft.com`). You can find the directory (tenant) ID on the app's **Overview** page.

+> - If your application supports **Accounts in any organizational directory**, replace this value with `organizations`.

+> - If your application supports **All Microsoft account users**, leave this value as `common`.

+>

+> For this quickstart, don't change any other values in the *appsettings.json* file.

+>

+> ## How the sample works

+>

+> The web API receives a token from a client application, and the code in the web API validates the token. This scenario is explained in more detail in [Scenario: Protected web API](scenario-protected-web-api-overview.md).

+>

+> ### Startup class

+>

+> The *Microsoft.AspNetCore.Authentication* middleware uses a `Startup` class that's executed when the hosting process starts. In its `ConfigureServices` method, the `AddMicrosoftIdentityWebApi` extension method provided by *Microsoft.Identity.Web* is called.

+>

+> ```csharp

+> public void ConfigureServices(IServiceCollection services)

+> {

+> services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)

+> .AddMicrosoftIdentityWebApi(Configuration, "AzureAd");

+> }

+> ```

+>

+> The `AddAuthentication()` method configures the service to add JwtBearer-based authentication.

+>

+> The line that contains `.AddMicrosoftIdentityWebApi` adds the Microsoft identity platform authorization to your web API. It's then configured to validate access tokens issued by the Microsoft identity platform based on the information in the `AzureAD` section of the *appsettings.json* configuration file:

+>

+> | *appsettings.json* key | Description |

+> ||-|

+> | `ClientId` | Application (client) ID of the application registered in the Azure portal. |

+> | `Instance` | Security token service (STS) endpoint for the user to authenticate. This value is typically `https://login.microsoftonline.com/`, indicating the Azure public cloud. |

+> | `TenantId` | Name of your tenant or its tenant ID (a GUID), or `common` to sign in users with work or school accounts or Microsoft personal accounts. |

+>

+> The `Configure()` method contains two important methods, `app.UseAuthentication()` and `app.UseAuthorization()`, that enable their named functionality:

+>

+> ```csharp

+> // The runtime calls this method. Use this method to configure the HTTP request pipeline.

+> public void Configure(IApplicationBuilder app, IHostingEnvironment env)

+> {

+> // more code

+> app.UseAuthentication();

+> app.UseAuthorization();

+> // more code

+> }

+> ```

+>

+> ### Protecting a controller, a controller's method, or a Razor page

+>

+> You can protect a controller or controller methods by using the `[Authorize]` attribute. This attribute restricts access to the controller or methods by allowing only authenticated users. An authentication challenge can be started to access the controller if the user isn't authenticated.

+>

+> ```csharp

+> namespace webapi.Controllers

+> {

+> [Authorize]

+> [ApiController]

+> [Route("[controller]")]

+> public class WeatherForecastController : ControllerBase

+> ```

+>

+> ### Validation of scope in the controller

+>

+> The code in the API verifies that the required scopes are in the token by using `HttpContext.VerifyUserHasAnyAcceptedScope> (scopeRequiredByApi);`:

+>

+> ```csharp

+> namespace webapi.Controllers

+> {

+> [Authorize]

+> [ApiController]

+> [Route("[controller]")]

+> public class WeatherForecastController : ControllerBase

+> {

+> // The web API will only accept tokens 1) for users, and 2) having the "access_as_user" scope for this API

+> static readonly string[] scopeRequiredByApi = new string[] { "access_as_user" };

+>

+> [HttpGet]

+> public IEnumerable<WeatherForecast> Get()

+> {

+> HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi);

+>

+> // some code here

+> }

+> }

+> }

+> ```

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> The GitHub repository that contains this ASP.NET Core web API code sample includes instructions and more code samples that show you how to:

+>

+> - Add authentication to a new ASP.NET Core web API.

+> - Call the web API from a desktop application.

+> - Call downstream APIs like Microsoft Graph and other Microsoft APIs.

+>

+> > [!div class="nextstepaction"]

+> > [ASP.NET Core web API tutorials on GitHub](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: ASP.NET Core web app that signs in users and calls a web API](web-app-quickstart.md?pivots=devlang-aspnet-core)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how an ASP.NET Core web app can sign in users from any Azure Active Directory (Azure AD) organization and calls Microsoft Graph.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> ## Step 1: Configure your application in the Azure portal

+>

+> For the code sample in this quickstart to work, add a **Redirect URI** of `https://localhost:44321/signin-oidc` and > **Front-channel logout URL** of `https://localhost:44321/signout-oidc` in the app registration.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> ## Step 2: Download the ASP.NET Core project

+>

+> Run the project.

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/archive/aspnetcore3-1-callsgraph.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+>

+> ## Step 3: Your app is configured and ready to run

+>

+> We have configured your project with values of your app's properties and it's ready to run.

+>

+> > [!NOTE]

+> > `Enter_the_Supported_Account_Info_Here`

+>

+> ## About the code

+>

+> This section gives an overview of the code required to sign in users and call the Microsoft Graph API on their behalf. This overview can be useful to understand how the code works, main arguments, and also if you want to add sign-in to an existing ASP.NET Core application and call Microsoft Graph. It uses [Microsoft.Identity.Web](microsoft-identity-web.md), which is a wrapper around [MSAL.NET](msal-overview.md).

+>

+> ### How the sample works

+>

+> 

+>

+> ### Startup class

+>

+> The *Microsoft.AspNetCore.Authentication* middleware uses a `Startup` class that's executed when the hosting process initializes:

+>

+> ```csharp

+>

+> public void ConfigureServices(IServiceCollection services)

+> {

+> // Get the scopes from the configuration (appsettings.json)

+> var initialScopes = Configuration.GetValue<string>("DownstreamApi:Scopes")?.Split(' ');

+>

+> // Add sign-in with Microsoft

+> services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)

+> .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"))

+>

+> // Add the possibility of acquiring a token to call a protected web API

+> .EnableTokenAcquisitionToCallDownstreamApi(initialScopes)

+>

+> // Enables controllers and pages to get GraphServiceClient by dependency injection

+> // And use an in memory token cache

+> .AddMicrosoftGraph(Configuration.GetSection("DownstreamApi"))

+> .AddInMemoryTokenCaches();

+>

+> services.AddControllersWithViews(options =>

+> {

+> var policy = new AuthorizationPolicyBuilder()

+> .RequireAuthenticatedUser()

+> .Build();

+> options.Filters.Add(new AuthorizeFilter(policy));

+> });

+>

+> // Enables a UI and controller for sign in and sign out.

+> services.AddRazorPages()

+> .AddMicrosoftIdentityUI();

+> }

+> ```

+>

+> The `AddAuthentication()` method configures the service to add cookie-based authentication, which is used in browser scenarios and to set the challenge to OpenID Connect.

+>

+> The line containing `.AddMicrosoftIdentityWebApp` adds the Microsoft identity platform authentication to your application. This is provided by [Microsoft.Identity.Web](microsoft-identity-web.md). It's then configured to sign in using the Microsoft identity platform based on the information in the `AzureAD` section of the *appsettings.json* configuration file:

+>

+> | *appsettings.json* key | Description > |

+> ||-|

+> | `ClientId` | **Application (client) ID** of the application registered in the Azure portal. |

+> | `Instance` | Security token service (STS) endpoint for the user to authenticate. This value is typically `https://login.microsoftonline.com/`, indicating the Azure public cloud. |

+> | `TenantId` | Name of your tenant or its tenant ID (a GUID), or *common* to sign in users with work or school accounts or Microsoft personal accounts. |

+>

+> The `EnableTokenAcquisitionToCallDownstreamApi` method enables your application to acquire a token to call protected web APIs. `AddMicrosoftGraph` enables your controllers or Razor pages to benefit directly the `GraphServiceClient` (by dependency injection) and the `AddInMemoryTokenCaches` methods enables your app to benefit from a token cache.

+>

+> The `Configure()` method contains two important methods, `app.UseAuthentication()` and `app.UseAuthorization()`, that enable their named functionality. Also in the `Configure()` method, you must register Microsoft Identity Web's routes with at least one call to `endpoints.MapControllerRoute()` or a call to `endpoints.MapControllers()`.

+>

+> ```csharp

+> app.UseAuthentication();

+> app.UseAuthorization();

+>

+> app.UseEndpoints(endpoints =>

+> {

+>

+> endpoints.MapControllerRoute(

+> name: "default",

+> pattern: "{controller=Home}/{action=Index}/{id?}");

+> endpoints.MapRazorPages();

+> });

+>

+> // endpoints.MapControllers(); // REQUIRED if MapControllerRoute() isn't called.

+> ```

+>

+> ### Protect a controller or a controller's method

+>

+> You can protect a controller or its methods by applying the `[Authorize]` attribute to the controller's class or one or more of its methods. This `[Authorize]` attribute restricts access by allowing only authenticated users. If the user isn't already authenticated, an authentication challenge can be started to access the controller. In this quickstart, the scopes are read from the configuration file:

+>

+> ```csharp

+> [AuthorizeForScopes(ScopeKeySection = "DownstreamApi:Scopes")]

+> public async Task<IActionResult> Index()

+> {

+> var user = await _graphServiceClient.Me.Request().GetAsync();

+> ViewData["ApiResult"] = user.DisplayName;

+>

+> return View();

+> }

+> ```

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> The GitHub repo that contains the ASP.NET Core code sample referenced in this quickstart includes instructions and more code samples that show you how to:

+>

+> - Add authentication to a new ASP.NET Core Web application

+> - Call Microsoft Graph, other Microsoft APIs, or your own web APIs

+> - Add authorization

+> - Sign in users in national clouds or with social identities

+>

+> > [!div class="nextstepaction"]

+> > [ASP.NET Core web app tutorials on GitHub](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+> > [Quickstart: ASP.NET Core web app with user sign-in](web-app-quickstart.md?pivots=devlang-aspnet-core)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how an ASP.NET Core web app can sign in users from any Azure Active Directory (Azure AD) organization.

+>

+> #### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work:

+> - For **Redirect URI**, enter **https://localhost:44321/** and **https://localhost:44321/signin-oidc**.

+> - For **Front-channel logout URL**, enter **https://localhost:44321/signout-oidc**.

+>

+> The authorization endpoint will issue request ID tokens.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the ASP.NET Core project

+>

+> Run the project.

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/archive/aspnetcore3-1.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+>

+> #### Step 3: Your app is configured and ready to run

+> We've configured your project with values of your app's properties, and it's ready to run.

+>

+> > [!NOTE]

+> > `Enter_the_Supported_Account_Info_Here`

+>

+> ## More information

+>

+> This section gives an overview of the code required to sign in users. This overview can be useful to understand how the code works, what the main arguments are, and how to add sign-in to an existing ASP.NET Core application.

+>

+> > [!div class="sxs-lookup" renderon="portal"]

+> > ### How the sample works

+> >

+> > 

+>

+> ### Startup class

+>

+> The *Microsoft.AspNetCore.Authentication* middleware uses a `Startup` class that's run when the hosting process starts:

+>

+> ```csharp

+> public void ConfigureServices(IServiceCollection services)

+> {

+> services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)

+> .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));

+>

+> services.AddControllersWithViews(options =>

+> {

+> var policy = new AuthorizationPolicyBuilder()

+> .RequireAuthenticatedUser()

+> .Build();

+> options.Filters.Add(new AuthorizeFilter(policy));

+> });

+> services.AddRazorPages()

+> .AddMicrosoftIdentityUI();

+> }

+> ```

+>

+> The `AddAuthentication()` method configures the service to add cookie-based authentication. This authentication is used in browser scenarios and to set the challenge to OpenID Connect.

+>

+> The line that contains `.AddMicrosoftIdentityWebApp` adds Microsoft identity platform authentication to your application. The application is then configured to sign in users based on the following information in the `AzureAD` section of the *appsettings.json* configuration file:

+>

+> | *appsettings.json* key | Description |

+> ||-|

+> | `ClientId` | Application (client) ID of the application registered in the Azure portal. |

+> | `Instance` | Security token service (STS) endpoint for the user to authenticate. This value is typically `https://login.microsoftonline.com/`, indicating the Azure public cloud. |

+> | `TenantId` | Name of your tenant or the tenant ID (a GUID), or `common` to sign in users with work or school accounts or Microsoft personal accounts. |

+>

+> The `Configure()` method contains two important methods, `app.UseAuthentication()` and `app.UseAuthorization()`, that enable their named functionality. Also in the `Configure()` method, you must register Microsoft Identity Web routes with at least one call to `endpoints.MapControllerRoute()` or a call to `endpoints.MapControllers()`:

+>

+> ```csharp

+> app.UseAuthentication();

+> app.UseAuthorization();

+>

+> app.UseEndpoints(endpoints =>

+> {

+> endpoints.MapControllerRoute(

+> name: "default",

+> pattern: "{controller=Home}/{action=Index}/{id?}");

+> endpoints.MapRazorPages();

+> });

+> ```

+>

+> ### Attribute for protecting a controller or methods

+>

+> You can protect a controller or controller methods by using the `[Authorize]` attribute. This attribute restricts access to the controller or methods by allowing only authenticated users. An authentication challenge can then be started to access the controller if the user isn't authenticated.

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> The GitHub repo that contains this ASP.NET Core tutorial includes instructions and more code samples that show you how to:

+>

+> - Add authentication to a new ASP.NET Core web application.

+> - Call Microsoft Graph, other Microsoft APIs, or your own web APIs.

+> - Add authorization.

+> - Sign in users in national clouds or with social identities.

+>

+> > [!div class="nextstepaction"]

+> > [ASP.NET Core web app tutorials on GitHub](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: ASP.NET web app that signs in users](web-app-quickstart.md?pivots=devlang-aspnet)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates an ASP.NET web application that can sign in users with Azure Active Directory (Azure AD) accounts.

+>

+> #### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work, enter **https://localhost:44368/** for **Redirect URI**.

+>

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with this attribute.

+>

+> #### Step 2: Download the project

+>

+> Run the project by using Visual Studio 2019.

+> > [!div class="sxs-lookup nextstepaction"]

+> > [Download the code sample](https://github.com/AzureADQuickStarts/AppModelv2-WebApp-OpenIDConnect-DotNet/archive/master.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+>

+> #### Step 3: Your app is configured and ready to run

+> We've configured your project with values of your app's properties.

+>

+> 1. Extract the .zip file to a local folder that's close to the root folder. For example, extract to *C:\Azure-Samples*.

+>

+> We recommend extracting the archive into a directory near the root of your drive to avoid errors caused by path length limitations on Windows.

+> 2. Open the solution in Visual Studio (*AppModelv2-WebApp-OpenIDConnect-DotNet.sln*).

+> 3. Depending on the version of Visual Studio, you might need to right-click the project > **AppModelv2-WebApp-OpenIDConnect-DotNet** and then select **Restore NuGet packages**.

+> 4. Open the Package Manager Console by selecting **View** > **Other Windows** > **Package Manager Console**. Then run `Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r`.

+>

+> > [!NOTE]

+> > `Enter_the_Supported_Account_Info_Here`

+>

+> ## More information

+>

+> This section gives an overview of the code required to sign in users. This overview can be useful to understand how the code works, what the main arguments are, and how to add sign-in to an existing ASP.NET application.

+>

+>

+> ### How the sample works

+>

+> 

+>

+> ### OWIN middleware NuGet packages

+>

+> You can set up the authentication pipeline with cookie-based authentication by using OpenID Connect in ASP.NET with OWIN middleware packages. You can install these packages by running the following commands in Package Manager Console within Visual Studio:

+>

+> ```powershell

+> Install-Package Microsoft.Owin.Security.OpenIdConnect

+> Install-Package Microsoft.Owin.Security.Cookies

+> Install-Package Microsoft.Owin.Host.SystemWeb

+> ```

+>

+> ### OWIN startup class

+>

+> The OWIN middleware uses a *startup class* that runs when the hosting process starts. In this quickstart, the *startup.cs* file is in the root folder. The following code shows the parameters that this quickstart uses:

+>

+> ```csharp

+> public void Configuration(IAppBuilder app)

+> {

+> app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

+>

+> app.UseCookieAuthentication(new CookieAuthenticationOptions());

+> app.UseOpenIdConnectAuthentication(

+> new OpenIdConnectAuthenticationOptions

+> {

+> // Sets the client ID, authority, and redirect URI as obtained from Web.config

+> ClientId = clientId,

+> Authority = authority,

+> RedirectUri = redirectUri,

+> // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it's using the home page

+> PostLogoutRedirectUri = redirectUri,

+> Scope = OpenIdConnectScope.OpenIdProfile,

+> // ResponseType is set to request the code id_token, which contains basic information about the signed-in user

+> ResponseType = OpenIdConnectResponseType.CodeIdToken,

+> // ValidateIssuer set to false to allow personal and work accounts from any organization to sign in to your application

+> // To only allow users from a single organization, set ValidateIssuer to true and the 'tenant' setting in Web.> config to the tenant name

+> // To allow users from only a list of specific organizations, set ValidateIssuer to true and use the ValidIssuers parameter

+> TokenValidationParameters = new TokenValidationParameters()

+> {

+> ValidateIssuer = false // Simplification (see note below)

+> },

+> // OpenIdConnectAuthenticationNotifications configures OWIN to send notification of failed authentications to > the OnAuthenticationFailed method

+> Notifications = new OpenIdConnectAuthenticationNotifications

+> {

+> AuthenticationFailed = OnAuthenticationFailed

+> }

+> }

+> );

+> }

+> ```

+>

+> > |Where | Description |

+> > |||

+> > | `ClientId` | The application ID from the application registered in the Azure portal. |

+> > | `Authority` | The security token service (STS) endpoint for the user to authenticate. It's usually `https://login.microsoftonline.com/{tenant}/v2.0` for the public cloud. In that URL, *{tenant}* is the name of your tenant, your tenant ID, or `common` for a reference to the common endpoint. (The common endpoint is used for multitenant applications.) |

+> > | `RedirectUri` | The URL where users are sent after authentication against the Microsoft identity platform. |

+> > | `PostLogoutRedirectUri` | The URL where users are sent after signing off. |

+> > | `Scope` | The list of scopes being requested, separated by spaces. |

+> > | `ResponseType` | The request that the response from authentication contains an authorization code and an ID token. |

+> > | `TokenValidationParameters` | A list of parameters for token validation. In this case, `ValidateIssuer` is set to `false` to indicate that it can accept sign-ins from any personal, work, or school account type. |

+> > | `Notifications` | A list of delegates that can be run on `OpenIdConnect` messages. |

+>

+>

+> > [!NOTE]

+> > Setting `ValidateIssuer = false` is a simplification for this quickstart. In real applications, validate the issuer. See the samples to understand how to do that.

+>

+> ### Authentication challenge

+>

+> You can force a user to sign in by requesting an authentication challenge in your controller:

+>

+> ```csharp

+> public void SignIn()

+> {

+> if (!Request.IsAuthenticated)

+> {

+> HttpContext.GetOwinContext().Authentication.Challenge(

+> new AuthenticationProperties{ RedirectUri = "/" },

+> OpenIdConnectAuthenticationDefaults.AuthenticationType);

+> }

+> }

+> ```

+>

+> > [!TIP]

+> > Requesting an authentication challenge by using this method is optional. You'd normally use it when you want a view to be accessible from both authenticated and unauthenticated users. Alternatively, you can protect controllers by using the method described in the next section.

+>

+> ### Attribute for protecting a controller or a controller actions

+>

+> You can protect a controller or controller actions by using the `[Authorize]` attribute. This attribute restricts access to the controller or actions by allowing only authenticated users to access the actions in the controller. An authentication challenge will then happen automatically when an unauthenticated user tries to access one of the actions or controllers decorated by the `[Authorize]` attribute.

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> For a complete step-by-step guide on building applications and new features, including a full explanation of this quickstart, try out the ASP.NET tutorial.

+>

+> > [!div class="nextstepaction"]

+> > [Add sign-in to an ASP.NET web app](tutorial-v2-asp-webapp.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Call a protected ASP.NET web API](web-api-quickstart.md?pivots=devlang-aspnet)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how to protect an ASP.NET web API by restricting access to its resources to authorized accounts only. The sample supports authorization of personal Microsoft accounts and accounts in any Azure Active Directory (Azure AD) organization.

+>

+> The article also uses a Windows Presentation Foundation (WPF) app to demonstrate how you can request an access token to access a web API.

+>

+> ## Prerequisites

+>

+> * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> * Visual Studio 2017 or 2019. Download [Visual Studio for free](https://www.visualstudio.com/downloads/).

+>

+> ## Clone or download the sample

+>

+> You can obtain the sample in either of two ways:

+>

+> * Clone it from your shell or command line:

+>

+> ```console

+> git clone https://github.com/AzureADQuickStarts/AppModelv2-NativeClient-DotNet.git

+> ```

+>

+> * [Download it as a ZIP file](https://github.com/AzureADQuickStarts/AppModelv2-NativeClient-DotNet/archive/complete.zip).

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+> ## Register the web API (TodoListService)

+>

+> Register your web API in **App registrations** in the Azure portal.

+>

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

+> 1. If you have access to multiple tenants, use the **Directory + subscription** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to select the tenant in which you want to register an application.

+> 1. Find and select **Azure Active Directory**.

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

+> 1. Enter a **Name** for your application, for example `AppModelv2-NativeClient-DotNet-TodoListService`. Users of your app might see this name, and you can change it later.

+> 1. For **Supported account types**, select **Accounts in any organizational directory**.

+> 1. Select **Register** to create the application.

+> 1. On the app **Overview** page, look for the **Application (client) ID** value, and then record it for later use. You'll need it to configure the Visual Studio configuration file for this project (that is, `ClientId` in the *TodoListService\Web.config* file).

+> 1. Under **Manage**, select **Expose an API** > **Add a scope**. Accept the proposed Application ID URI (`api://{clientId}> `) by selecting **Save and continue**, and then enter the following information:

+>

+> 1. For **Scope name**, enter `access_as_user`.

+> 1. For **Who can consent**, ensure that the **Admins and users** option is selected.

+> 1. In the **Admin consent display name** box, enter `Access TodoListService as a user`.

+> 1. In the **Admin consent description** box, enter `Accesses the TodoListService web API as a user`.

+> 1. In the **User consent display name** box, enter `Access TodoListService as a user`.

+> 1. In the **User consent description** box, enter `Accesses the TodoListService web API as a user`.

+> 1. For **State**, keep **Enabled**.

+> 1. Select **Add scope**.

+>

+> ### Configure the service project

+>

+> Configure the service project to match the registered web API.

+>

+> 1. Open the solution in Visual Studio, and then open the *Web.config* file under the root of the TodoListService project.

+>

+> 1. Replace the value of the `ida:ClientId` parameter with the Client ID (Application ID) value from the application you registered in the **App registrations** portal.

+>

+> ### Add the new scope to the app.config file

+>

+> To add the new scope to the TodoListClient *app.config* file, follow these steps:

+>

+> 1. In the TodoListClient project root folder, open the *app.config* file.

+>

+> 1. Paste the Application ID from the application that you registered for your TodoListService project in the `TodoListServiceScope` parameter, replacing the `{Enter the Application ID of your TodoListService from the app registration portal}` string.

+>

+> > [!NOTE]

+> > Make sure that the Application ID uses the following format: `api://{TodoListService-Application-ID}/access_as_user` (where `{TodoListService-Application-ID}` is the GUID representing the Application ID for your TodoListService app).

+>

+> ## Register the web app (TodoListClient)

+>

+> Register your TodoListClient app in **App registrations** in the Azure portal, and then configure the code in the TodoListClient project. If the client and server are considered the same application, you can reuse the application that's registered in step 2. Use the same application if you want users to sign in with a personal Microsoft account.

+>

+> ### Register the app

+>

+> To register the TodoListClient app, follow these steps:

+>

+> 1. Go to the Microsoft identity platform for developers [App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) portal.

+> 1. Select **New registration**.

+> 1. When the **Register an application page** opens, enter your application's registration information:

+>

+> 1. In the **Name** section, enter a meaningful application name that will be displayed to users of the app (for example, **NativeClient-DotNet-TodoListClient**).

+> 1. For **Supported account types**, select **Accounts in any organizational directory**.

+> 1. Select **Register** to create the application.

+>

+> > [!NOTE]

+> > In the TodoListClient project *app.config* file, the default value of `ida:Tenant` is set to `common`. The possible values are:

+> >

+> > - `common`: You can sign in by using a work or school account or a personal Microsoft account (because you selected **Accounts in any organizational directory** in a previous step).

+> > - `organizations`: You can sign in by using a work or school account.

+> > - `consumers`: You can sign in only by using a Microsoft personal account.

+>

+> 1. On the app **Overview** page, select **Authentication**, and then complete these steps to add a platform:

+>

+> 1. Under **Platform configurations**, select the **Add a platform** button.

+> 1. For **Mobile and desktop applications**, select **Mobile and desktop applications**.

+> 1. For **Redirect URIs**, select the `https://login.microsoftonline.com/common/oauth2/nativeclient` check box.

+> 1. Select **Configure**.

+>

+> 1. Select **API permissions**, and then complete these steps to add permissions:

+>

+> 1. Select the **Add a permission** button.

+> 1. Select the **My APIs** tab.

+> 1. In the list of APIs, select **AppModelv2-NativeClient-DotNet-TodoListService API** or the name you entered for the web API.

+> 1. Select the **access_as_user** permission check box if it's not already selected. Use the Search box if necessary.

+> 1. Select the **Add permissions** button.

+>

+> ### Configure your project

+>

+> Configure your TodoListClient project by adding the Application ID to the *app.config* file.

+>

+> 1. In the **App registrations** portal, on the **Overview** page, copy the value of the **Application (client) ID**.

+>

+> 1. From the TodoListClient project root folder, open the *app.config* file, and then paste the Application ID value in the `ida:ClientId` parameter.

+>

+> ## Run your projects

+>

+> Start both projects. If you are using Visual Studio:

+>

+> 1. Right click on the Visual Studio solution and select **Properties**

+>

+> 1. In the **Common Properties** select **Startup Project** and then **Multiple startup projects**.

+>

+> 1. For both projects choose **Start** as the action

+>

+> 1. Ensure the TodoListService service starts first by moving it to the fist position in the list, using the up arrow.

+>

+> Sign in to run your TodoListClient project.

+>

+> 1. Press F5 to start the projects. The service page opens, as well as the desktop application.

+>

+> 1. In the TodoListClient, at the upper right, select **Sign in**, and then sign in with the same credentials you used to register your application, or sign in as a user in the same directory.

+>

+> If you're signing in for the first time, you might be prompted to consent to the TodoListService web API.

+>

+> To help you access the TodoListService web API and manipulate the *To-Do* list, the sign-in also requests an access token to the *access_as_user* scope.

+>

+> ## Pre-authorize your client application

+>

+> You can allow users from other directories to access your web API by pre-authorizing the client application to access your web API. You do this by adding the Application ID from the client app to the list of pre-authorized applications for your web API. By adding a pre-authorized client, you're allowing users to access your web API without having to provide consent.

+>

+> 1. In the **App registrations** portal, open the properties of your TodoListService app.

+> 1. In the **Expose an API** section, under **Authorized client applications**, select **Add a client application**.

+> 1. In the **Client ID** box, paste the Application ID of the TodoListClient app.

+> 1. In the **Authorized scopes** section, select the scope for the `api://<Application ID>/access_as_user` web API.

+> 1. Select **Add application**.

+>

+> ### Run your project

+>

+> 1. Press <kbd>F5</kbd> to run your project. Your TodoListClient app opens.

+> 1. At the upper right, select **Sign in**, and then sign in by using a personal Microsoft account, such as a *live.com* or *hotmail.com* account, or a work or school account.

+>

+> ## Optional: Limit sign-in access to certain users

+>

+> By default, any personal accounts, such as *outlook.com* or *live.com* accounts, or work or school accounts from organizations that are integrated with Azure AD can request tokens and access your web API.

+>

+> To specify who can sign in to your application, use one of the following options:

+>

+> ### Option 1: Limit access to a single organization (single tenant)

+>

+> You can limit sign-in access to your application to user accounts that are in a single Azure AD tenant, including guest accounts of that tenant. This scenario is common for line-of-business applications.

+>

+> 1. Open the *App_Start\Startup.Auth* file, and then change the value of the metadata endpoint that's passed into the `OpenIdConnectSecurityTokenProvider` to `https://login.microsoftonline.com/{Tenant ID}/v2.0/.well-known/openid-configuration`. You can also use the tenant name, such as `contoso.onmicrosoft.com`.

+> 1. In the same file, set the `ValidIssuer` property on the `TokenValidationParameters` to `https://sts.windows.net/{Tenant ID}/`, and set the `ValidateIssuer` argument to `true`.

+>

+> ### Option 2: Use a custom method to validate issuers

+>

+> You can implement a custom method to validate issuers by using the `IssuerValidator` parameter. For more information about this parameter, see [TokenValidationParameters class](/dotnet/api/microsoft.identitymodel.tokens.tokenvalidationparameters).

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Learn more about the protected web API scenario that the Microsoft identity platform supports.

+> > [!div class="nextstepaction"]

+> > [Protected web API scenario](scenario-protected-web-api-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: iOS or macOS app that signs in users and calls a web API](mobile-app-quickstart.md?pivots=devlang-ios)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a native iOS or macOS application can sign in users and get an access token to call the Microsoft Graph API.

+>

+> The quickstart applies to both iOS and macOS apps. Some steps are needed only for iOS apps and will be indicated as such.

+>

+> ## Prerequisites

+>

+> * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> * XCode 10+

+> * iOS 10+

+> * macOS 10.12+

+>

+> ## How the sample works

+>

+> 

+>

+> #### Step 1: Configure your application

+> For the code sample for this quickstart to work, add a **Redirect URI** compatible with the Auth broker.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes

+>

+> #### Step 2: Download the sample project

+> > [!div class="nextstepaction"]

+> > [Download the code sample for iOS]()

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample for macOS]()

+>

+> #### Step 3: Install dependencies

+>

+> 1. Extract the zip file.

+> 2. In a terminal window, navigate to the folder with the downloaded code sample and run `pod install` to install the latest MSAL library.

+>

+> #### Step 4: Your app is configured and ready to run

+> We have configured your project with values of your app's properties and it's ready to run.

+> > [!NOTE]

+> > `Enter_the_Supported_Account_Info_Here`

+>

+> 1. If you're building an app for [Azure AD national clouds](/graph/deployments#app-registration-and-token-service-root-endpoints), replace the line starting with 'let kGraphEndpoint' and 'let kAuthority' with correct endpoints. For global access, use default values:

+>

+> ```swift

+> let kGraphEndpoint = "https://graph.microsoft.com/"

+> let kAuthority = "https://login.microsoftonline.com/common"

+> ```

+>

+> 1. Other endpoints are documented [here](/graph/deployments#app-registration-and-token-service-root-endpoints). For example, to run the quickstart with Azure AD Germany, use following:

+>

+> ```swift

+> let kGraphEndpoint = "https://graph.microsoft.de/"

+> let kAuthority = "https://login.microsoftonline.de/common"

+> ```

+>

+> 3. Open the project settings. In the **Identity** section, enter the **Bundle Identifier** that you entered into the portal.

+> 4. Right-click **Info.plist** and select **Open As** > **Source Code**.

+> 5. Under the dict root node, replace `Enter_the_bundle_Id_Here` with the ***Bundle Id*** that you used in the portal. Notice the `msauth.` prefix in the string.

+>

+> ```xml

+> <key>CFBundleURLTypes</key>

+> <array>

+> <dict>

+> <key>CFBundleURLSchemes</key>

+> <array>

+> <string>msauth.Enter_the_Bundle_Id_Here</string>

+> </array>

+> </dict>

+> </array>

+> ```

+>

+> 6. Build and run the app!

+>

+> ## More Information

+>

+> Read these sections to learn more about this quickstart.

+>

+> ### Get MSAL

+>

+> MSAL ([MSAL.framework](https://github.com/AzureAD/microsoft-authentication-library-for-objc)) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. You can add MSAL to your application using the following process:

+>

+> ```

+> $ vi Podfile

+> ```

+>

+> Add the following to this podfile (with your project's target):

+>

+> ```

+> use_frameworks!

+>

+> target 'MSALiOS' do

+> pod 'MSAL'

+> end

+> ```

+>

+> Run CocoaPods installation command:

+>

+> `pod install`

+>

+> ### Initialize MSAL

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```swift

+> import MSAL

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```swift

+> let authority = try MSALAADAuthority(url: URL(string: kAuthority)!)

+>

+> let msalConfiguration = MSALPublicClientApplicationConfig(clientId: kClientID, redirectUri: nil, authority: authority)

+> self.applicationContext = try MSALPublicClientApplication(configuration: msalConfiguration)

+> ```

+>

+> > |Where: | Description |

+> > |||

+> > | `clientId` | The Application ID from the application registered in *portal.azure.com* |

+> > | `authority` | The Microsoft identity platform. In most of cases this will be `https://login.microsoftonline.com/common` > |

+> > | `redirectUri` | The redirect URI of the application. You can pass 'nil' to use the default value, or your custom redirect URI. |

+>

+> ### For iOS only, additional app requirements

+>

+> Your app must also have the following in your `AppDelegate`. This lets MSAL SDK handle token response from the Auth broker app when you do authentication.

+>

+> ```swift

+> func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {

+>

+> return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)

+> }

+> ```

+>

+> > [!NOTE]

+> > On iOS 13+, if you adopt `UISceneDelegate` instead of `UIApplicationDelegate`, place this code into the `scene:openURLContexts:` callback instead (See [Apple's documentation](https://developer.apple.com/documentation/uikit/uiscenedelegate/3238059-scene?language=objc)).

+> > If you support both UISceneDelegate and UIApplicationDelegate for compatibility with older iOS, MSAL callback needs to be placed into both places.

+>

+> ```swift

+> func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {

+>

+> guard let urlContext = URLContexts.first else {

+> return

+> }

+>

+> let url = urlContext.url

+> let sourceApp = urlContext.options.sourceApplication

+>

+> MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: sourceApp)

+> }

+> ```

+>

+> Finally, your app must have an `LSApplicationQueriesSchemes` entry in your ***Info.plist*** alongside the `CFBundleURLTypes`. The sample comes with this included.

+>

+> ```xml

+> <key>LSApplicationQueriesSchemes</key>

+> <array>

+> <string>msauthv2</string>

+> <string>msauthv3</string>

+> </array>

+> ```

+>

+> ### Sign in users & request tokens

+>

+> MSAL has two methods used to acquire tokens: `acquireToken` and `acquireTokenSilent`.

+>

+> #### acquireToken: Get a token interactively

+>

+> Some situations require users to interact with Microsoft identity platform. In these cases, the end user may be required to select their account, enter their credentials, or consent to your app's permissions. For example,

+>

+> * The first time users sign in to the application

+> * If a user resets their password, they'll need to enter their credentials

+> * When your application is requesting access to a resource for the first time

+> * When MFA or other Conditional Access policies are required

+>

+> ```swift

+> let parameters = MSALInteractiveTokenParameters(scopes: kScopes, webviewParameters: self.webViewParamaters!)

+> self.applicationContext!.acquireToken(with: parameters) { (result, error) in /* Add your handling logic */}

+> ```

+>

+> > |Where:| Description |

+> > |||

+> > | `scopes` | Contains the scopes being requested (that is, `[ "user.read" ]` for Microsoft Graph or `[ "<Application ID URL>/scope" ]` for custom web APIs (`api://<Application ID>/access_as_user`) |

+>

+> #### acquireTokenSilent: Get an access token silently

+>

+> Apps shouldn't require their users to sign in every time they request a token. If the user has already signed in, this method allows apps to request tokens silently.

+>

+> ```swift

+> self.applicationContext!.getCurrentAccount(with: nil) { (currentAccount, previousAccount, error) in

+>

+> guard let account = currentAccount else {

+> return

+> }

+>

+> let silentParams = MSALSilentTokenParameters(scopes: self.kScopes, account: account)

+> self.applicationContext!.acquireTokenSilent(with: silentParams) { (result, error) in /* Add your handling logic */}

+> }

+> ```

+>

+> > |Where: | Description |

+> > |||

+> > | `scopes` | Contains the scopes being requested (that is, `[ "user.read" ]` for Microsoft Graph or `[ "<Application ID URL>/scope" ]` for custom web APIs (`api://<Application ID>/access_as_user`) |

+> > | `account` | The account a token is being requested for. This quickstart is about a single account application. If you want to build a multi-account app you'll need to define logic to identify which account to use for token requests using `accountsFromDeviceForParameters:completionBlock:` and passing correct `accountIdentifier` |

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Move on to the step-by-step tutorial in which you build an iOS or macOS app that gets an access token from the Microsoft identity platform and uses it to call the Microsoft Graph API.

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial: Sign in users and call Microsoft Graph from an iOS or macOS app](tutorial-v2-ios.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Java daemon that calls a protected API](console-app-quickstart.md?pivots=devlang-java)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Java application can get an access token using the app's identity to call the Microsoft Graph API and display a [list of users](/graph/api/user-list) in the directory. The code sample demonstrates how an unattended job or Windows service can run with an application identity, instead of a user's identity.

+>

+> ## Prerequisites

+>

+> To run this sample, you need:

+>

+> - [Java Development Kit (JDK)](https://openjdk.java.net/) 8 or greater

+> - [Maven](https://maven.apache.org/)

+>

+> > [!div class="sxs-lookup"]

+> ### Download and configure the quickstart app

+>

+> #### Step 1: Configure the application in Azure portal

+> For the code sample for this quickstart to work, you need to create a client secret, and add Graph API's **User.Read.All** application permission.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the Java project

+>

+> > [!div class="sxs-lookup nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-java-daemon/archive/master.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Admin consent

+>

+> If you try to run the application at this point, you'll receive *HTTP 403 - Forbidden* error: `Insufficient privileges to complete the operation`. This error happens because any *app-only permission* requires Admin consent: a global administrator of your directory must give consent to your application. Select one of the options below depending on your role:

+>

+> ##### Global tenant administrator

+>

+> If you are a global administrator, go to **API Permissions** page select **Grant admin consent for Enter_the_Tenant_Name_Here**.

+> > [!div id="apipermissionspage"]

+> > [Go to the API Permissions page]()

+>

+> ##### Standard user

+>

+> If you're a standard user of your tenant, then you need to ask a global administrator to grant admin consent for your application. To do this, give the following URL to your administrator:

+>

+> ```url

+> https://login.microsoftonline.com/Enter_the_Tenant_Id_Here/adminconsent?client_id=Enter_the_Application_Id_Here

+> ```

+> #### Step 4: Run the application

+>

+> You can test the sample directly by running the main method of ClientCredentialGrant.java from your IDE.

+>

+> From your shell or command line:

+>

+> ```

+> $ mvn clean compile assembly:single

+> ```

+>

+> This will generate a msal-client-credential-secret-1.0.0.jar file in your /targets directory. Run this using your Java executable like below:

+>

+> ```

+> $ java -jar msal-client-credential-secret-1.0.0.jar

+> ```

+>

+> After running, the application should display the list of users in the configured tenant.

+>

+> > [!IMPORTANT]

+> > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](https://github.com/Azure-Samples/ms-identity-java-daemon/tree/master/msal-client-credential-certificate) in the same GitHub repository for this sample, but in the second folder **msal-client-credential-certificate**.

+>

+> ## More information

+>

+> ### MSAL Java

+>

+> [MSAL Java](https://github.com/AzureAD/microsoft-authentication-library-for-java) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. As described, this quickstart requests tokens by using the application own identity instead of delegated permissions. The authentication flow used in this case is known as *[client credentials oauth flow](v2-oauth2-client-creds-grant-flow.md)*. For more information on how to use MSAL Java with daemon apps, see [this article](scenario-daemon-overview.md).

+>

+> Add MSAL4J to your application by using Maven or Gradle to manage your dependencies by making the following changes to the application's pom.xml (Maven) or build.gradle (Gradle) file.

+>

+> In pom.xml:

+>

+> ```xml

+> <dependency>

+> <groupId>com.microsoft.azure</groupId>

+> <artifactId>msal4j</artifactId>

+> <version>1.0.0</version>

+> </dependency>

+> ```

+>

+> In build.gradle:

+>

+> ```$xslt

+> compile group: 'com.microsoft.azure', name: 'msal4j', version: '1.0.0'

+> ```

+>

+> ### MSAL initialization

+>

+> Add a reference to MSAL for Java by adding the following code to the top of the file where you will be using MSAL4J:

+>

+> ```Java

+> import com.microsoft.aad.msal4j.*;

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```Java

+> IClientCredential credential = ClientCredentialFactory.createFromSecret(CLIENT_SECRET);

+>

+> ConfidentialClientApplication cca =

+> ConfidentialClientApplication

+> .builder(CLIENT_ID, credential)

+> .authority(AUTHORITY)

+> .build();

+> ```

+>

+> > | Where: |Description |

+> > |||

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

+> > | `AUTHORITY` | The STS endpoint for user to authenticate. Usually `https://login.microsoftonline.com/{tenant}` for public cloud, where {tenant} is the name of your tenant or your tenant Id.|

+>

+> ### Requesting tokens

+>

+> To request a token using app's identity, use `acquireToken` method:

+>

+> ```Java

+> IAuthenticationResult result;

+> try {

+> SilentParameters silentParameters =

+> SilentParameters

+> .builder(SCOPE)

+> .build();

+>

+> // try to acquire token silently. This call will fail since the token cache does not

+> // have a token for the application you are requesting an access token for

+> result = cca.acquireTokenSilently(silentParameters).join();

+> } catch (Exception ex) {

+> if (ex.getCause() instanceof MsalException) {

+>

+> ClientCredentialParameters parameters =

+> ClientCredentialParameters

+> .builder(SCOPE)

+> .build();

+>

+> // Try to acquire a token. If successful, you should see

+> // the token information printed out to console

+> result = cca.acquireToken(parameters).join();

+> } else {

+> // Handle other exceptions accordingly

+> throw ex;

+> }

+> }

+> return result;

+> ```

+>

+> > |Where:| Description |

+> > |||

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

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> To learn more about daemon applications, see the scenario landing page.

+>

+> > [!div class="nextstepaction"]

+> > [Daemon application that calls web APIs](scenario-daemon-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Java web app with user sign-in](web-app-quickstart.md?pivots=devlang-java)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Java web application can sign in users and call the Microsoft Graph API. Users from any Azure Active Directory (Azure AD) organization can sign in to the application.

+>

+> For an overview, see the [diagram of how the sample works](#how-the-sample-works).

+>

+> ## Prerequisites

+>

+> To run this sample, you need:

+>

+> - [Java Development Kit (JDK)](https://openjdk.java.net/) 8 or later.

+> - [Maven](https://maven.apache.org/).

+>

+>

+> #### Step 1: Configure your application in the Azure portal

+>

+> To use the code sample in this quickstart:

+>

+> 1. Add reply URLs `https://localhost:8443/msal4jsample/secure/aad` and `https://localhost:8443/msal4jsample/graph/me`.

+> 1. Create a client secret.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the code sample

+>

+> Download the project and extract the .zip file into a folder near the root of your drive. For example, *C:\Azure-Samples*.

+>

+> To use HTTPS with localhost, provide the `server.ssl.key` properties. To generate a self-signed certificate, use the keytool utility (included in JRE).

+>

+> Here's an example:

+> ```

+> keytool -genkeypair -alias testCert -keyalg RSA -storetype PKCS12 -keystore keystore.p12 -storepass password

+>

+> server.ssl.key-store-type=PKCS12

+> server.ssl.key-store=classpath:keystore.p12

+> server.ssl.key-store-password=password

+> server.ssl.key-alias=testCert

+> ```

+> Put the generated keystore file in the *resources* folder.

+>

+> > [!div class="sxs-lookup nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-java-webapp/archive/master.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> > [!div class="sxs-lookup"]

+>

+> #### Step 3: Run the code sample

+>

+> To run the project, take one of these steps:

+>

+> - Run it directly from your IDE by using the embedded Spring Boot server.

+> - Package it to a WAR file by using [Maven](https://maven.apache.org/plugins/maven-war-plugin/usage.html), and then deploy it to a J2EE container solution like [Apache Tomcat](http://tomcat.apache.org/).

+>

+> ##### Running the project from an IDE

+>

+> To run the web application from an IDE, select run, and then go to the home page of the project. For this sample, the standard home page URL is https://localhost:8443.

+>

+> 1. On the front page, select the **Login** button to redirect users to Azure Active Directory and prompt them for credentials.

+>

+> 1. After users are authenticated, they're redirected to `https://localhost:8443/msal4jsample/secure/aad`. They're now signed in, and the page will show information about the user account. The sample UI has these buttons:

+> - **Sign Out**: Signs the current user out of the application and redirects that user to the home page.

+> - **Show User Info**: Acquires a token for Microsoft Graph and calls Microsoft Graph with a request that contains the token, which returns basic information about the signed-in user.

+>

+> ##### Running the project from Tomcat

+>

+> If you want to deploy the web sample to Tomcat, make a couple changes to the source code.

+>

+> 1. Open *ms-identity-java-webapp/src/main/java/com.microsoft.azure.msalwebsample/MsalWebSampleApplication*.

+>

+> - Delete all source code and replace it with this code:

+>

+> ```Java

+> package com.microsoft.azure.msalwebsample;

+>

+> import org.springframework.boot.SpringApplication;

+> import org.springframework.boot.autoconfigure.SpringBootApplication;

+> import org.springframework.boot.builder.SpringApplicationBuilder;

+> import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

+>

+> @SpringBootApplication

+> public class MsalWebSampleApplication extends SpringBootServletInitializer {

+>

+> public static void main(String[] args) {

+> SpringApplication.run(MsalWebSampleApplication.class, args);

+> }

+>

+> @Override

+> protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {

+> return builder.sources(MsalWebSampleApplication.class);

+> }

+> }

+> ```

+>

+> 2. Tomcat's default HTTP port is 8080, but you need an HTTPS connection over port 8443. To configure this setting:

+> - Go to *tomcat/conf/server.xml*.

+> - Search for the `<connector>` tag, and replace the existing connector with this connector:

+>

+> ```xml

+> <Connector

+> protocol="org.apache.coyote.http11.Http11NioProtocol"

+> port="8443" maxThreads="200"

+> scheme="https" secure="true" SSLEnabled="true"

+> keystoreFile="C:/Path/To/Keystore/File/keystore.p12" keystorePass="KeystorePassword"

+> clientAuth="false" sslProtocol="TLS"/>

+> ```

+>

+> 3. Open a Command Prompt window. Go to the root folder of this sample (where the pom.xml file is located), and run `mvn > package` to build the project.

+> - This command will generate a *msal-web-sample-0.1.0.war* file in your */targets* directory.

+> - Rename this file to *msal4jsample.war*.

+> - Deploy the WAR file by using Tomcat or any other J2EE container solution.

+> - To deploy the msal4jsample.war file, copy it to the */webapps/* directory in your Tomcat installation, and then start the Tomcat server.

+>

+> 4. After the file is deployed, go to https://localhost:8443/msal4jsample by using a browser.

+>

+> > [!IMPORTANT]

+> > This quickstart application uses a client secret to identify itself as a confidential client. Because the client secret is added as plain text to your project files, for security reasons we recommend that you use a certificate instead of a client secret before using the application in a production environment. For more information on how to use a certificate, see [Certificate credentials for application authentication](./active-directory-certificate-credentials.md).

+>

+> ## More information

+>

+> ### How the sample works

+> 

+>

+> ### Get MSAL

+>

+> MSAL for Java (MSAL4J) is the Java library used to sign in users and request tokens that are used to access an API that's protected by the Microsoft identity platform.

+>

+> Add MSAL4J to your application by using Maven or Gradle to manage your dependencies by making the following changes to the > application's pom.xml (Maven) or build.gradle (Gradle) file.

+>

+> In pom.xml:

+>

+> ```xml

+> <dependency>

+> <groupId>com.microsoft.azure</groupId>

+> <artifactId>msal4j</artifactId>

+> <version>1.0.0</version>

+> </dependency>

+> ```

+>

+> In build.gradle:

+>

+> ```$xslt

+> compile group: 'com.microsoft.azure', name: 'msal4j', version: '1.0.0'

+> ```

+>

+> ### Initialize MSAL

+>

+> Add a reference to MSAL for Java by adding the following code at the start of the file where you'll be using MSAL4J:

+>

+> ```Java

+> import com.microsoft.aad.msal4j.*;

+> ```

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> For a more in-depth discussion of building web apps that sign in users on the Microsoft identity platform, see the multipart scenario series:

+>

+> > [!div class="nextstepaction"]

+> > [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md?tabs=java)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Angular single-page app with user sign-in](single-page-app-quickstart.md?pivots=devlang-angular)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a JavaScript Angular single-page application (SPA) can sign in users and call Microsoft Graph using the authorization code flow. The code sample demonstrates how to get an access token to call the Microsoft Graph API or any web API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> This quickstart uses MSAL Angular v2 with the authorization code flow.

+>

+> ## Prerequisites

+>

+> * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+> #### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work, add a **Redirect URI** of `http://localhost:4200/`.

+>

+> >[!div class="nextstepaction"]

+> >[Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these > attributes.

+>

+> #### Step 2: Download the project

+>

+> Run the project with a web server by using Node.js

+>

+> >[!div class="nextstepaction"]

+> >[Download the code sample](https://github.com/Azure-Samples/ms-identity-javascript-angular-spa/archive/main.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+>

+> #### Step 3: Your app is configured and ready to run

+>

+> We have configured your project with values of your app's properties.

+>

+> #### Step 4: Run the project

+>

+> Run the project with a web server by using Node.js:

+>

+> 1. To start the server, run the following commands from within the project directory:

+> ```console

+> npm install

+> npm start

+> ```

+> 1. Browse to `http://localhost:4200/`.

+>

+> 1. Select **Login** to start the sign-in process and then call the Microsoft Graph API.

+>

+> The first time you sign in, you're prompted to provide your consent to allow the application to access your profile and sign you in. After you're signed in successfully, click the **Profile** button to display your user information on the page.

+>

+> ## More information

+>

+> ### How the sample works

+>

+> 

+>

+> ### msal.js

+>

+> The MSAL.js library signs in users and requests the tokens that are used to access an API that's protected by the Microsoft identity platform.

+>

+> If you have Node.js installed, you can download the latest version by using the Node.js Package Manager (npm):

+>

+> ```console

+> npm install @azure/msal-browser @azure/msal-angular@2

+> ```

+>

+> ## Next steps

+>

+> For a detailed step-by-step guide on building the auth code flow application using vanilla JavaScript, see the following tutorial:

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)

+> # Quickstart: Sign in and get an access token in a React SPA using the auth code flow

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: React single-page app with user sign-in](single-page-app-quickstart.md?pivots=devlang-react)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a JavaScript React single-page application (SPA) can sign in users and call Microsoft Graph using the authorization code flow. The code sample demonstrates how to get an access token to call the Microsoft Graph API or any web API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> ## Prerequisites

+>

+> * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+> #### Step 1: Configure your application in the Azure portal

+>

+> This code samples requires a **Redirect URI** of `http://localhost:3000/`.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the project

+>

+> Run the project with a web server by using Node.js

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-javascript-react-spa/archive/main.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+>

+> #### Step 3: Your app is configured and ready to run

+> We have configured your project with values of your app's properties.

+>

+> #### Step 4: Run the project

+>

+> Run the project with a web server by using Node.js:

+>

+> 1. To start the server, run the following commands from within the project directory:

+> ```console

+> npm install

+> npm start

+> ```

+> 1. Browse to `http://localhost:3000/`.

+>

+> 1. Select **Sign In** to start the sign-in process and then call the Microsoft Graph API.

+>

+> The first time you sign in, you're prompted to provide your consent to allow the application to access your profile and sign you in. After you're signed in successfully, click on the **Request Profile Information** to display your profile information on the page.

+>

+> ## More information

+>

+> ### How the sample works

+>

+> 

+>

+> ### msal.js

+>

+> The MSAL.js library signs in users and requests the tokens that are used to access an API that's protected by the Microsoft identity platform.

+>

+> If you have Node.js installed, you can download the latest version by using the Node.js Package Manager (npm):

+>

+> ```console

+> npm install @azure/msal-browser @azure/msal-react

+> ```

+>

+> ## Next steps

+>

+> Next, try a step-by-step tutorial to learn how to build a React SPA from scratch that signs in users and calls the > Microsoft Graph API to get user profile data:

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial: Sign in users and call Microsoft Graph](tutorial-v2-react.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: JavaScript single-page app with user sign-in](single-page-app-quickstart.md?pivots=devlang-javascript)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a JavaScript single-page application (SPA) can sign in users and call Microsoft Graph using the authorization code flow with Proof Key for Code Exchange (PKCE). The code sample demonstrates how to get an access token to call the Microsoft Graph API or any web API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> ## Prerequisites

+>

+> * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+>

+> #### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work, add a **Redirect URI** of `http://localhost:3000/`.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the project

+>

+> Run the project with a web server by using Node.js

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-javascript-v2/archive/master.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Your app is configured and ready to run

+>

+> We have configured your project with values of your app's properties.

+>

+> Run the project with a web server by using Node.js.

+>

+> 1. To start the server, run the following commands from within the project directory:

+>

+> ```console

+> npm install

+> npm start

+> ```

+>

+> 1. Go to `http://localhost:3000/`.

+>

+> 1. Select **Sign In** to start the sign-in process and then call the Microsoft Graph API.

+>

+> The first time you sign in, you're prompted to provide your consent to allow the application to access your profile and sign you in. After you're signed in successfully, your user profile information is displayed on the page.

+>

+> ## More information

+>

+> ### How the sample works

+>

+> 

+>

+> ### MSAL.js

+>

+> The MSAL.js library signs in users and requests the tokens that are used to access an API that's protected by Microsoft > identity platform. The sample's *https://docsupdatetracker.net/index.html* file contains a reference to the library:

+>

+> ```html

+> <script type="text/javascript" src="https://alcdn.msauth.net/browser/2.0.0-beta.0/js/msal-browser.js" integrity=

+> "sha384-r7Qxfs6PYHyfoBR6zG62DGzptfLBxnREThAlcJyEfzJ4dq5rqExc1Xj3TPFE/9TH" crossorigin="anonymous"></script>

+> ```

+>

+> If you have Node.js installed, you can download the latest version by using the Node.js Package Manager (npm):

+>

+> ```console

+> npm install @azure/msal-browser

+> ```

+>

+> ## Next steps

+>

+> For a more detailed step-by-step guide on building the application used in this quickstart, see the following tutorial:

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: .NET Core console that calls an API](console-app-quickstart.md?pivots=devlang-dotnet-core)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a .NET Core console application can get an access token to call the Microsoft Graph API and display a [list of users](/graph/api/user-list) in the directory. The code sample also demonstrates how a job or a Windows service can run with an application identity, instead of a user's identity. The sample console application in this quickstart is also a daemon application, so it's a confidential client application.

+>

+> ## Prerequisites

+>

+> This quickstart requires [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download) but will also work with .NET 5.0 SDK.

+>

+> > [!div class="sxs-lookup"]

+> ### Download and configure your quickstart app

+>

+> #### Step 1: Configure your application in the Azure portal

+> For the code sample in this quickstart to work, create a client secret and add the Graph API's **User.Read.All** application permission.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download your Visual Studio project

+>

+> > [!div class="sxs-lookup"]

+> > Run the project by using Visual Studio 2019.

+> > [!div class="sxs-lookup" id="autoupdate" class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/archive/master.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Admin consent

+>

+> If you try to run the application at this point, you'll receive an *HTTP 403 - Forbidden* error: "Insufficient privileges to complete the operation." This error happens because any app-only permission requires a global administrator of your directory to give consent to your application. Select one of the following options, depending on your role.

+>

+> ##### Global tenant administrator

+>

+> If you're a global administrator, go to the **API Permissions** page and select **Grant admin consent for Enter_the_Tenant_Name_Here**.

+> > [!div id="apipermissionspage"]

+> > [Go to the API Permissions page]()

+>

+> ##### Standard user

+>

+> If you're a standard user of your tenant, ask a global administrator to grant admin consent for your application. To do this, give the following URL to your administrator:

+>

+> ```url

+> https://login.microsoftonline.com/Enter_the_Tenant_Id_Here/adminconsent?client_id=Enter_the_Application_Id_Here

+> ```

+>

+> You might see the error "AADSTS50011: No reply address is registered for the application" after you grant consent to the app by using the preceding URL. This error happens because this application and the URL don't have a redirect URI. You can ignore it.

+>

+> #### Step 4: Run the application

+>

+> If you're using Visual Studio or Visual Studio for Mac, press **F5** to run the application. Otherwise, run the application via command prompt, console, or terminal:

+>

+> ```dotnetcli

+> cd {ProjectFolder}\1-Call-MSGraph\daemon-console

+> dotnet run

+> ```

+> In that code:

+> * `{ProjectFolder}` is the folder where you extracted the .zip file. An example is `C:\Azure-Samples\active-directory-dotnetcore-daemon-v2`.

+>

+> You should see a list of users in Azure Active Directory as result.

+>

+> This quickstart application uses a client secret to identify itself as a confidential client. The client secret is added as a plain-text file to your project files. For security reasons, we recommend that you use a certificate instead of a client secret before considering the application as a production application. For more information on how to use a certificate, see [these instructions](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/#variation-daemon-application-using-client-credentials-with-certificates) in the GitHub repository for this sample.

+>

+> ## More information

+> This section gives an overview of the code required to sign in users. This overview can be useful to understand how the > code works, what the main arguments are, and how to add sign-in to an existing .NET Core console application.

+>

+> > [!div class="sxs-lookup"]

+> ### How the sample works

+>

+> 

+>

+> ### MSAL.NET

+>

+> Microsoft Authentication Library (MSAL, in the [Microsoft.Identity.Client](https://www.nuget.org/packages/Microsoft.Identity.Client) package) is the library that's used to sign in users and request tokens for accessing an API protected by the Microsoft identity platform. This quickstart requests tokens by using the application's own identity instead of delegated permissions. The authentication flow in this case is known as a [client credentials OAuth flow](v2-oauth2-client-creds-grant-flow.md). For more information on how to use MSAL.NET with a client credentials flow, see [this article](https://aka.ms/msal-net-client-credentials).

+>

+> You can install MSAL.NET by running the following command in the Visual Studio Package Manager Console:

+>

+> ```dotnetcli

+> dotnet add package Microsoft.Identity.Client

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```csharp

+> using Microsoft.Identity.Client;

+> ```

+>

+> Then, initialize MSAL by using the following code:

+>

+> ```csharp

+> IConfidentialClientApplication app;

+> app = ConfidentialClientApplicationBuilder.Create(config.ClientId)

+> .WithClientSecret(config.ClientSecret)

+> .WithAuthority(new Uri(config.Authority))

+> .Build();

+> ```

+>

+> | Element | Description |

+> |||

+> | `config.ClientSecret` | The client secret created for the application in the Azure portal. |

+> | `config.ClientId` | The application (client) ID for the application registered in the Azure portal. You can find this value on the app's **Overview** page in the Azure portal. |

+> | `config.Authority` | (Optional) The security token service (STS) endpoint for the user to authenticate. It's usually `https://login.microsoftonline.com/{tenant}` for the public cloud, where `{tenant}` is the name of your tenant or your tenant ID.|

+>

+> For more information, see the [reference documentation for `ConfidentialClientApplication`](/dotnet/api/microsoft.identity.client.iconfidentialclientapplication).

+>

+> ### Requesting tokens

+>

+> To request a token by using the app's identity, use the `AcquireTokenForClient` method:

+>

+> ```csharp

+> result = await app.AcquireTokenForClient(scopes)

+> .ExecuteAsync();

+> ```

+>

+> |Element| Description |

+> |||

+> | `scopes` | Contains the requested scopes. For confidential clients, this value should use a format similar to `{Application ID URI}/.default`. This format indicates that the requested scopes are the ones that are 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 in the Azure portal, under **Application Registration (Preview)** > **Expose an API**. |

+>

+> For more information, see the [reference documentation for `AcquireTokenForClient`](/dotnet/api/microsoft.identity.client.confidentialclientapplication.acquiretokenforclient).

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> To learn more about daemon applications, see the scenario overview:

+>

+> > [!div class="nextstepaction"]

+> > [Daemon application that calls web APIs](scenario-daemon-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Node.js console app that calls an API](console-app-quickstart.md?pivots=devlang-nodejs)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Node.js console application can get an access token using the app's identity to call the Microsoft Graph API and display a [list of users](/graph/api/user-list) in the directory. The code sample demonstrates how an unattended job or Windows service can run with an application identity, instead of a user's identity.

+>

+> This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Node)](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node) with the [client credentials grant](v2-oauth2-client-creds-grant-flow.md).

+>

+> ## Prerequisites

+>

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+>

+> ### Download and configure the sample app

+>

+> #### Step 1: Configure the application in Azure portal

+> For the code sample for this quickstart to work, you need to create a client secret, and add Graph API's **User.Read.All** application permission.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the Node.js sample project

+>

+> > [!div class="sxs-lookup nextstepaction"]

+> > [Download the code sample](https://github.com/azure-samples/ms-identity-javascript-nodejs-console/archive/main.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Admin consent

+>

+> If you try to run the application at this point, you'll receive *HTTP 403 - Forbidden* error: `Insufficient privileges to complete the operation`. This error happens because any *app-only permission* requires **admin consent**: a global administrator of your directory must give consent to your application. Select one of the options below depending on your role:

+>

+> ##### Global tenant administrator

+>

+> If you are a global administrator, go to **API Permissions** page select **Grant admin consent for > Enter_the_Tenant_Name_Here**

+> > > [!div id="apipermissionspage"]

+> > > [Go to the API Permissions page]()

+>

+> ##### Standard user

+>

+> If you're a standard user of your tenant, then you need to ask a global administrator to grant **admin consent** for your application. To do this, give the following URL to your administrator:

+>

+> ```url

+> https://login.microsoftonline.com/Enter_the_Tenant_Id_Here/adminconsent?client_id=Enter_the_Application_Id_Here

+> ```

+>

+> #### Step 4: Run the application

+>

+> Locate the sample's root folder (where `package.json` resides) in a command prompt or console. You'll need to install the dependencies of this sample once:

+>

+> ```console

+> npm install

+> ```

+>

+> Then, run the application via command prompt or console:

+>

+> ```console

+> node . --op getUsers

+> ```

+>

+> You should see on the console output some JSON fragment representing a list of users in your Azure AD directory.

+>

+> ## About the code

+>

+> Below, some of the important aspects of the sample application are discussed.

+>

+> ### MSAL Node

+>

+> [MSAL Node](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. As described, this quickstart requests tokens by application permissions (using the application's own identity) instead of delegated permissions. The authentication flow used in this case is known as [OAuth 2.0 client credentials flow](v2-oauth2-client-creds-grant-flow.md). For more information on how to use MSAL Node with daemon apps, see [Scenario: Daemon application](scenario-daemon-overview.md).

+>

+> You can install MSAL Node by running the following npm command.

+>

+> ```console

+> npm install @azure/msal-node --save

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```javascript

+> const msal = require('@azure/msal-node');

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```javascript

+> const msalConfig = {

+> auth: {

+> clientId: "Enter_the_Application_Id_Here",

+> authority: "https://login.microsoftonline.com/Enter_the_Tenant_Id_Here",

+> clientSecret: "Enter_the_Client_Secret_Here",

+> }

+> };

+> const cca = new msal.ConfidentialClientApplication(msalConfig);

+> ```

+>

+> > | Where: |Description |

+> > |||

+> > | `clientId` | 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. |

+> > | `authority` | The STS endpoint for user to authenticate. Usually `https://login.microsoftonline.com/{tenant}` for public cloud, where {tenant} is the name of your tenant or your tenant Id.|

+> > | `clientSecret` | Is the client secret created for the application in Azure Portal. |

+>

+> For more information, please see the [reference documentation for `ConfidentialClientApplication`](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/initialize-confidential-client-application.md)

+>

+> ### Requesting tokens

+>

+> To request a token using app's identity, use `acquireTokenByClientCredential` method:

+>

+> ```javascript

+> const tokenRequest = {

+> scopes: [ 'https://graph.microsoft.com/.default' ],

+> };

+>

+> const tokenResponse = await cca.acquireTokenByClientCredential(tokenRequest);

+> ```

+>

+> > |Where:| Description |

+> > |||

+> > | `tokenRequest` | 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 **Expose an API** section in Azure Portal's Application Registration. |

+> > | `tokenResponse` | The response contains an access token for the scopes requested. |

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> To learn more about daemon/console app development with MSAL Node, see the tutorial:

+>

+> > [!div class="nextstepaction"]

+> > [Daemon application that calls web APIs](tutorial-v2-nodejs-console.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Node.js Electron desktop app with user sign-in](desktop-app-quickstart.md?pivots=devlang-nodejs-electron)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how an Electron desktop application can sign in users and acquire access tokens to call the Microsoft Graph API.

+>

+> This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Node)](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node) with the [authorization code flow with PKCE](v2-oauth2-auth-code-flow.md).

+>

+> ## Prerequisites

+>

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+> #### Step 1: Configure the application in Azure portal

+> For the code sample for this quickstart to work, you need to add a reply URL as **msal://redirect**.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the Electron sample project

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/azure-samples/ms-identity-javascript-nodejs-desktop/archive/main.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 4: Run the application

+>

+> You'll need to install the dependencies of this sample once:

+>

+> ```console

+> npm install

+> ```

+>

+> Then, run the application via command prompt or console:

+>

+> ```console

+> npm start

+> ```

+>

+> You should see application's UI with a **Sign in** button.

+>

+> ## About the code

+>

+> Below, some of the important aspects of the sample application are discussed.

+>

+> ### MSAL Node

+>

+> [MSAL Node](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. For more information on how to use MSAL Node with desktop apps, see [this article](scenario-desktop-overview.md).

+>

+> You can install MSAL Node by running the following npm command.

+>

+> ```console

+> npm install @azure/msal-node --save

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL Node by adding the following code:

+>

+> ```javascript

+> const { PublicClientApplication } = require('@azure/msal-node');

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```javascript

+> const MSAL_CONFIG = {

+> auth: {

+> clientId: "Enter_the_Application_Id_Here",

+> authority: "https://login.microsoftonline.com/Enter_the_Tenant_Id_Here",

+> },

+> };

+>

+> const pca = new PublicClientApplication(MSAL_CONFIG);

+> ```

+>

+> > | Where: |Description |

+> > |||

+> > | `clientId` | 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. |

+> > | `authority` | The STS endpoint for user to authenticate. Usually `https://login.microsoftonline.com/{tenant}` for public cloud, where {tenant} is the name of your tenant or your tenant Id.|

+>

+> ### Requesting tokens

+>

+> In the first leg of authorization code flow with PKCE, prepare and send an authorization code request with the appropriate parameters. Then, in the second leg of the flow, listen for the authorization code response. Once the code is obtained, exchange it to obtain a token.

+>

+> ```javascript

+> // The redirect URI you setup during app registration with a custom file protocol "msal"

+> const redirectUri = "msal://redirect";

+>

+> const cryptoProvider = new CryptoProvider();

+>

+> const pkceCodes = {

+> challengeMethod: "S256", // Use SHA256 Algorithm

+> verifier: "", // Generate a code verifier for the Auth Code Request first

+> challenge: "" // Generate a code challenge from the previously generated code verifier

+> };

+>

+> /**

+> * Starts an interactive token request

+> * @param {object} authWindow: Electron window object

+> * @param {object} tokenRequest: token request object with scopes

+> */

+> async function getTokenInteractive(authWindow, tokenRequest) {

+>

+> /**

+> * Proof Key for Code Exchange (PKCE) Setup

+> *

+> * MSAL enables PKCE in the Authorization Code Grant Flow by including the codeChallenge and codeChallengeMethod

+> * parameters in the request passed into getAuthCodeUrl() API, as well as the codeVerifier parameter in the

+> * second leg (acquireTokenByCode() API).

+> */

+>

+> const {verifier, challenge} = await cryptoProvider.generatePkceCodes();

+>

+> pkceCodes.verifier = verifier;

+> pkceCodes.challenge = challenge;

+>

+> const authCodeUrlParams = {

+> redirectUri: redirectUri

+> scopes: tokenRequest.scopes,

+> codeChallenge: pkceCodes.challenge, // PKCE Code Challenge

+> codeChallengeMethod: pkceCodes.challengeMethod // PKCE Code Challenge Method

+> };

+>

+> const authCodeUrl = await pca.getAuthCodeUrl(authCodeUrlParams);

+>

+> // register the custom file protocol in redirect URI

+> protocol.registerFileProtocol(redirectUri.split(":")[0], (req, callback) => {

+> const requestUrl = url.parse(req.url, true);

+> callback(path.normalize(`${__dirname}/${requestUrl.path}`));

+> });

+>

+> const authCode = await listenForAuthCode(authCodeUrl, authWindow); // see below

+>

+> const authResponse = await pca.acquireTokenByCode({

+> redirectUri: redirectUri,

+> scopes: tokenRequest.scopes,

+> code: authCode,

+> codeVerifier: pkceCodes.verifier // PKCE Code Verifier

+> });

+>

+> return authResponse;

+> }

+>

+> /**

+> * Listens for auth code response from Azure AD

+> * @param {string} navigateUrl: URL where auth code response is parsed

+> * @param {object} authWindow: Electron window object

+> */

+> async function listenForAuthCode(navigateUrl, authWindow) {

+>

+> authWindow.loadURL(navigateUrl);

+>

+> return new Promise((resolve, reject) => {

+> authWindow.webContents.on('will-redirect', (event, responseUrl) => {

+> try {

+> const parsedUrl = new URL(responseUrl);

+> const authCode = parsedUrl.searchParams.get('code');

+> resolve(authCode);

+> } catch (err) {

+> reject(err);

+> }

+> });

+> });

+> }

+> ```

+>

+> > |Where:| Description |

+> > |||

+> > | `authWindow` | Current Electron window in process. |

+> > | `tokenRequest` | Contains the scopes being requested, such as `"User.Read"` for Microsoft Graph or `"api://<Application ID>/access_as_user"` for custom web APIs. |

+>

+> ## Next steps

+>

+> To learn more about Electron desktop app development with MSAL Node, see the tutorial:

+>

+> > [!div class="nextstepaction"]

+> > [Tutorial: Sign in users and call the Microsoft Graph API in an Electron desktop app](tutorial-v2-nodejs-desktop.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Node.js web app that signs in users with MSAL Node](web-app-quickstart.md?pivots=devlang-nodejs-msal)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Node.js web app can sign in users by using the authorization code flow. The code sample also demonstrates how to get an access token to call Microsoft Graph API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node) with the authorization code flow.

+>

+> ## Prerequisites

+>

+> * An Azure subscription. [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> * [Node.js](https://nodejs.org/en/download/)

+> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor

+>

+> #### Step 1: Configure the application in Azure portal

+> For the code sample for this quickstart to work, you need to create a client secret and add the following reply URL: `http:/> /localhost:3000/redirect`.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these > attributes.

+>

+> #### Step 2: Download the project

+>

+> Run the project with a web server by using Node.js.

+>

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-node/archive/main.zip)

+>

+> #### Step 3: Your app is configured and ready to run

+>

+> Run the project by using Node.js.

+>

+> 1. To start the server, run the following commands from within the project directory:

+>

+> ```console

+> npm install

+> npm start

+> ```

+>

+> 1. Go to `http://localhost:3000/`.

+>

+> 1. Select **Sign In** to start the sign-in process.

+>

+> The first time you sign in, you're prompted to provide your consent to allow the application to access your profile and sign you in. After you're signed in successfully, you will see a log message in the command line.

+>

+> ## More information

+>

+> ### How the sample works

+>

+> The sample hosts a web server on localhost, port 3000. When a web browser accesses this site, the sample immediately redirects the user to a Microsoft authentication page. Because of this, the sample does not contain any HTML or display elements. Authentication success displays the message "OK".

+>

+> ### MSAL Node

+>

+> The MSAL Node library signs in users and requests the tokens that are used to access an API that's protected by Microsoft identity platform. You can download the latest version by using the Node.js Package Manager (npm):

+>

+> ```console

+> npm install @azure/msal-node

+> ```

+>

+> ## Next steps

+>

+> > [!div class="nextstepaction"]

+> > [Adding Auth to an existing web app - GitHub code sample >](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/auth-code)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Add user sign-in to a Node.js web app built with the Express framework ](web-app-quickstart.md?pivots=devlang-nodejs-passport)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how to set up OpenID Connect authentication in a web application built using Node.js with Express. The sample is designed to run on any platform.

+>

+> ## Prerequisites

+>

+> - An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> - [Node.js](https://nodejs.org/en/download/).

+>

+> ## 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**.

+> 1. Enter a **Name** for your application, for example `MyWebApp`. Users of your app might see this name, and you can change it later.

+> 1. In the **Supported account types** section, select **Accounts in any organizational directory and personal Microsoft accounts (e.g. Skype, Xbox, Outlook.com)**.

+>

+> If there are more than one redirect URIs, add these from the **Authentication** tab later after the app has been successfully created.

+>

+> 1. Select **Register** to create the app.

+> 1. On the app's **Overview** page, find the **Application (client) ID** value and record it for later. You'll need this > value to configure the application later in this project.

+> 1. Under **Manage**, select **Authentication**.

+> 1. Select **Add a platform** > **Web**.

+> 1. In the **Redirect URIs** section, enter `http://localhost:3000/auth/openid/return`.

+> 1. Enter a **Front-channel logout URL** `https://localhost:3000`.

+> 1. In the **Implicit grant and hybrid flows** section, select **ID tokens** as this sample requires the [Implicit grant flow](./v2-oauth2-implicit-grant-flow.md) to be enabled to sign-in the user.

+> 1. Select **Configure**.

+> 1. Under **Manage**, select **Certificates & secrets** > **Client secrets** > **New client secret**.

+> 1. Enter a key description (for instance app secret).

+> 1. Select a key duration of either **In 1 year, In 2 years,** or **Never Expires**.

+> 1. Select **Add**. The key value will be displayed. Copy the key value and save it in a safe location for later use.

+>

+>

+> ## Download the sample application and modules

+>

+> Next, clone the sample repo and install the NPM modules.

+>

+> From your shell or command line:

+>

+> `$ git clone git@github.com:AzureADQuickStarts/AppModelv2-WebApp-OpenIDConnect-nodejs.git`

+>

+> or

+>

+> `$ git clone https://github.com/AzureADQuickStarts/AppModelv2-WebApp-OpenIDConnect-nodejs.git`

+>

+> From the project root directory, run the command:

+>

+> `$ npm install`

+>

+> ## Configure the application

+>

+> Provide the parameters in `exports.creds` in config.js as instructed.

+>

+> * Update `<tenant_name>` in `exports.identityMetadata` with the Azure AD tenant name of the format \*.onmicrosoft.com.

+> * Update `exports.clientID` with the Application ID noted from app registration.

+> * Update `exports.clientSecret` with the Application secret noted from app registration.

+> * Update `exports.redirectUrl` with the Redirect URI noted from app registration.

+>

+> **Optional configuration for production apps:**

+>

+> * Update `exports.destroySessionUrl` in config.js, if you want to use a different `post_logout_redirect_uri`.

+>

+> * Set `exports.useMongoDBSessionStore` in config.js to true, if you want to use [mongoDB](https://www.mongodb.com) or other [compatible session stores](https://github.com/expressjs/session#compatible-session-stores).

+> The default session store in this sample is `express-session`. The default session store is not suitable for production.

+>

+> * Update `exports.databaseUri`, if you want to use mongoDB session store and a different database URI.

+>

+> * Update `exports.mongoDBSessionMaxAge`. Here you can specify how long you want to keep a session in mongoDB. The unit is second(s).

+>

+> ## Build and run the application

+>

+> Start mongoDB service. If you are using mongoDB session store in this app, you have to [install mongoDB](http://www.mongodb.org/) and start the service first. If you are using the default session store, you can skip this step.

+>

+> Run the app using the following command from your command line.

+>

+> ```

+> $ node app.js

+> ```

+>

+> **Is the server output hard to understand?:** We use `bunyan` for logging in this sample. The console won't make much sense to you unless you also install bunyan and run the server like above but pipe it through the bunyan binary:

+>

+> ```

+> $ npm install -g bunyan

+>

+> $ node app.js | bunyan

+> ```

+>

+> ### You're done!

+>

+> You will have a server successfully running on `http://localhost:3000`.

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+> Learn more about the web app scenario that the Microsoft identity platform supports:

+> > [!div class="nextstepaction"]

+> > [Web app that signs in users scenario](scenario-web-app-sign-user-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Python console app that calls an API](console-app-quickstart.md?pivots=devlang-python)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Python application can get an access token using the app's identity to call the Microsoft Graph API and display a [list of users](/graph/api/user-list) in the directory. The code sample demonstrates how an unattended job or Windows service can run with an application identity, instead of a user's identity.

+>

+> ## Prerequisites

+>

+> To run this sample, you need:

+>

+> - [Python 2.7+](https://www.python.org/downloads/release/python-2713) or [Python 3+](https://www.python.org/downloads/release/python-364/)

+> - [MSAL Python](https://github.com/AzureAD/microsoft-authentication-library-for-python)

+>

+> > [!div class="sxs-lookup"]

+> ### Download and configure the quickstart app

+>

+> #### Step 1: Configure your application in Azure portal

+> For the code sample in this quickstart to work, create a client secret and add Graph API's **User.Read.All** application permission.

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the Python project

+>

+> > [!div class="sxs-lookup nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-python-daemon/archive/master.zip)

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Admin consent

+>

+> If you try to run the application at this point, you'll receive *HTTP 403 - Forbidden* error: `Insufficient privileges to complete the operation`. This error happens because any *app-only permission* requires Admin consent: a global administrator of your directory must give consent to your application. Select one of the options below depending on your role:

+>

+> ##### Global tenant administrator

+>

+> If you are a global administrator, go to **API Permissions** page select **Grant admin consent for Enter_the_Tenant_Name_Here**.

+> > [!div id="apipermissionspage"]

+> > [Go to the API Permissions page]()

+>

+> ##### Standard user

+>

+> If you're a standard user of your tenant, ask a global administrator to grant admin consent for your application. To do this, give the following URL to your administrator:

+>

+> ```url

+> https://login.microsoftonline.com/Enter_the_Tenant_Id_Here/adminconsent?client_id=Enter_the_Application_Id_Here

+> ```

+>

+>

+> #### Step 4: Run the application

+>

+> You'll need to install the dependencies of this sample once.

+>

+> ```console

+> pip install -r requirements.txt

+> ```

+>

+> Then, run the application via command prompt or console:

+>

+> ```console

+> python confidential_client_secret_sample.py parameters.json

+> ```

+>

+> You should see on the console output some Json fragment representing a list of users in your Azure AD directory.

+>

+> > [!IMPORTANT]

+> > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](https://github.com/Azure-Samples/ms-identity-python-daemon/blob/master/2-Call-MsGraph-WithCertificate/README.md) in the same GitHub repository for this sample, but in the second folder **2-Call-MsGraph-WithCertificate**.

+>

+> ## More information

+>

+> ### MSAL Python

+>

+> [MSAL Python](https://github.com/AzureAD/microsoft-authentication-library-for-python) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. As described, this quickstart requests tokens by using the application own identity instead of delegated permissions. The authentication flow used in this case is known as *[client credentials oauth flow](v2-oauth2-client-creds-grant-flow.md)*. For more information on how to use MSAL Python with daemon apps, see [this article](scenario-daemon-overview.md).

+>

+> You can install MSAL Python by running the following pip command.

+>

+> ```powershell

+> pip install msal

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```Python

+> import msal

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```Python

+> app = msal.ConfidentialClientApplication(

+> config["client_id"], authority=config["authority"],

+> client_credential=config["secret"])

+> ```

+>

+> > | Where: |Description |

+> > |||

+> > | `config["secret"]` | Is the client secret created for the application in Azure portal. |

+> > | `config["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. |

+> > | `config["authority"]` | The STS endpoint for user to authenticate. Usually `https://login.microsoftonline.com/{tenant}` for public cloud, where {tenant} is the name of your tenant or your tenant Id.|

+>

+> For more information, please see the [reference documentation for `ConfidentialClientApplication`](https://msal-python.readthedocs.io/en/latest/#confidentialclientapplication).

+>

+> ### Requesting tokens

+>

+> To request a token using app's identity, use `AcquireTokenForClient` method:

+>

+> ```Python

+> result = None

+> result = app.acquire_token_silent(config["scope"], account=None)

+>

+> if not result:

+> logging.info("No suitable token exists in cache. Let's get a new one from AAD.")

+> result = app.acquire_token_for_client(scopes=config["scope"])

+> ```

+>

+> > |Where:| Description |

+> > |||

+> > | `config["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.|

+>

+> For more information, please see the [reference documentation for `AcquireTokenForClient`](https://msal-python.readthedocs.io/en/latest/#msal.ConfidentialClientApplication.acquire_token_for_client).

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> To learn more about daemon applications, see the scenario landing page.

+>

+> > [!div class="nextstepaction"]

+> > [Daemon application that calls web APIs](scenario-daemon-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Python web app with user sign-in](web-app-quickstart.md?pivots=devlang-python)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Python web application can sign in users and get an access token to call the Microsoft Graph API. Users with a personal Microsoft Account or an account in any Azure Active Directory (Azure AD) organization can sign into the application.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+> ## Prerequisites

+>

+> - An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> - [Python 2.7+](https://www.python.org/downloads/release/python-2713) or [Python 3+](https://www.python.org/downloads/release/python-364/)

+> - [Flask](http://flask.pocoo.org/), [Flask-Session](https://pypi.org/project/Flask-Session/), [requests](https://requests.kennethreitz.org/en/master/)

+> - [MSAL Python](https://github.com/AzureAD/microsoft-authentication-library-for-python)

+>

+> #### Step 1: Configure your application in Azure portal

+>

+> For the code sample in this quickstart to work:

+>

+> 1. Add a reply URL as `http://localhost:5000/getAToken`.

+> 1. Create a Client Secret.

+> 1. Add Microsoft Graph API's User.ReadBasic.All delegated permission.

+>

+> > [!div class="nextstepaction"]

+> > [Make these changes for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with this attribute

+>

+> #### Step 2: Download your project

+>

+> Download the project and extract the zip file to a local folder closer to the root folder - for example, **C:\Azure-Samples**

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/ms-identity-python-webapp/archive/master.zip)

+>

+> > [!NOTE]

+> > `Enter_the_Supported_Account_Info_Here`

+>

+> #### Step 3: Run the code sample

+>

+> 1. You will need to install MSAL Python library, Flask framework, Flask-Sessions for server-side session management and requests using pip as follows:

+>

+> ```shell

+> pip install -r requirements.txt

+> ```

+>

+> 2. Run `app.py` from shell or command line:

+>

+> ```shell

+> python app.py

+> ```

+>

+> > [!IMPORTANT]

+> > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](./active-directory-certificate-credentials.md).

+>

+> ## More information

+>

+> ### How the sample works

+> 

+>

+> ### Getting MSAL

+> MSAL is the library used to sign in users and request tokens used to access an API protected by the Microsoft identity Platform.

+> You can add MSAL Python to your application using Pip.

+>

+> ```Shell

+> pip install msal

+> ```

+>

+> ### MSAL initialization

+> You can add the reference to MSAL Python by adding the following code to the top of the file where you will be using MSAL:

+>

+> ```Python

+> import msal

+> ```

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Learn more about web apps that sign in users in our multi-part scenario series.

+>

+> > [!div class="nextstepaction"]

+> > [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Universal Windows Platform (UWP) desktop app with user sign-in](desktop-app-quickstart.md?pivots=devlang-uwp)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Universal Windows Platform (UWP) application can sign in users and get an access token to call the Microsoft Graph API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+>

+> ## Prerequisites

+>

+> * An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+> * [Visual Studio 2019](https://visualstudio.microsoft.com/vs/)

+>

+> #### Step 1: Configure the application

+> For the code sample in this quickstart to work, add a **Redirect URI** of `https://login.microsoftonline.com/common/oauth2/nativeclient`.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download the Visual Studio project

+>

+> Run the project using Visual Studio 2019.

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/active-directory-dotnet-native-uwp-v2/archive/msal3x.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+>

+> #### Step 3: Your app is configured and ready to run

+> We have configured your project with values of your app's properties and it's ready to run.

+> #### Step 4: Run the application

+>

+> To run the sample application on your local machine:

+>

+> 1. In the Visual Studio toolbar, choose the right platform (probably **x64** or **x86**, not ARM). The target device should change from *Device* to *Local Machine*.

+> 1. Select **Debug** > **Start Without Debugging**.

+>

+> If you're prompted to do so, you might first need to enable **Developer Mode**, and then **Start Without Debugging** again to launch the app.

+>

+> When the app's window appears, you can select the **Call Microsoft Graph API** button, enter your credentials, and consent to the permissions requested by the application. If successful, the application displays some token information and data obtained from the call to the Microsoft Graph API.

+>

+> ## How the sample works

+>

+> 

+>

+> ### MSAL.NET

+>

+> MSAL ([Microsoft.Identity.Client](https://www.nuget.org/packages/Microsoft.Identity.Client)) is the library used to sign in users and request security tokens. The security tokens are used to access an API protected by the Microsoft Identity platform. You can install MSAL by running the following command in Visual Studio's *Package Manager Console*:

+>

+> ```powershell

+> Install-Package Microsoft.Identity.Client

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```csharp

+> using Microsoft.Identity.Client;

+> ```

+>

+> Then, MSAL is initialized using the following code:

+>

+> ```csharp

+> public static IPublicClientApplication PublicClientApp;

+> PublicClientApp = PublicClientApplicationBuilder.Create(ClientId)

+> .WithRedirectUri("https://login.microsoftonline.com/common/oauth2/> nativeclient")

+> .Build();

+> ```

+>

+> The value of `ClientId` is the **Application (client) ID** of the app you registered in the Azure portal. You can find this value in the app's **Overview** page in the Azure portal.

+>

+> ### Requesting tokens

+>

+> MSAL has two methods for acquiring tokens in a UWP app: `AcquireTokenInteractive` and `AcquireTokenSilent`.

+>

+> #### Get a user token interactively

+>

+> Some situations require forcing users to interact with the Microsoft identity platform through a pop-up window to either validate their credentials or to give consent. Some examples include:

+>

+> - The first-time users sign in to the application

+> - When users may need to reenter their credentials because the password has expired

+> - When your application is requesting access to a resource, that the user needs to consent to

+> - When two factor authentication is required

+>

+> ```csharp

+> authResult = await App.PublicClientApp.AcquireTokenInteractive(scopes)

+> .ExecuteAsync();

+> ```

+>

+> The `scopes` parameter contains the scopes being requested, such as `{ "user.read" }` for Microsoft Graph or `{ "api://<Application ID>/access_as_user" }` for custom web APIs.

+>

+> #### Get a user token silently

+>

+> Use the `AcquireTokenSilent` method to obtain tokens to access protected resources after the initial `AcquireTokenInteractive` method. You donΓÇÖt want to require the user to validate their credentials every time they need to access a resource. Most of the time you want token acquisitions and renewal without any user interaction

+>

+> ```csharp

+> var accounts = await App.PublicClientApp.GetAccountsAsync();

+> var firstAccount = accounts.FirstOrDefault();

+> authResult = await App.PublicClientApp.AcquireTokenSilent(scopes, firstAccount)

+> .ExecuteAsync();

+> ```

+>

+> * `scopes` contains the scopes being requested, such as `{ "user.read" }` for Microsoft Graph or `{ "api://<Application ID>/access_as_user" }` for custom web APIs.

+> * `firstAccount` specifies the first user account in the cache (MSAL supports multiple users in a single app).

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Try out the Windows desktop tutorial for a complete step-by-step guide on building applications and new features, including a full explanation of this quickstart.

+>

+> > [!div class="nextstepaction"]

+> > [UWP - Call Graph API tutorial](tutorial-v2-windows-uwp.md)

+> [!div renderon="docs"]

+> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:

+>

+> > [Quickstart: Windows Presentation Foundation (WPF) desktop app that signs in users and calls a web API](desktop-app-quickstart.md?pivots=devlang-windows-desktop)

+>

+> We apologize for the inconvenience and appreciate your patience while we work to get this resolved.

+> [!div renderon="portal" class="sxs-lookup"]

+> In this quickstart, you download and run a code sample that demonstrates how a Windows Presentation Foundation (WPF) application can sign in users and get an access token to call the Microsoft Graph API.

+>

+> See [How the sample works](#how-the-sample-works) for an illustration.

+>

+>

+> #### Step 1: Configure your application in Azure portal

+> For the code sample in this quickstart to work, add a **Redirect URI** of `https://login.microsoftonline.com/common/oauth2/nativeclient` and `ms-appx-web://microsoft.aad.brokerplugin/{client_id}`.

+> > [!div class="nextstepaction"]

+> > [Make this change for me]()

+>

+> > [!div class="alert alert-info"]

+> >  Your application is configured with these attributes.

+>

+> #### Step 2: Download your Visual Studio project

+>

+> Run the project using Visual Studio 2019.

+> > [!div class="nextstepaction"]

+> > [Download the code sample](https://github.com/Azure-Samples/active-directory-dotnet-desktop-msgraph-v2/archive/msal3x.zip)

+>

+> [!INCLUDE [active-directory-develop-path-length-tip](../../../includes/active-directory-develop-path-length-tip.md)]

+>

+> #### Step 3: Your app is configured and ready to run

+> We have configured your project with values of your app's properties and it's ready to run.

+>

+> > [!div class="sxs-lookup"]

+> > > [!NOTE]

+> > > `Enter_the_Supported_Account_Info_Here`

+>

+> ## More information

+>

+> ### How the sample works

+> 

+>

+> ### MSAL.NET

+> MSAL ([Microsoft.Identity.Client](https://www.nuget.org/packages/Microsoft.Identity.Client)) is the library used to sign in users and request tokens used to access an API protected by Microsoft identity platform. You can install MSAL by running the following command in Visual Studio's **Package Manager Console**:

+>

+> ```powershell

+> Install-Package Microsoft.Identity.Client -IncludePrerelease

+> ```

+>

+> ### MSAL initialization

+>

+> You can add the reference for MSAL by adding the following code:

+>

+> ```csharp

+> using Microsoft.Identity.Client;

+> ```

+>

+> Then, initialize MSAL using the following code:

+>

+> ```csharp

+> IPublicClientApplication publicClientApp = PublicClientApplicationBuilder.Create(ClientId)

+> .WithRedirectUri("https://login.microsoftonline.com/common/oauth2/nativeclient")

+> .WithAuthority(AzureCloudInstance.AzurePublic, Tenant)

+> .Build();

+> ```

+>

+> |Where: | Description |

+> |||

+> | `ClientId` | 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. |

+>

+> ### Requesting tokens

+>

+> MSAL has two methods for acquiring tokens: `AcquireTokenInteractive` and `AcquireTokenSilent`.

+>

+> #### Get a user token interactively

+>

+> Some situations require forcing users interact with the Microsoft identity platform through a pop-up window to either validate their credentials or to give consent. Some examples include:

+>

+> - The first time users sign in to the application

+> - When users may need to reenter their credentials because the password has expired

+> - When your application is requesting access to a resource that the user needs to consent to

+> - When two factor authentication is required

+>

+> ```csharp

+> authResult = await App.PublicClientApp.AcquireTokenInteractive(_scopes)

+> .ExecuteAsync();

+> ```

+>

+> |Where:| Description |

+> |||

+> | `_scopes` | Contains the scopes being requested, such as `{ "user.read" }` for Microsoft Graph or `{ "api://<Application ID>/access_as_user" }` for custom web APIs. |

+>

+> #### Get a user token silently

+>

+> You don't want to require the user to validate their credentials every time they need to access a resource. Most of the time you want token acquisitions and renewal without any user interaction. You can use the `AcquireTokenSilent` method to obtain tokens to access protected resources after the initial `AcquireTokenInteractive` method:

+>

+> ```csharp

+> var accounts = await App.PublicClientApp.GetAccountsAsync();

+> var firstAccount = accounts.FirstOrDefault();

+> authResult = await App.PublicClientApp.AcquireTokenSilent(scopes, firstAccount)

+> .ExecuteAsync();

+> ```

+>

+> |Where: | Description |

+> |||

+> | `scopes` | Contains the scopes being requested, such as `{ "user.read" }` for Microsoft Graph or `{ "api://<Application ID>/access_as_user" }` for custom web APIs. |

+> | `firstAccount` | Specifies the first user in the cache (MSAL support multiple users in a single app). |

+>

+> [!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]

+>

+> ## Next steps

+>

+> Try out the Windows desktop tutorial for a complete step-by-step guide on building applications and new features, including a full explanation of this quickstart.

+>

+> > [!div class="nextstepaction"]

+> > [Call Graph API tutorial](./tutorial-v2-windows-desktop.md)

+| AADSTS500212 | NotAllowedByOutboundPolicyTenant - The user's administrator has set an outbound access policy that does not allow access to the resource tenant. |

+| AADSTS500213 | NotAllowedByInboundPolicyTenant - The resource tenant's cross-tenant access policy does not allow this user to access this tenant. |

+This article describes how to program directly against the protocol in your application using any language. When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows). For more information, look at [sample apps that use MSAL](sample-v2-code.md).

+The OAuth 2.0 authorization code flow is described in [section 4.1 of the OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749). With OIDC, this flow does authentication and authorization for most app types. These types include [single page apps](v2-app-types.md#single-page-apps-javascript), [web apps](v2-app-types.md#web-apps), and [natively installed apps](v2-app-types.md#mobile-and-native-apps). The flow enables apps to securely acquire an `access_token` that can be used to access resources secured by the Microsoft identity platform. Apps can refresh tokens to get other access tokens and ID tokens for the signed in user.

+This diagram provides a high-level overview of the authentication flow for an application:

+

+The authorization code flow for single page applications requires additional setup. Follow the instructions for [creating your single-page application](scenario-spa-app-registration.md#redirect-uri-msaljs-20-with-auth-code-flow) to correctly mark your redirect URI as enabled for Cross-Origin Resource Sharing (CORS). To update an existing redirect URI to enable CORS, open the manifest editor and set the `type` field for your redirect URI to `spa` in the `replyUrlsWithType` section. Or, you can select the redirect URI in **Authentication** > **Web** and select URIs to migrate to using the authorization code flow.

+If you attempt to use the authorization code flow without setting up CORS for your redirect URI, you will see this error in the console:

+```http

+access to XMLHttpRequest at 'https://login.microsoftonline.com/common/v2.0/oauth2/token' from origin 'yourApp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

+```

+If so, visit your app registration and update the redirect URI for your app to use the `spa` type.

+Applications can't use a `spa` redirect URI with non-SPA flows, for example, native applications or client credential flows. To ensure security and best practices, the Microsoft identity platform returns an error if you attempt to use a `spa` redirect URI without an `Origin` header. Similarly, the Microsoft identity platform also prevents the use of client credentials in all flows in the presence of an `Origin` header, to ensure that secrets aren't used from within the browser.

+The authorization code flow begins with the client directing the user to the `/authorize` endpoint. In this request, the client requests the `openid`, `offline_access`, and `https://graph.microsoft.com/mail.read` permissions from the user.

+Some permissions are admin-restricted, for example, writing data to an organization's directory by using `Directory.ReadWrite.All`. If your application requests access to one of these permissions from an organizational user, the user receives an error message that says they're not authorized to consent to your app's permissions. To request access to admin-restricted scopes, you should request them directly from a Global Administrator. For more information, see [Admin-restricted permissions](v2-permissions-and-consent.md#admin-restricted-permissions).

+```http

+> Select the link below to execute this request! After signing in, your browser should be redirected to `http://localhost/myapp/` with a `code` in the address bar.

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For guest scenarios where you sign a user from one tenant into another tenant, you *must* provide the tenant identifier to sign them into the resource tenant. For more information, see [Endpoints](active-directory-v2-protocols.md#endpoints). |

+| `client_id` | required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience assigned to your app. |

+| `response_type` | required | Must include `code` for the authorization code flow. Can also include `id_token` or `token` if using the [hybrid flow](#request-an-id-token-as-well-or-hybrid-flow). |

+| `redirect_uri` | required | 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. For native and mobile apps, use one of the recommended values: `https://login.microsoftonline.com/common/oauth2/nativeclient` for apps using embedded browsers or `http://localhost` for apps that use system browsers. |

+| `scope` | required | A space-separated list of [scopes](v2-permissions-and-consent.md) that you want the user to consent to. For the `/authorize` leg of the request, this parameter can cover multiple resources. This value allows your app to get consent for multiple web APIs you want to call. |

+| `response_mode` | recommended | Specifies the method that should be used to send the resulting token back to your app. It can be one of the following values:<br/><br/>- `query`<br/>- `fragment`<br/>- `form_post`<br/><br/>`query` provides the code as a query string parameter on your redirect URI. If you're requesting an ID token using the implicit flow, you can't use `query` as specified in the [OpenID spec](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations). If you're requesting just the code, you can use `query`, `fragment`, or `form_post`. `form_post` executes a POST containing the code to your redirect URI. |

+| `state` | recommended | A value included in the request that is also returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for [preventing cross-site request forgery attacks](https://tools.ietf.org/html/rfc6749#section-10.12). The value can also encode information about the user's state in the app before the authentication request occurred. For instance, it could encode the page or view they were on. |

+| `prompt` | optional | Indicates the type of user interaction that is required. Valid values are `login`, `none`, `consent`, and `select_account`.<br/><br/>- `prompt=login` forces the user to enter their credentials on that request, negating single-sign on.<br/>- `prompt=none` is the opposite. It ensures that the user isn't presented with any interactive prompt. If the request can't be completed silently by using single-sign on, the Microsoft identity platform returns an `interaction_required` error.<br/>- `prompt=consent` triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.<br/>- `prompt=select_account` interrupts single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.<br/> |

+| `login_hint` | optional | You can use this parameter to pre-fill the username and email address field of the sign-in page for the user. Apps can use this parameter during reauthentication, after already extracting the `login_hint` [optional claim](active-directory-optional-claims.md) from an earlier sign-in. |

+| `domain_hint` | optional | If included, the app skips the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. For example, sending them to their federated identity provider. Apps can use this parameter during reauthentication, by extracting the `tid` from a previous sign-in. |

+| `code_challenge` | recommended / required | Used to secure authorization code grants by using Proof Key for Code Exchange (PKCE). Required if `code_challenge_method` is included. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). This parameter is now recommended for all application types, both public and confidential clients, and required by the Microsoft identity platform for [single page apps using the authorization code flow](reference-third-party-cookies-spas.md). |

+| `code_challenge_method` | recommended / required | The method used to encode the `code_verifier` for the `code_challenge` parameter. This *SHOULD* be `S256`, but the spec allows the use of `plain` if the client can't support SHA256. <br/><br/>If excluded, `code_challenge` is assumed to be plaintext if `code_challenge` is included. The Microsoft identity platform supports both `plain` and `S256`. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). This parameter is required for [single page apps using the authorization code flow](reference-third-party-cookies-spas.md).|

+At this point, the user is asked to enter their credentials and complete the authentication. The Microsoft identity platform also ensures that the user has consented to the permissions indicated in the `scope` query parameter. If the user hasn't consented to any of those permissions, it asks the user to consent to the required permissions. For more information, see [Permissions and consent in the Microsoft identity platform](v2-permissions-and-consent.md).

+Once the user authenticates and grants consent, the Microsoft identity platform returns a response to your app at the indicated `redirect_uri`, using the method specified in the `response_mode` parameter.

+This example shows a successful response using `response_mode=query`:

+| `code` | The `authorization_code` that the app requested. The app can use the authorization code to request an access token for the target resource. Authorization codes are short lived. Typically, they expire after about 10 minutes. |

+| `state` | If a `state` parameter is included in the request, the same value should appear in the response. The app should verify that the state values in the request and response are identical. |

+You can also receive an ID token if you request one and have the implicit grant enabled in your application registration. This behavior is sometimes referred to as the [*hybrid flow*](#request-an-id-token-as-well-or-hybrid-flow). It's used by frameworks like ASP.NET.

+| `error` | An error code string that can be used to classify types of errors, and to react to errors. This part of the error is provided so that the app can react appropriately to the error, but does not explain in depth why an error occurred. |

+| `error_description` | A specific error message that can help a developer identify the cause of an authentication error. This part of the error contains most of the useful information about _why_ the error occurred. |

+| `invalid_request` | Protocol error, such as a missing required parameter. | Fix and resubmit the request. This error is a development error typically caught during initial testing. |

+| `access_denied` | Resource owner denied consent | The client application can notify the user that it can't continue unless the user consents. |

+| `unsupported_response_type` | The authorization server doesn't support the response type in the request. | Fix and resubmit the request. This error is a development error typically caught during initial testing. In the [hybrid flow](#request-an-id-token-as-well-or-hybrid-flow), this error signals that you must enable the ID token implicit grant setting on the client app registration. |

+| `server_error` | The server encountered an unexpected error.| Retry the request. These errors can result from temporary conditions. The client application might explain to the user that its response is delayed to a temporary error. |

+| `invalid_resource` | The target resource is invalid because it does not exist, Azure AD can't find it, or it's not correctly configured. | This error indicates the resource, if it exists, hasn't been configured in the tenant. The application can prompt the user with instruction for installing the application and adding it to Azure AD. |

+| `login_required` | Too many or no users found. | The client requested silent authentication (`prompt=none`), but a single user couldn't be found. This error may mean there are multiple users active in the session, or no users. This error takes into account the tenant chosen. For example, if there are two Azure AD accounts active and one Microsoft account, and `consumers` is chosen, silent authentication works. |

+| `interaction_required` | The request requires user interaction. | Another authentication step or consent is required. Retry the request without `prompt=none`. |

+### Request an ID token as well or hybrid flow

+To learn who the user is before redeeming an authorization code, it's common for applications to also request an ID token when they request the authorization code. This approach is called the *hybrid flow* because it mixes the implicit grant with the authorization code flow.

+The hybrid flow is commonly used in web apps to render a page for a user without blocking on code redemption, notably in [ASP.NET](quickstart-v2-aspnet-core-webapp.md). Both single-page apps and traditional web apps benefit from reduced latency in this model.

+The hybrid flow is the same as the authorization code flow described earlier but with three additions. All of these additions are required to request an ID token: new scopes, a new response_type, and a new `nonce` query parameter.

+```http

+|`response_type`| required | The addition of `id_token` indicates to the server that the application would like an ID token in the response from the `/authorize` endpoint. |

+|`scope`| required | For ID tokens, this parameter must be updated to include the ID token scopes: `openid` and optionally `profile` and `email`. |

+|`nonce`| required| A value included in the request, generated by the app, that is 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. |

+|`response_mode`| recommended | Specifies the method that should be used to send the resulting token back to your app. Default value is `query` for just an authorization code, but `fragment` if the request includes an `id_token` `response_type`. We recommend apps use `form_post`, especially when using `http://localhost` as a redirect URI. |

+The use of `fragment` as a response mode causes issues for web apps that read the code from the redirect. Browsers don't pass the fragment to the web server. In these situations, apps should use the `form_post` response mode to ensure that all data is sent to the server.

+This example shows a successful response using `response_mode=fragment`:

+```http

+| `id_token` | An ID token for the user, issued by using the *implicit grant*. Contains a special `c_hash` claim that is the hash of the `code` in the same request. |

+| `state` | If a `state` parameter is included in the request, the same value should appear in the response. The app should verify that the state values in the request and response are identical. |

+All confidential clients have a choice of using client secrets or certificate credentials. Symmetric shared secrets are generated by the Microsoft identity platform. Certificate credentials are asymmetric keys uploaded by the developer. For more information, see [Microsoft identity platform application authentication certificate credentials](active-directory-certificate-credentials.md).

+For best security, we recommend using certificate credentials. Public clients, which include native applications and single page apps, must not use secrets or certificates when redeeming an authorization code. Always ensure that your redirect URIs include the type of application and [are unique](reply-url.md#localhost-exceptions).

+Now that you've acquired an `authorization_code` and have been granted permission by the user, you can redeem the `code` for an `access_token` to the resource. Redeem the `code` by sending a `POST` request to the `/token` endpoint:

+```http

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more information, see [Endpoints](active-directory-v2-protocols.md#endpoints). |

+| `client_id` | required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) page assigned to your app. |

+| `scope` | optional | A space-separated list of scopes. The scopes must all be from a single resource, along with OIDC scopes (`profile`, `openid`, `email`). For more information, see [Permissions and consent in the Microsoft identity platform](v2-permissions-and-consent.md). This parameter is a Microsoft extension to the authorization code flow, intended to allow apps to declare the resource they want the token for during token redemption.|

+| `code` | required | The `authorization_code` that you acquired in the first leg of the flow. |

+| `redirect_uri` | required | The same `redirect_uri` value that was used to acquire the `authorization_code`. |

+| `grant_type` | required | Must be `authorization_code` for the authorization code flow. |

+| `code_verifier` | recommended | The same `code_verifier` that was used to obtain the authorization_code. Required if PKCE was used in the authorization code grant request. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). |

+| `client_secret` | required for confidential web apps | The application secret that you created in the app registration portal for your app. Don't use the application secret in a native app or single page app because a `client_secret` can't be reliably stored on devices or web pages. It's required for web apps and web APIs, which can store the `client_secret` securely on the server side. Like all parameters here, the client secret must be URL-encoded before being sent. This step is usually done by the SDK. For more information on URI encoding, see the [URI Generic Syntax specification](https://tools.ietf.org/html/rfc3986#page-12). The Basic auth pattern of instead providing credentials in the Authorization header, per [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1) is also supported. |

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more detail, see [Endpoints](active-directory-v2-protocols.md#endpoints). |

+| `client_id` | required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) page assigned to your app. |

+| `scope` | optional | A space-separated list of scopes. The scopes must all be from a single resource, along with OIDC scopes (`profile`, `openid`, `email`). For more information, see [permissions, consent, and scopes](v2-permissions-and-consent.md). This parameter is a Microsoft extension to the authorization code flow. This extension allows apps to declare the resource they want the token for during token redemption.|

+| `code` | required | The `authorization_code` that you acquired in the first leg of the flow. |

+| `redirect_uri` | required | The same `redirect_uri` value that was used to acquire the `authorization_code`. |

+| `code_verifier` | recommended | The same `code_verifier` that was used to obtain the `authorization_code`. Required if PKCE was used in the authorization code grant request. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). |

+| `client_assertion_type` | required for confidential web apps | The value must be set to `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` to use a certificate credential. |

+| `client_assertion` | required for confidential web apps | An assertion, which is a JSON web token (JWT), that you need to create and sign with the certificate you registered as credentials for your application. Read about [certificate credentials](active-directory-certificate-credentials.md) to learn how to register your certificate and the format of the assertion.|

+The parameters are same as the request by shared secret except that the `client_secret` parameter is replaced by two parameters: a `client_assertion_type` and `client_assertion`.

+This example shows a successful token response:

+| `token_type` | Indicates the token type value. The only type that Azure AD supports is `Bearer`. |

+| `expires_in` | How long the access token is valid, in seconds. |

+| `scope` | The scopes that the `access_token` is valid for. Optional. This parameter is non-standard and, if omitted, the token is for the scopes requested on the initial leg of the flow. |

+| `refresh_token` | An OAuth 2.0 refresh token. The app can use this token to acquire other access tokens after the current access token expires. Refresh tokens are long-lived. They can maintain access to resources for extended periods. For more detail on refreshing an access token, refer to [Refresh the access token](#refresh-the-access-token) later in this article.<br> **Note:** Only provided if `offline_access` scope was requested. |

+| `id_token` | A JSON Web Token. 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, and confidential clients can use this token for authorization. For more information about id_tokens, see the [`id_token reference`](id-tokens.md). <br> **Note:** Only provided if `openid` scope was requested. |

+This example is an Error response:

+| `error` | An error code string that can be used to classify types of errors, and to react to errors. |

+| `error_description` | A specific error message that can help a developer identify the cause of an authentication error. |

+| `invalid_request` | Protocol error, such as a missing required parameter. | Fix the request or app registration and resubmit the request. |

+| `invalid_grant` | The authorization code or PKCE code verifier is invalid or has expired. | Try a new request to the `/authorize` endpoint and verify that the `code_verifier` parameter was correct. |

+| `unauthorized_client` | The authenticated client isn't authorized to use this authorization grant type. | This error usually occurs when the client application isn't registered in Azure AD or isn't added to the user's Azure AD tenant. The application can prompt the user with instruction for installing the application and adding it to Azure AD. |

+| `unsupported_grant_type` | The authorization server doesn't support the authorization grant type. | Change the grant type in the request. This type of error should occur only during development and be detected during initial testing. |

+| `invalid_resource` | The target resource is invalid because it doesn't exist, Azure AD can't find it, or it's not correctly configured. | This code indicates the resource, if it exists, hasn't been configured in the tenant. The application can prompt the user with instruction for installing the application and adding it to Azure AD. |

+| `interaction_required` | Non-standard, as the OIDC specification calls for this code only on the `/authorize` endpoint. The request requires user interaction. For example, another authentication step is required. | Retry the `/authorize` request with the same scopes. |

+|`consent_required` | The request requires user consent. This error is non-standard. It's usually only returned on the `/authorize` endpoint per OIDC specifications. Returned when a `scope` parameter was used on the code redemption flow that the client app doesn't have permission to request. | The client should send the user back to the `/authorize` endpoint with the correct scope to trigger consent. |

+|`invalid_scope` | The scope requested by the app is invalid. | Update the value of the `scope` parameter in the authentication request to a valid value. |

+> Single page apps may receive an `invalid_request` error indicating that cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. This indicates that the redirect URI used to request the token has not been marked as a `spa` redirect URI. Review the [application registration steps](#redirect-uri-setup-required-for-single-page-apps) on how to enable this flow.

+```http

+Access tokens are short lived. Refresh them after they expire to continue accessing resources. You can do so by submitting another `POST` request to the `/token` endpoint. Provide the `refresh_token` instead of the `code`. Refresh tokens are valid for all permissions that your client has already received consent for. For example, a refresh token issued on a request for `scope=mail.read` can be used to request a new access token for `scope=api://contoso.com/api/UseResource`.

+Refresh tokens for web apps and native apps don't have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the action. Your application needs to expect and handle [errors returned by the token issuance endpoint](#error-codes-for-token-endpoint-errors). Single page apps get a token with a 24-hour lifetime, requiring a new authentication every day. This action can be done silently in an iframe when third-party cookies are enabled. It must be done in a top-level frame, either full page navigation or a pop-up window, in browsers without third-party cookies, such as Safari.

+Refresh tokens aren't revoked when used to acquire new access tokens. You're expected to discard the old refresh token. The [OAuth 2.0 spec](https://tools.ietf.org/html/rfc6749#section-6) says: "The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client."

+> For refresh tokens sent to a redirect URI registered as `spa`, the refresh token expires after 24 hours. Additional refresh tokens acquired using the initial refresh token carries over that expiration time, so apps must be prepared to re-run the authorization code flow using an interactive authentication to get a new refresh token every 24 hours. Users do not have to enter their credentials, and usually don't even see any user experience, just a reload of your application. The browser must visit the login page in a top level frame in order to see the login session. This is due to [privacy features in browsers that block third party cookies](reference-third-party-cookies-spas.md).

+```http

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more information, see [Endpoints](active-directory-v2-protocols.md#endpoints). |

+| `scope` | optional | A space-separated list of scopes. The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the original `authorization_code` request leg. If the scopes specified in this request span multiple resource server, then the Microsoft identity platform returns a token for the resource specified in the first scope. For more information, see [Permissions and consent in the Microsoft identity platform](v2-permissions-and-consent.md). |

+| `refresh_token` | required | The `refresh_token` that you acquired in the second leg of the flow. |

+| `client_secret` | required for web apps | The application secret that you created in the app registration portal for your app. It shouldn't be used in a native app, because a `client_secret` can't be reliably stored on devices. It's required for web apps and web APIs, which can store the `client_secret` securely on the server side. This secret needs to be URL-Encoded. For more information, see the [URI Generic Syntax specification](https://tools.ietf.org/html/rfc3986#page-12). |

+This example shows a successful token response:

+| `access_token` | The requested access token. The app can use this token to authenticate to the secured resource, such as a web API. |

+| `token_type` | Indicates the token type value. The only type that Azure AD supports is Bearer. |

+| `expires_in` | How long the access token is valid, in seconds. |

+| `scope` | The scopes that the `access_token` is valid for. |

+| `refresh_token` | A new OAuth 2.0 refresh token. Replace the old refresh token with this newly acquired refresh token to ensure your refresh tokens remain valid for as long as possible. <br> **Note:** Only provided if `offline_access` scope was requested.|

+| `id_token` | An unsigned JSON Web Token. 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_token`, see the [Microsoft identity platform ID tokens](id-tokens.md). <br> **Note:** Only provided if `openid` scope was requested. |

+| `error` | An error code string that can be used to classify types of errors, and to react to errors. |

+## Next steps

+- Go over the [MSAL JS samples](sample-v2-code.md) to get started coding.

+- Learn about [token exchange scenarios](scenario-token-exchange-saml-oauth.md).

+Review the [UserInfo documentation](userinfo.md#calling-the-api) to look over how to call the UserInfo endpoint with this token.

+2. The administrator in the host organization [sets up policies](external-collaboration-settings-configure.md) that allow Sam to identify and add other users from the partner organization (Litware). (Sam must be added to the **Guest inviter** role.)

+- [Delegate invitations for Azure Active Directory B2B collaboration](external-collaboration-settings-configure.md)

+Make sure your organization's external collaboration settings are configured such that you're allowed to invite guests. By default, all users and admins can invite guests. But your organization's external collaboration policies might be configured to prevent certain types of users or admins from inviting guests. To find out how to view and set these policies, see [Enable B2B external collaboration and manage who can invite guests](external-collaboration-settings-configure.md).

+- The number of domains you can add to an allow list or deny list is limited only by the size of the policy. This limit applies to the number of characters, so you can have a greater number of shorter domains or fewer longer domains. The maximum size of the entire policy is 25 KB (25,000 characters), which includes the allow list or deny list and any other parameters configured for other features.

+6. When you're done, select **Save**.

+This is a more restrictive configuration, where you can set specific domains in the allow list and restrict invitations to any other organizations or domains that aren't mentioned.

+6. When you're done, select **Save**.

+### Switch from allow list to deny list and vice versa

+- For information about Conditional Access and B2B collaboration, see [Conditional Access for B2B collaboration users](authentication-conditional-access.md).

+ Title: Authentication and Conditional Access for B2B users - Azure AD

+description: Learn how to enforce multi-factor authentication policies for Azure Active Directory B2B users.

+# Authentication and Conditional Access for External Identities

+When an external user accesses resources in your organization, the authentication flow is determined by the user's identity provider (an external Azure AD tenant, social identity provider, etc.), Conditional Access policies, and the [cross-tenant access settings](cross-tenant-access-overview.md) configured both in the user's home tenant and the tenant hosting resources.

+This article describes the authentication flow for external users who are accessing resources in your organization. Organizations can enforce multiple Conditional Access policies for their external users, which can be enforced at the tenant, app, or individual user level in the same way that they're enabled for full-time employees and members of the organization.

+## Authentication flow for external Azure AD users

+The following diagram illustrates the authentication flow when an Azure AD organization shares resources with users from other Azure AD organizations. This diagram shows how cross-tenant access settings work with Conditional Access policies, such as multi-factor authentication (MFA), to determine if the user can access resources.

+

+|Step |Description |

+|||

+|**1** | A user from Fabrikam (the userΓÇÖs *home tenant*) initiates sign-in to a resource in Contoso (the *resource tenant*). |

+|**2** | During sign-in, the Azure AD security token service (STS) evaluates Contoso's Conditional Access policies. It also checks whether the Fabrikam user is allowed access by evaluating cross-tenant access settings (FabrikamΓÇÖs outbound settings and ContosoΓÇÖs inbound settings). |

+|**3** | Azure AD checks ContosoΓÇÖs inbound trust settings to see if Contoso trusts MFA and device claims (device compliance, hybrid Azure AD joined status) from Fabrikam. If not, skip to step 6. |

+|**4** | If Contoso trusts MFA and device claims from Fabrikam, Azure AD checks the userΓÇÖs credentials for an indication the user has completed MFA. If Contoso trusts device information from Fabrikam, Azure AD uses the device ID to look up the device object in Fabrikam to determine its state (compliant or hybrid Azure AD joined). |

+|**5** | If MFA is required but not completed or if a device ID isn't provided, Azure AD issues MFA and device challenges in the user's home tenant as needed. When MFA and device requirements are satisfied in Fabrikam, the user is allowed access to the resource in Contoso. If the checks canΓÇÖt be satisfied, access is blocked. |

+|**6** | When no trust settings are configured and MFA is required, B2B collaboration users are prompted for MFA, which they need to satisfy in the resource tenant. If device compliance is required, access is blocked. |

+For more information, see the [Conditional Access for external users](#conditional-access-for-external-users) section.

+## Authentication flow for non-Azure AD external users

+When an Azure AD organization shares resources with external users with an identity provider other than Azure AD, the authentication flow depends on whether the user is authenticating with an identity provider or with email one-time passcode authentication. In either case, the resource tenant identifies which authentication method to use, and then either redirects the user to their identity provider or issues a one-time passcode.

+### Example 1: Authentication flow and token for a non-Azure AD external user

+The following diagram illustrates the authentication flow when an external user signs in with an account from a non-Azure AD identity provider, such as Google, Facebook, or a federated SAML/WS-Fed identity provider.

+

+| Step | Description |

+|--|--|

+| **1** | The B2B guest user requests access to a resource. The resource redirects the user to its resource tenant, a trusted IdP.|

+| **2** | The resource tenant identifies the user as external and redirects the user to the B2B guest userΓÇÖs IdP. The user performs primary authentication in the IdP.

+| **3** | Outbound cross-tenant access settings are evaluated. If the user is allowed outbound access, the B2B guest userΓÇÖs IdP issues a token to the user. The user is redirected back to the resource tenant with the token. The resource tenant validates the token and then evaluates the user against its Conditional Access policies. For example, the resource tenant could require the user to perform Azure Active Directory (AD) MFA.

+| **4** | Inbound cross-tenant access settings and Conditional Access policies are evaluated. If all policies are satisfied, the resource tenant issues its own token and redirects the user to its resource.

+### Example 2: Authentication flow and token for one-time passcode user

+The following diagram illustrates the flow when email one-time passcode authentication is enabled and the external user isn't authenticated through other means, such as Azure AD, Microsoft account (MSA), or social identity provider.

+

+| Step | Description |

+|--|--|

+| **1** |The user requests access to a resource in another tenant. The resource redirects the user to its resource tenant, a trusted IdP.|

+| **2** | The resource tenant identifies the user as an [external email one-time passcode (OTP) user](./one-time-passcode.md) and sends an email with the OTP to the user.|

+| **3** | The user retrieves the OTP and submits the code. The resource tenant evaluates the user against its Conditional Access policies.

+| **4** | Once all Conditional Access policies are satisfied, the resource tenant issues a token and redirects the user to its resource. |

+## Conditional Access for external users

+Organizations can enforce Conditional Access policies for external B2B collaboration users in the same way that they're enabled for full-time employees and members of the organization. This section describes important considerations for applying Conditional Access to users outside of your organization.

+### Azure AD cross-tenant trust settings for MFA and device claims

+In an Azure AD cross-tenant scenario, the resource organization can create Conditional Access policies that require MFA or device compliance for all guest and external users. Generally, an external user accessing a resource is required to set up their Azure AD MFA with the resource tenant. However, Azure AD now offers the capability to trust MFA, compliant device claims, and [hybrid Azure AD joined device](../conditional-access/howto-conditional-access-policy-compliant-device.md) claims from external Azure AD organizations, making for a more streamlined sign-in experience for the external user. As the resource tenant, you can use cross-tenant access settings to trust the MFA and device claims from external Azure AD tenants. Trust settings can apply to all Azure AD organizations, or just selected Azure AD organizations.

+When trust settings are enabled, Azure AD will check a user's credentials during authentication for an MFA claim or a device ID to determine if the policies have already been met in their home tenant. If so, the external user will be granted seamless sign-on to your shared resource. Otherwise, an MFA or device challenge will be initiated in the user's home tenant. If trust settings aren't enabled, or if the user's credentials don't contain the required claims, the external user will be presented with an MFA or device challenge.

+For details, see [Configuring cross-tenant access settings for B2B collaboration](cross-tenant-access-settings-b2b-collaboration.md). If no trust settings are configured, the flow is the same as the [MFA flow for non-Azure AD external users](#mfa-for-non-azure-ad-external-users).

+### MFA for non-Azure AD external users

+For non-Azure AD external users, the resource tenant is always responsible for MFA. The following is an example of a typical MFA flow. This scenario works for any identity, including a Microsoft Account (MSA) or social ID. This flow also applies for Azure AD external users when you haven't configured trust settings with their home Azure AD organization.

+1. An admin or information worker in a company named Fabrikam invites a user from another company named Contoso to use Fabrikam's app.

+2. Fabrikam's app is configured to require Azure AD MFA upon access.

+3. When the B2B collaboration user from Contoso attempts to access Fabrikam's app, they're asked to complete the Azure AD MFA challenge.

+4. The guest user can then set up their Azure AD MFA with Fabrikam and select the options.

+Fabrikam must have sufficient premium Azure AD licenses that support Azure AD MFA. The user from Contoso then consumes this license from Fabrikam. See [billing model for Azure AD external identities](./external-identities-pricing.md) for information on the B2B licensing.

+>[!NOTE]

+>MFA is completed at resource tenancy to ensure predictability. When the guest user signs in, they'll see the resource tenant sign-in page displayed in the background, and their own home tenant sign-in page and company logo in the foreground.

+### Azure AD MFA reset (proof up) for B2B collaboration users

+The following PowerShell cmdlets are available to *proof up* or request MFA registration from B2B collaboration users.

+1. Connect to Azure AD:

+ ```powershell

+ $cred = Get-Credential

+ Connect-MsolService -Credential $cred

+ ```

+2. Get all users with proof up methods:

+ ```powershell

+ Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}

+ ```

+ For example:

+ ```powershell

+ Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}

+ ```

+3. Reset the Azure AD MFA method for a specific user to require the user to set proof up methods again, for example:

+ ```powershell

+ Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com

+ ```

+### Device-based Conditional Access

+In Conditional Access, there's an option to require a userΓÇÖs [device to be compliant or hybrid Azure AD joined](../conditional-access/howto-conditional-access-policy-compliant-device.md). Because devices can only be managed by the home tenant, additional considerations must be made for external users. As the resource tenant, you can use cross-tenant access settings to trust device (compliant and hybrid Azure AD joined) claims.

+>[!Important]

+>

+>- Unless you're willing to trust device (compliant or hybrid Azure AD joined) claims for external users, we don't recommend a Conditional Access policy requiring a managed device.

+>- When guest users try to access a resource protected by Conditional Access, they can't register and enroll devices in your tenant and will be blocked from accessing your resources.

+### Mobile application management policies

+The Conditional Access grant controls, such as **Require approved client apps** and **Require app protection policies**, need the device to be registered in the resource tenant. These controls can only be applied to [iOS and Android devices](../conditional-access/concept-conditional-access-conditions.md#device-platforms). However, neither of these controls can be applied to B2B guest users, since the userΓÇÖs device can only be managed by their home tenant.

+>[!NOTE]

+>We don't recommend requiring an app protection policy for external users.

+### Location-based Conditional Access

+The [location-based policy](../conditional-access/concept-conditional-access-conditions.md#locations) based on IP ranges can be enforced if the inviting organization can create a trusted IP address range that defines their partner organizations.

+Policies can also be enforced based on **geographical locations**.

+### Risk-based Conditional Access

+The [Sign-in risk policy](../conditional-access/concept-conditional-access-conditions.md#sign-in-risk) is enforced if the B2B guest user satisfies the grant control. For example, an organization could require Azure AD Multi-Factor Authentication for medium or high sign-in risk. However, if a user hasn't previously registered for Azure AD Multi-Factor Authentication in the resource tenant, the user will be blocked. This is done to prevent malicious users from registering their own Azure AD Multi-Factor Authentication credentials in the event they compromise a legitimate userΓÇÖs password.

+The [User-risk policy](../conditional-access/concept-conditional-access-conditions.md#user-risk), however, can't be resolved in the resource tenant. For example, if you require a password change for high-risk guest users, they'll be blocked because of the inability to reset passwords in the resource directory.

+### Conditional Access client apps condition

+[Client apps conditions](../conditional-access/concept-conditional-access-conditions.md#client-apps) behave the same for B2B guest users as they do for any other type of user. For example, you could prevent guest users from using legacy authentication protocols.

+### Conditional Access session controls

+[Session controls](../conditional-access/concept-conditional-access-session.md) behave the same for B2B guest users as they do for any other type of user.

+## Next steps

+For more information, see the following articles on Azure AD B2B collaboration:

+- [What is Azure AD B2B collaboration?](./what-is-b2b.md)

+- [Identity Protection and B2B users](../identity-protection/concept-identity-protection-b2b.md)

+- [External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/)

+- [Frequently Asked Questions (FAQs)](./faq.yml)

+> **As of November 1, 2021**, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. As part of this change, Microsoft will stop creating new, unmanaged ("viral") Azure AD accounts and tenants during B2B collaboration invitation redemption. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, if you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+| Carefully consider how you want to collaborate with external users and organizations | Azure AD gives you a flexible set of controls for managing collaboration with external users and organizations. You can allow or block all collaboration, or configure collaboration only for specific organizations, users, and apps. Before configuring settings for cross-tenant access and external collaboration, take a careful inventory of the organizations you work and partner with. Then determine if you want to enable [B2B collaboration](what-is-b2b.md) with other Azure AD tenants, and how you want to manage [B2B collaboration invitations](external-collaboration-settings-configure.md). |

+| Enforce Conditional Access policies for Azure Active Directory Multi-Factor Authentication (MFA) | We recommend enforcing MFA policies on the apps you want to share with partner B2B users. This way, MFA will be consistently enforced on the apps in your tenant regardless of whether the partner organization is using MFA. See [Conditional Access for B2B collaboration users](authentication-conditional-access.md). |

+| If youΓÇÖre enforcing device-based Conditional Access policies, use exclusion lists to allow access to B2B users | If device-based Conditional Access policies are enabled in your organization, B2B guest user devices will be blocked because theyΓÇÖre not managed by your organization. You can create exclusion lists containing specific partner users to exclude them from the device-based Conditional Access policy. See [Conditional Access for B2B collaboration users](authentication-conditional-access.md). |

+| Find out if your environment will be affected by Azure AD directory limits | Azure AD B2B is subject to Azure AD service directory limits. For details about the number of directories a user can create and the number of directories to which a user or guest user can belong, see [Azure AD service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md).|

+[Manage B2B sharing](external-collaboration-settings-configure.md)

+ Title: Azure AD B2B in government and national clouds - Azure Active Directory

+description: Learn what features are available in Azure Active Directory B2B collaboration in US Government and national clouds

+# Azure AD B2B in government and national clouds

+## National clouds

+[National clouds](../develop/authentication-national-cloud.md) are physically isolated instances of Azure. B2B collaboration is not supported across national cloud boundaries. For example, if your Azure tenant is in the public, global cloud, you can't invite a user whose account is in a national cloud. To collaborate with the user, ask them for another email address or create a member user account for them in your directory.

+## Azure US Government clouds

+Within the Azure US Government cloud, B2B collaboration is supported between tenants that are both within Azure US Government cloud and that both support B2B collaboration. Azure US Government tenants that support B2B collaboration can also collaborate with social users using Microsoft, Google accounts, or email one-time passcode accounts. If you invite a user outside of these groups (for example, if the user is in a tenant that isn't part of the Azure US Government cloud or doesn't yet support B2B collaboration), the invitation will fail or the user won't be able to redeem the invitation. For Microsoft accounts (MSAs), there are known limitations with accessing the Azure portal: newly invited MSA guests are unable to redeem direct link invitations to the Azure portal, and existing MSA guests are unable to sign in to the Azure portal. For details about other limitations, see [Azure Active Directory Premium P1 and P2 Variations](../../azure-government/compare-azure-government-global-azure.md#azure-active-directory-premium-p1-and-p2).

+### How can I tell if B2B collaboration is available in my Azure US Government tenant?

+To find out if your Azure US Government cloud tenant supports B2B collaboration, do the following:

+1. In a browser, go to the following URL, substituting your tenant name for *&lt;tenantname&gt;*:

+ `https://login.microsoftonline.com/<tenantname>/v2.0/.well-known/openid-configuration`

+2. Find `"tenant_region_scope"` in the JSON response:

+ - If `"tenant_region_scope":"USGOVΓÇ¥` appears, B2B is supported.

+ - If `"tenant_region_scope":"USG"` appears, B2B is not supported.

+## Next steps

+See the following articles on Azure AD B2B collaboration:

+- [What is Azure AD B2B collaboration?](what-is-b2b.md)

+- [Delegate B2B collaboration invitations](external-collaboration-settings-configure.md)

+ Title: Cross-tenant access overview - Azure AD

+description: Get an overview of cross-tenant access in Azure AD External Identities. Learn how to manage your B2B collaboration with other Azure AD organizations through this overview of cross-tenant access settings.

+# Overview: Cross-tenant access with Azure AD External Identities (Preview)

+> [!NOTE]

+> Cross-tenant access settings are preview features 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/).

+Azure AD organizations can use External Identities cross-tenant access settings to manage how they collaborate with other Azure AD organizations through B2B collaboration. [Cross-tenant access settings](cross-tenant-access-settings-b2b-collaboration.md) give you granular control over how external Azure AD organizations collaborate with you (inbound access) and how your users collaborate with external Azure AD organizations (outbound access). These settings also let you trust multi-factor authentication (MFA) and device claims ([compliant claims and hybrid Azure AD joined claims](../conditional-access/howto-conditional-access-policy-compliant-device.md)) from other Azure AD organizations.

+This article describes cross-tenant access settings that are used to manage B2B collaboration with external Azure AD organizations. For B2B collaboration with non-Azure AD identities (for example, social identities or non-IT managed external accounts), use external collaboration settings. External collaboration settings include options for restricting guest user access, specifying who can invite guests, and allowing or blocking domains.

+

+

+## Manage external access with inbound and outbound settings

+B2B collaboration is enabled by default, but comprehensive admin settings let you control your B2B collaboration with external partners and organizations

+- **Outbound access settings** control whether your users can access resources in an external organization. You can apply these settings to everyone, or you can specify individual users, groups, and applications.

+- **Inbound access settings** control whether users from external Azure AD organizations can access resources in your organization. You can apply these settings to everyone, or you can specify individual users, groups, and applications.

+- **Trust settings** (inbound) determine whether your Conditional Access policies will trust the multi-factor authentication (MFA), compliant device, and [hybrid Azure AD joined device](../devices/concept-azure-ad-join-hybrid.md) claims from an external organization if their users have already satisfied these requirements in their home tenants. For example, when you configure your trust settings to trust MFA, your MFA policies are still applied to external users, but users who have already completed MFA in their home tenants won't have to complete MFA again in your tenant.

+## Default settings

+The default cross-tenant access settings apply to all Azure AD organizations external to your tenant, except those for which you've configured organizational settings. You can change your default settings, but the initial default settings for B2B collaboration are as follows:

+- All your internal users are enabled for B2B collaboration by default. This means your users can invite external guests to access your resources and they can be invited to external organizations as guests. MFA and device claims from other Azure AD organizations aren't trusted.

+- No organizations are added to your Organizational settings by default. This means all external Azure AD organizations are enabled for B2B collaboration with your organization.

+## Organizational settings

+You can configure organization-specific settings by adding an organization and modifying the inbound and outbound settings for that organization. Organizational settings take precedence over default settings.

+- For B2B collaboration with other Azure AD organizations, you can use cross-tenant access settings to manage inbound and outbound B2B collaboration and scope access to specific users, groups, and applications. You can set a default configuration that applies to all external organizations, and then create individual, organization-specific settings as needed. Using cross-tenant access settings, you can also trust multi-factor (MFA) and device claims (compliant claims and hybrid Azure AD joined claims) from other Azure AD organizations.

+- You can use external collaboration settings to limit who can invite external users, allow or block B2B specific domains, and set restrictions on guest user access to your directory.

+## Important considerations

+> [!CAUTION]

+> Changing the default inbound or outbound settings to Block access could block existing business-critical access to apps in your organization or partner organizations. Be sure to use the tools described in this article and consult with your business stakeholders to identify the required access.

+- Cross-tenant access settings are used to manage B2B collaboration with other Azure AD organizations. For non-Azure AD identities (for example, social identities or non-IT managed external accounts), use [external collaboration settings](external-collaboration-settings-configure.md). External collaboration settings include options for restricting guest user access, specifying who can invite guests, and allowing or blocking domains.

+- If you want to apply access settings to specific users, groups, or applications in an external organization, you'll need to contact the organization for information before configuring your settings. Obtain their user object IDs, group object IDs, or application IDs (*client app IDs* or *resource app IDs*) so you can target your settings correctly.

+ > [!TIP]

+ > You might be able to find the application IDs for apps in external organizations by checking your sign-in logs. See the [Identify inbound and outbound sign-ins](#identify-inbound-and-outbound-sign-ins) section.

+- The access settings you configure for users and groups must match the access settings for applications. Conflicting settings aren't allowed, and youΓÇÖll see warning messages if you try to configure them.

+ - **Example 1**: If you block inbound B2B collaboration for all external users and groups, access to all your applications must also be blocked.

+ - **Example 2**: If you allow outbound B2B collaboration for all your users (or specific users or groups), youΓÇÖll be prevented from blocking all access to external applications; access to at least one application must be allowed.

+- If you block access to all apps by default, users will be unable to read emails encrypted with Microsoft Rights Management Service (also known as Office 365 Message Encryption or OME). To avoid this issue, we recommend configuring your outbound settings to allow your users to access this app ID: 00000012-0000-0000-c000-000000000000. If this is the only application you allow, access to all other apps will be blocked by default.

+- To configure cross-tenant access settings in the Azure portal, you'll need an account with a Global administrator or Security administrator role.

+- To configure trust settings or apply access settings to specific users, groups, or applications, you'll need an Azure AD Premium P1 license.

+## Identify inbound and outbound sign-ins

+Several tools are available to help you identify the access your users and partners need before you set inbound and outbound access settings. To ensure you donΓÇÖt remove access that your users and partners need, you can examine current sign-in behavior. Taking this preliminary step will help prevent loss of desired access for your end users and partner users. However, in some cases these logs are only retained for 30 days, so we strongly recommend you speak with your business stakeholders to ensure required access isn't lost.

+### Sign-In Logs

+To determine your users access to external Azure AD organizations in the last 30 days, run the following PowerShell script:

+```powershell

+Get-MgAuditLogsSignIn `

+-Filter ΓÇ£ResourceTenantID ne ΓÇÿyour tenant idΓÇÖΓÇ¥ `

+-all:$True| `

+group ResourceTenantId,AppDisplayName,UserPrincipalName| `

+select count, @{n=ΓÇÖExt TenantID/App User PairΓÇÖ;e={$_.name}}]

+```

+The output is a list of outbound sign-ins initiated by your users to apps in external tenants, for example:

+```powershell

+Count Ext TenantID/App User Pair

+-- --

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, ADIbizaUX, a@b.com

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, Azure Portal, a@b.com

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, Access Panel, a@b.com

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, MS-PIM, a@b.com

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, AAD ID Gov, a@b.com

+ 6 45fc4ed2-8f2b-42c1-b98c-b254d552f4a7, Access Panel, a@b.com

+```

+For the most up-to-date PowerShell script, see the [cross-tenant user sign-in activity script](https://aka.ms/cross-tenant-signins-ps).

+### Azure Monitor

+If your organization subscribes to the Azure Monitor service, you can use the **Cross-tenant access activity** workbook (available in the Monitoring workbooks gallery in the Azure portal) to visually explore inbound and outbound sign-ins for longer time periods.

+### Security Information and Event Management (SIEM) Systems

+If your organization exports sign-in logs to a Security Information and Event Management (SIEM) system, you can retrieve required information from your SIEM system.

+## Next steps

+[Configure cross-tenant access settings for B2B collaboration](cross-tenant-access-settings-b2b-collaboration.md)

+ Title: Configure B2B collaboration cross-tenant access - Azure AD

+description: Use cross-tenant collaboration settings to manage how you collaborate with other Azure AD organizations. Learn how to configure outbound access to external organizations and inbound access from external Azure AD for B2B collaboration.

+# Configure cross-tenant access settings for B2B collaboration (Preview)

+> [!NOTE]

+> Cross-tenant access settings are preview features 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/).

+Use External Identities cross-tenant access settings to manage how you collaborate with other Azure AD organizations through B2B collaboration. These settings determine both the level of *inbound* access users in external Azure AD organizations have to your resources, as well as the level of *outbound* access your users have to external organizations. They also let you trust multi-factor authentication (MFA) and device claims ([compliant claims and hybrid Azure AD joined claims](../conditional-access/howto-conditional-access-policy-compliant-device.md)) from other Azure AD organizations. For details and planning considerations, see [Cross-tenant access in Azure AD External Identities](cross-tenant-access-overview.md).

+## Before you begin

+ > [!CAUTION]

+ > Changing the default inbound or outbound settings to **Block access** could block existing business-critical access to apps in your organization or partner organizations. Be sure to use the tools described in [Cross-tenant access in Azure AD External Identities](cross-tenant-access-overview.md) and consult with your business stakeholders to identify the required access.

+- Review the [Important considerations](cross-tenant-access-overview.md#important-considerations) section in the [cross-tenant access overview](cross-tenant-access-overview.md) before configuring your cross-tenant access settings.

+- Use the tools and follow the recommendations in [Identify inbound and outbound sign-ins](cross-tenant-access-overview.md#identify-inbound-and-outbound-sign-ins) to understand which external Azure AD organizations and resources users are currently accessing.

+- Decide on the default level of access you want to apply to all external Azure AD organizations.

+- Identify any Azure AD organizations that will need customized settings so you can configure **Organizational settings** for them.

+- If you want to apply access settings to specific users, groups, or applications in an external organization, you'll need to contact the organization for information before configuring your settings. Obtain their user object IDs, group object IDs, or application IDs (*client app IDs* or *resource app IDs*) so you can target your settings correctly.

+## Configure default settings

+ Default cross-tenant access settings apply to all external tenants for which you haven't created organization-specific customized settings. If you want to modify the Azure AD-provided default settings, follow these steps.

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator or Security administrator account. Then open the **Azure Active Directory** service.

+1. Select **External Identities**, and then select **Cross-tenant access settings (Preview)**.

+1. Select the **Default settings** tab and review the summary page.

+ 

+1. To change the settings, select the **Edit inbound defaults** link or the **Edit outbound defaults** link.

+ 

+1. Modify the default settings by following the detailed steps in these sections:

+ - [Modify inbound access settings](#modify-inbound-access-settings)

+ - [Modify outbound access settings](#modify-outbound-access-settings)

+## Add an organization

+Follow these steps to configure customized settings for specific organizations.

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator or Security administrator account. Then open the **Azure Active Directory** service.

+1. Select **External Identities**, and then select **Cross-tenant access settings (preview)**.

+1. Select **Organizational settings**.

+1. Select **Add organization**.

+1. On the **Add organization** pane, type the full domain name (or tenant ID) for the organization.

+ 

+1. Select the organization in the search results, and then select **Add**.

+1. The organization appears in the **Organizational settings** list. At this point, all access settings for this organization are inherited from your default settings. To change the settings for this organization, select the **Inherited from default** link under the **Inbound access** or **Outbound access** column.

+ 

+1. Modify the organization's settings by following the detailed steps in these sections:

+ - [Modify inbound access settings](#modify-inbound-access-settings)

+ - [Modify outbound access settings](#modify-outbound-access-settings)

+## Modify inbound access settings

+With inbound settings, you select which external users and groups will be able to access the internal applications you choose. Whether you're configuring default settings or organization-specific settings, the steps for changing inbound cross-tenant access settings are the same. As described in this section, you'll navigate to either the **Default** tab or an organization on the **Organizational settings** tab, and then make your changes.

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator or Security administrator account. Then open the **Azure Active Directory** service.

+1. Select **External Identities** > **Cross-tenant access settings (preview)**.

+1. Navigate to the settings you want to modify:

+ - **Default settings**: To modify default inbound settings, select the **Default settings** tab, and then under **Inbound access settings**, select **Edit inbound defaults**.

+ - **Organizational settings**: To modify settings for a specific organization, select the **Organizational settings** tab, find the organization in the list (or [add one](#add-an-organization)), and then select the link in the **Inbound access** column.

+1. Follow the detailed steps for the inbound settings you want to change:

+ - [To change inbound B2B collaboration settings](#to-change-inbound-b2b-collaboration-settings)

+ - [To change inbound trust settings for accepting MFA and device claims](#to-change-inbound-trust-settings-for-mfa-and-device-claims)

+### To change inbound B2B collaboration settings

+1. Select the **B2B collaboration** tab.

+1. (This step applies to **Organizational settings** only.) If you're configuring inbound access settings for a specific organization, select one of the following:

+ - **Default settings**: Select this option if you want the organization to use the default inbound settings (as configured on the **Default** settings tab). If customized settings were already configured for this organization, you'll need to select **Yes** to confirm that you want all settings to be replaced by the default settings. Then select **Save**, and skip the rest of the steps in this procedure.

+ - **Customize settings**: Select this option if you want to customize the settings for this organization, which will be enforced for this organization instead of the default settings. Continue with the rest of the steps in this procedure.

+1. Select **External users and groups**.

+1. Under **Access status**, select one of the following:

+ - **Allow access**: Allows the users and groups specified under **Target** to be invited for B2B collaboration.

+ - **Block access**: Blocks the users and groups specified under **Target** from being invited to B2B collaboration.

+ 

+1. Under **Target**, select one of the following:

+ - **All external users and groups**: Applies the action you chose under **Access status** to all users and groups from external Azure AD organizations.

+ - **Select external users and groups** (requires an Azure AD premium subscription): Lets you apply the action you chose under **Access status** to specific users and groups within the external organization.

+ > [!NOTE]

+ > If you block access for all external users and groups, you also need to block access to all your internal applications (on the **Applications** tab).

+ 

+1. If you chose **Select external users and groups**, do the following for each user or group you want to add:

+ - Select **Add external users and groups**.

+ - In the **Add other users and groups** pane, in the search box, type the user object ID or group object ID you obtained from your partner organization.

+ - In the menu next to the search box, choose either **user** or **group**.

+ - Select **Add**.

+ 

+1. When you're done adding users and groups, select **Submit**.

+ 

+1. Select the **Applications** tab.

+1. Under **Access status**, select one of the following:

+ - **Allow access**: Allows the applications specified under **Target** to be accessed by B2B collaboration users.

+ - **Block access**: Blocks the applications specified under **Target** from being accessed by B2B collaboration users.

+ 

+1. Under **Target**, select one of the following:

+ - **All applications**: Applies the action you chose under **Access status** to all of your applications.

+ - **Select applications** (requires an Azure AD premium subscription): Lets you apply the action you chose under **Access status** to specific applications in your organization.

+ > [!NOTE]

+ > If you block access to all applications, you also need to block access for all external users and groups (on the **External users and groups** tab).

+ 

+1. If you chose **Select applications**, do the following for each application you want to add:

+ - Select **Add Microsoft applications** or **Add other applications**.

+ - In the **Select** pane, type the application name or the application ID (either the *client app ID* or the *resource app ID*) in the search box. Then select the application in the search results. Repeat for each application you want to add.

+ - When you're done selecting applications, choose **Select**.

+ 

+1. Select **Save**.

+### To change inbound trust settings for MFA and device claims

+1. Select the **Trust settings** tab.

+1. (This step applies to **Organizational settings** only.) If you're configuring settings for an organization, select one of the following:

+ - **Default settings**: The organization will use the settings configured on the **Default** settings tab. If customized settings were already configured for this organization, you'll need to select **Yes** to confirm that you want all settings to be replaced by the default settings. Then select **Save**, and skip the rest of the steps in this procedure.

+ - **Customize settings**: You can customize the settings for this organization, which will be enforced for this organization instead of the default settings. Continue with the rest of the steps in this procedure.

+1. Select one or more of the following options:

+ - **Trust multi-factor authentication from Azure AD tenants**: Select this checkbox to allow your Conditional Access policies to trust MFA claims from external organizations. During authentication, Azure AD will check a user's credentials for a claim that the user has completed MFA. If not, an MFA challenge will be initiated in the user's home tenant.

+ - **Trust compliant devices**: Allows your Conditional Access policies to trust compliant device claims from an external organization when their users access your resources.

+ - **Trust hybrid Azure AD joined devices**: Allows your Conditional Access policies to trust hybrid Azure AD joined device claims from an external organization when their users access your resources.

+ 

+1. Select **Save**.

+## Modify outbound access settings

+With outbound settings, you select which of your users and groups will be able to access the external applications you choose. Whether you're configuring default settings or organization-specific settings, the steps for changing outbound cross-tenant access settings are the same. As described in this section, you'll navigate to either the **Default** tab or an organization on the **Organizational settings** tab, and then make your changes.

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator or Security administrator account. Then open the **Azure Active Directory** service.

+1. Select **External Identities**, and then select **Cross-tenant access settings (Preview)**.

+1. Navigate to the settings you want to modify:

+ - To modify default outbound settings, select the **Default settings** tab, and then under **Outbound access settings**, select **Edit outbound defaults**.

+ - To modify settings for a specific organization, select the **Organizational settings** tab, find the organization in the list (or [add one](#add-an-organization)) and then select the link in the **Outbound access** column.

+1. Select the **B2B collaboration** tab.

+1. (This step applies to **Organizational settings** only.) If you're configuring settings for an organization, select one of the following:

+ - **Default settings**: The organization will use the settings configured on the **Default** settings tab. If customized settings were already configured for this organization, you'll need to select **Yes** to confirm that you want all settings to be replaced by the default settings. Then select **Save**, and skip the rest of the steps in this procedure.

+ - **Customize settings**: You can customize the settings for this organization, which will be enforced for this organization instead of the default settings. Continue with the rest of the steps in this procedure.

+1. Select **Users and groups**.

+1. Under **Access status**, select one of the following:

+ - **Allow access**: Allows your users and groups specified under **Target** to be invited to external organizations for B2B collaboration.

+ - **Block access**: Blocks your users and groups specified under **Target** from being invited to B2B collaboration. If you block access for all users and groups, this will also block all external applications from being accessed via B2B collaboration.

+ 

+1. Under **Target**, select one of the following:

+ - **All \<your organization\> users**: Applies the action you chose under **Access status** to all your users and groups.

+ - **Select \<your organization\> users and groups** (requires an Azure AD premium subscription): Lets you apply the action you chose under **Access status** to specific users and groups.

+ > [!NOTE]

+ > If you block access for all of your users and groups, you also need to block access to all external applications (on the **External applications** tab).

+ 

+1. If you chose **Select \<your organization\> users and groups**, do the following for each user or group you want to add:

+ - Select **Add \<your organization\> users and groups**.

+ - In the **Select** pane, type the user name or group name in the search box.

+ - Select the user or group in the search results.

+ - When you're done selecting the users and groups you want to add, choose **Select**.

+1. Select the **External applications** tab.

+1. Under **Access status**, select one of the following:

+ - **Allow access**: Allows the external applications specified under **Target** to be accessed by your users via B2B collaboration.

+ - **Block access**: Blocks the external applications specified under **Target** from being accessed by your users via B2B collaboration.

+ 

+1. Under **Target**, select one of the following:

+ - **All external applications**: Applies the action you chose under **Access status** to all external applications.

+ - **Select external applications**: Applies the action you chose under **Access status** to all external applications.

+ > [!NOTE]

+ > If you block access to all external applications, you also need to block access for all of your users and groups (on the **Users and groups** tab).

+ 

+1. If you chose **Select external applications**, do the following for each application you want to add:

+ - Select **Add Microsoft applications** or **Add other applications**.

+ - In the search box, type the application name or the application ID (either the *client app ID* or the *resource app ID*). Then select the application in the search results. Repeat for each application you want to add.

+ - When you're done selecting applications, choose **Select**.

+ 

+1. Select **Save**.

+## Next steps

+See [Configure external collaboration settings](external-collaboration-settings-configure.md) for B2B collaboration with non-Azure AD identities, social identities, and non-IT managed external accounts.

+With Azure AD B2B, you can enforce multi-factor authentication at the resource organization (the inviting organization). The reasons for this approach are detailed in [Conditional Access for B2B collaboration users](authentication-conditional-access.md). If a partner already has multi-factor authentication set up and enforced, their users might have to perform the authentication once in their home organization and then again in yours.

+- [Azure AD B2B in government and national clouds](b2b-government-national-clouds.md)

+- [Delegate B2B collaboration invitations](external-collaboration-settings-configure.md)

+ Title: Enable B2B external collaboration settings - Azure AD

+description: Learn how to enable Active Directory B2B external collaboration and manage who can invite guest users. Use the Guest Inviter role to delegate invitations.

+# Configure external collaboration settings

+External collaboration settings let you specify what roles in your organization can invite external users for B2B collaboration. These settings also include options for [allowing or blocking specific domains](allow-deny-list.md), and options for restricting what external guest users can see in your Azure AD directory. The following options are available:

+- **Determine guest user access**: Azure AD allows you to restrict what external guest users can see in your Azure AD directory. For example, you can limit guest users' view of group memberships, or allow guests to view only their own profile information.

+- **Specify who can invite guests**: By default, all users in your organization, including B2B collaboration guest users, can invite external users to B2B collaboration. If you want to limit the ability to send invitations, you can turn invitations on or off for everyone, or limit invitations to certain roles.

+- **Enable guest self-service sign-up via user flows**: For applications you build, you can create user flows that allow a user to sign up for an app and create a new guest account. You can enable the feature in your external collaboration settings, and then [add a self-service sign-up user flow to your app](self-service-sign-up-user-flow.md).

+- **Allow or block domains**: You can use collaboration restrictions to allow or deny invitations to the domains you specify. For details, see [Allow or block domains](allow-deny-list.md).

+For B2B collaboration with other Azure AD organizations, you should also review your [cross-tenant access settings](cross-tenant-access-settings-b2b-collaboration.md) to ensure your inbound and outbound B2B collaboration and scope access to specific users, groups, and applications.

+### To configure external collaboration settings:

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator or Security administrator account and open the **Azure Active Directory** service.

+1. Select **External Identities** > **External collaboration settings**.

+1. Under **Guest user access**, choose the level of access you want guest users to have:

+

+ - **Guest users have the same access as members (most inclusive)**: This option gives guests the same access to Azure AD resources and directory data as member users.

+ - **Guest users have limited access to properties and memberships of directory objects**: (Default) This setting blocks guests from certain directory tasks, like enumerating users, groups, or other directory resources. Guests can see membership of all non-hidden groups.

+ - **Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)**: With this setting, guests can access only their own profiles. Guests are not allowed to see other users' profiles, groups, or group memberships.

+1. Under **Guest invite settings**, choose the appropriate settings:

+ 

+ - **Anyone in the organization can invite guest users including guests and non-admins (most inclusive)**: To allow guests in the organization to invite other guests including those who are not members of an organization, select this radio button.

+ - **Member users and users assigned to specific admin roles can invite guest users including guests with member permissions**: To allow member users and users who have specific administrator roles to invite guests, select this radio button.

+ - **Only users assigned to specific admin roles can invite guest users**: To allow only those users with administrator roles to invite guests, select this radio button. The administrator roles include [Global Administrator](../roles/permissions-reference.md#global-administrator), [User Administrator](../roles/permissions-reference.md#user-administrator), and [Guest Inviter](../roles/permissions-reference.md#guest-inviter).

+ - **No one in the organization can invite guest users including admins (most restrictive)**: To deny everyone in the organization from inviting guests, select this radio button.

+ > [!NOTE]

+ > If **Members can invite** is set to **No** and **Admins and users in the guest inviter role can invite** is set to **Yes**, users in the **Guest Inviter** role will still be able to invite guests.

+1. Under **Enable guest self-service sign up via user flows**, select **Yes** if you want to be able to create user flows that let users sign up for apps. For more information about this setting, see [Add a self-service sign-up user flow to an app](self-service-sign-up-user-flow.md).

+ 

+1. Under **Collaboration restrictions**, you can choose whether to allow or deny invitations to the domains you specify and enter specific domain names in the text boxes. For multiple domains, enter each domain on a new line. For more information, see [Allow or block invitations to B2B users from specific organizations](allow-deny-list.md).

+ 

+## Assign the Guest Inviter role to a user

+With the Guest Inviter role, you can give individual users the ability to invite guests without assigning them a global administrator or other admin role. Assign the Guest inviter role to individuals. Then make sure you set **Admins and users in the guest inviter role can invite** to **Yes**.

+Here's an example that shows how to use PowerShell to add a user to the Guest Inviter role:

+```

+Add-MsolRoleMember -RoleObjectId 95e79109-95c0-4d8e-aee3-d01accf2d47b -RoleMemberEmailAddress <RoleMemberEmailAddress>

+```

+## Next steps

+See the following articles on Azure AD B2B collaboration:

+- [What is Azure AD B2B collaboration?](what-is-b2b.md)

+- [Add B2B collaboration guest users without an invitation](add-user-without-invite.md)

+- [Adding a B2B collaboration user to a role](./add-users-administrator.md)

+ Title: External Identities in Azure Active Directory | Microsoft Docs

+description: Azure AD External Identities allow you to collaborate with or publish apps to people outside your organization. Compare solutions for External Identities, including Azure Active Directory B2B collaboration, Azure AD B2B collaboration, and Azure AD B2C.

+# External Identities in Azure Active Directory

+Azure AD External Identities refers to all the ways you can securely interact with users outside of your organization. If you want to collaborate with partners, distributors, suppliers, or vendors, you can share your resources and define how your internal users can access external organizations. If you're a developer creating consumer-facing apps, you can manage your customers' identity experiences.

+With External Identities, external users can "bring their own identities." Whether they have a corporate or government-issued digital identity, or an unmanaged social identity like Google or Facebook, they can use their own credentials to sign in. The external userΓÇÖs identity provider manages their identity, and you manage access to your apps with Azure AD or Azure AD B2C to keep your resources protected.

+The following capabilities make up External Identities:

+- **B2B collaboration** - Collaborate with external users by letting them use their preferred identity to sign in to your Microsoft applications or other enterprise applications (SaaS apps, custom-developed apps, etc.). B2B collaboration users are represented in your directory, typically as guest users.

+

+- **Azure AD B2C** - Publish modern SaaS apps or custom-developed apps (excluding Microsoft apps) to consumers and customers, while using Azure AD B2C for identity and access management.

+Depending on how you want to interact with external organizations and the types of resources you need to share, you can use a combination of these capabilities.

+

+## B2B collaboration

+With B2B collaboration, you can invite anyone to sign in to your Azure AD organization using their own credentials so they can access the apps and resources you want to share with them. Use B2B collaboration when you need to let external users access your Office 365 apps, software-as-a-service (SaaS) apps, and line-of-business applications, especially when the partner doesn't use Azure AD. There are no credentials associated with B2B collaboration users. Instead, they authenticate with their home organization or identity provider, and then your organization checks the guest userΓÇÖs eligibility for B2B collaboration.

+There are various ways to add external users to your organization for B2B collaboration:

+- Invite users to B2B collaboration using their Azure AD accounts, Microsoft accounts, or social identities that you enable, such as Google. An admin can use the Azure portal or PowerShell to invite users to B2B collaboration. The user signs into the shared resources using a simple redemption process with their work, school, or other email account.

+- Use self-service sign-up user flows to let external users sign up for applications themselves. The experience can be customized to allow sign-up with a work, school, or social identity (like Google or Facebook). You can also collect information about the user during the sign-up process.

+- Use [Azure AD entitlement management](../governance/entitlement-management-overview.md), an identity governance feature that lets you manage [identity and access for external users at scale](../governance/entitlement-management-external-users.md#how-access-works-for-external-users) by automating access request workflows, access assignments, reviews, and expiration.

+A user object is created for the B2B collaboration user in the same directory as your employees. This user object can be managed like other user objects in your directory, added to groups, and so on. You can assign permissions to the user object (for authorization) while letting them use their existing credentials (for authentication).

+You can use [cross-tenant access settings](cross-tenant-access-overview.md) to manage B2B collaboration with other Azure AD organizations. For B2B collaboration with non-Azure AD external users and organizations, use [external collaboration settings](external-collaboration-settings-configure.md).

+Learn more about [B2B collaboration in Azure AD](what-is-b2b.md).

+## Azure AD B2C

+Azure AD B2C is a Customer Identity and Access Management (CIAM) solution that lets you build user journeys for consumer- and customer-facing apps. If you're a business or individual developer creating customer-facing apps, you can scale to millions of consumers, customers, or citizens by using Azure AD B2C. Developers can use Azure AD B2C as the full-featured CIAM system for their applications.

+With Azure AD B2C, customers can sign in with an identity they've already established (like Facebook or Gmail). With Azure AD B2C, you can completely customize and control how customers sign up, sign in, and manage their profiles when using your applications. For more information, see the Azure AD B2C documentation.

+Learn more about [Azure AD B2C](../../active-directory-b2c/index.yml).

+## Comparing External Identities feature sets

+The following table gives a detailed comparison of the scenarios you can enable with Azure AD External Identities. In the B2B scenarios, an external user is anyone who is not homed in your Azure AD organization.

+| | B2B collaboration | Azure AD B2C |

+| - | | |

+| **Primary scenario** | Collaborate with external users by letting them use their preferred identity to sign in to resources in your Azure AD organization. Provides access to Microsoft applications or your own applications (SaaS apps, custom-developed apps, etc.). <br><br> *Example:* Invite an external user to sign in to your Microsoft apps or become a guest member in Teams. | Publish apps to consumers and customers using Azure AD B2C for identity experiences. Provides identity and access management for modern SaaS or custom-developed applications (not first-party Microsoft apps). |

+| **Intended for** | Collaborating with business partners from external organizations like suppliers, partners, vendors. These users may or may not have Azure AD or managed IT. | Customers of your product. These users are managed in a separate Azure AD directory. |

+| **User management** | B2B collaboration users are managed in the same directory as employees but are typically annotated as guest users. Guest users can be managed the same way as employees, added to the same groups, and so on. Cross-tenant access settings can be used to determine which users have access to B2B collaboration. | User objects are created for consumer users in your Azure AD B2C directory. They're managed separately from the organization's employee and partner directory (if any). |

+| **Identity providers supported** | External users can collaborate using work accounts, school accounts, any email address, SAML and WS-Fed based identity providers, and social identity providers like Gmail and Facebook. | Consumer users with local application accounts (any email address, user name, or phone number), Azure AD, various supported social identities, and users with corporate and government-issued identities via SAML/WS-Fed-based identity provider federation. |

+| **Single sign-on (SSO)** | SSO to all Azure AD-connected apps is supported. For example, you can provide access to Microsoft 365 or on-premises apps, and to other SaaS apps such as Salesforce or Workday. | SSO to customer owned apps within the Azure AD B2C tenants is supported. SSO to Microsoft 365 or to other Microsoft SaaS apps isn't supported. |

+| **Licensing and billing** | Based on monthly active users (MAU), including B2B collaboration and Azure AD B2C users. Learn more about [External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/) and [billing setup for B2B](external-identities-pricing.md). | Based on monthly active users (MAU), including B2B collaboration and Azure AD B2C users. Learn more about [External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/) and [billing setup for Azure AD B2C](../../active-directory-b2c/billing.md). |

+| **Security policy and compliance** | Managed by the host/inviting organization (for example, with [Conditional Access policies](authentication-conditional-access.md) and cross-tenant access settings). | Managed by the organization via Conditional Access and Identity Protection. |

+| **Branding** | Host/inviting organization's brand is used. | Fully customizable branding per application or organization. |

+| **More information** | [Blog post](https://blogs.technet.microsoft.com/enterprisemobility/2017/02/01/azure-ad-b2b-new-updates-make-cross-business-collab-easy/), [Documentation](what-is-b2b.md) | [Product page](https://azure.microsoft.com/services/active-directory-b2c/), [Documentation](../../active-directory-b2c/index.yml) |

+## Managing External Identities features

+Azure AD B2B collaboration is a feature of Azure AD, and it's managed in the Azure portal through the Azure Active Directory service. To control inbound and outbound collaboration with other Azure AD organizations, you can use *cross-tenant access settings*. To control inbound collaboration with other non-Azure AD organizations, you can use *external collaboration settings*.

+### Cross-tenant access settings (Preview)

+Cross-tenant access settings let you manage B2B collaboration with other Azure AD organizations. You can determine how other Azure AD organizations collaborate with you (inbound access), and how your users collaborate with other Azure AD organizations (outbound access). Granular controls let you determine the people, groups, and apps, both in your organization and in external Azure AD organizations, that can participate in B2B collaboration. You can also trust multi-factor authentication (MFA) and device claims (compliant claims and hybrid Azure AD joined claims) from other Azure AD organizations.

+- **Default cross-tenant access settings** determine your baseline inbound and outbound settings for B2B collaboration. Initially, your default settings are configured to allow all inbound and outbound B2B collaboration with other Azure AD organizations. You can change these initial settings to create your own default configuration.

+- **Organization-specific access settings** let you configure customized settings for individual Azure AD organizations. Once you add an organization and customize your cross-tenant access settings with this organization, these settings will take precedence over your defaults. For example, you could enable B2B collaboration with all external organizations by default, but disable this feature only for Fabrikam.

+For more information, see [Cross-tenant access in Azure AD External Identities](cross-tenant-access-overview.md).

+### External collaboration settings

+External collaboration settings determine whether your users can send B2B collaboration invitations to external users and the level of access guest users have to your directory. With these settings, you can:

+- **Determine guest user permissions**. Azure AD allows you to restrict what external guest users can see in your Azure AD directory. For example, you can limit guest users' view of group memberships, or allow guests to view only their own profile information.

+- **Specify who can invite guests**. By default, all users in your organization, including B2B collaboration guest users, can invite external users to B2B collaboration. If you want to limit the ability to send invitations, you can turn invitations on or off for everyone, or limit invitations to certain roles.

+- **Allow or block domains**. Choose whether to allow or deny invitations to the domains you specify. For details, see [Allow or block domains](allow-deny-list.md).

+For more information, see how to [configure B2B external collaboration settings](external-collaboration-settings-configure.md).

+### How external collaboration and cross-tenant access settings work together

+External collaboration settings work at the invitation level, whereas cross-tenant access settings work at the authentication level.

+Cross-tenant access settings and external collaboration settings are used to manage two different aspects of B2B collaboration. Cross-tenant access settings control whether users can authenticate with external Azure AD tenants, and they apply to both inbound and outbound B2B collaboration. By contrast, external collaboration settings control which of your users are allowed to send B2B collaboration invitations to external users from any organization.

+When you're considering B2B collaboration with a specific external Azure AD organization, youΓÇÖll want to assess whether your cross-tenant access settings allow B2B collaboration with that organization, and whether your external collaboration settings allow your users to send invitations to that organization's domain. Here are some examples:

+- **Example 1**: You've previously added `adatum.com` (an Azure AD organization) to the list of blocked domains in your external collaboration settings, but your cross-tenant access settings enable B2B collaboration for all Azure AD organizations. In this case, the most restrictive setting applies. Your external collaboration settings will prevent your users from sending invitations to users at `adatum.com`.

+- **Example 2**: You allow B2B collaboration with Fabrikam in your cross-tenant access settings, but then you add `fabrikam.com` to your blocked domains in your external collaboration settings. Your users won't be able to invite new Fabrikam guest users, but existing Fabrikam guests will be able to continue using B2B collaboration.

+### Azure Active Directory B2C management

+Azure AD B2C is a separate consumer-based directory that you manage in the Azure portal through the Azure AD B2C service. Each Azure AD B2C tenant is separate and distinct from other Azure Active Directory and Azure AD B2C tenants. The Azure AD B2C portal experience is similar to Azure AD, but there are key differences, such as the ability to customize your user journeys using the Identity Experience Framework.

+For details about configuring and managing Azure AD B2C, see the [Azure AD B2B documentation](../../active-directory-b2c/index.yml).

+## Related Azure AD technologies

+There are several Azure AD technologies that are related to collaboration with external users and organizations. As you design your External Identities collaboration model, consider these additional features.

+### Azure AD entitlement management for B2B guest user sign-up

+As an inviting organization, you might not know ahead of time who the individual external collaborators are who need access to your resources. You need a way for users from partner companies to sign themselves up with policies that you control. If you want to enable users from other organizations to request access, and upon approval be provisioned with guest accounts and assigned to groups, apps, and SharePoint Online sites, you can use [Azure AD entitlement management](../governance/entitlement-management-overview.md) to configure policies that [manage access for external users](../governance/entitlement-management-external-users.md#how-access-works-for-external-users).

+### Azure AD Microsoft Graph API for B2B collaboration

+Microsoft Graph APIs are available for creating and managing External Identities features.

+- **Cross-tenant access settings API**: The Microsoft Graph cross-tenant access API lets you programmatically create the same B2B collaboration policies that are configurable in the Azure portal. Using the API, you can set up policies for inbound and outbound collaboration to allow or block features for everyone by default and limit access to specific organizations, groups, users, and applications. The API also allows you to accept MFA and device claims (compliant claims and hybrid Azure AD joined claims) from other Azure AD organizations.

+- **B2B collaboration invitation manager**: The [Microsoft Graph invitation manager API](/graph/api/resources/invitation) is available for building your own onboarding experiences for B2B guest users. You can use the [create invitation API](/graph/api/invitation-post?tabs=http) to automatically send a customized invitation email directly to the B2B user, for example. Or your app can use the inviteRedeemUrl returned in the creation response to craft your own invitation (through your communication mechanism of choice) to the invited user.

+### Conditional Access

+Organizations can enforce Conditional Access policies for external B2B collaboration users in the same way that they're enabled for full-time employees and members of the organization. For Azure AD cross-tenant scenarios, if your Conditional Access policies require MFA or device compliance, you can now trust MFA and device compliance claims from an external user's home organization. When trust settings are enabled, during authentication, Azure AD will check a user's credentials for an MFA claim or a device ID to determine if the policies have already been met. If so, the external user will be granted seamless sign-on to your shared resource. Otherwise, an MFA or device challenge will be initiated in the user's home tenant. Learn more about the [authentication flow and Conditional Access for external users](authentication-conditional-access.md).

+### Multitenant applications

+If you offer a Software as a Service (SaaS) application to many organizations, you can configure your application to accept sign-ins from any Azure Active Directory (Azure AD) tenant. This configuration is called making your application multi-tenant. Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application. See how to [enable multitenant sign-ins](../develop/howto-convert-app-to-be-multi-tenant.md).

+## Next steps

+- [What is Azure AD B2B collaboration?](what-is-b2b.md)

+- [About Azure AD B2C](../../active-directory-b2c/overview.md)

+- You can set up multi-factor authentication (MFA) policies for the Guest user so that MFA is used during Application Proxy authentication. For more information, see [Conditional Access for B2B collaboration users](authentication-conditional-access.md).

+### Create B2B guest user objects through an Azure AD B2B script

+You can use an [Azure AD B2B sample script](https://github.com/Azure-Samples/B2B-to-AD-Sync) to create shadow Azure AD accounts synced from Azure AD B2B accounts. You can then use the shadow accounts for on-premises apps that use KCD.

+* [Delegate B2B collaboration invitations](external-collaboration-settings-configure.md)

+> - **As of November 1, 2021**, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. As part of this change, Microsoft no longer creates new, unmanaged ("viral") Azure AD accounts and tenants during B2B collaboration invitation redemption. To minimize disruptions during the holidays and deployment lockdowns, the majority of tenants will see changes rolled out in January 2022. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, if you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+Starting November 1, 2021, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. Microsoft no longer supports the redemption of invitations by creating unmanaged ("viral" or "just-in-time") Azure AD accounts and tenants for B2B collaboration scenarios. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, you have the option of disabling this feature if you choose not to use it.

+For more information about current limitations, see [Azure AD B2B in government and national clouds](b2b-government-national-clouds.md).

+No, the global rollout of the change to enable email one-time passcode by default that began on November 1, 2021 doesn't include SharePoint and OneDrive integration with Azure AD B2B. To learn how to enable integration so that collaboration on SharePoint and OneDrive uses B2B capabilities, or how to disable this integration, see [SharePoint and OneDrive Integration with Azure AD B2B](/sharepoint/sharepoint-azureb2b-integration).

+> - **As of November 1, 2021**, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. As part of this change, Microsoft will stop creating new, unmanaged ("viral") Azure AD accounts and tenants during B2B collaboration invitation redemption. To minimize disruptions during the holidays and deployment lockdowns, the majority of tenants will see changes rolled out in January 2022. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, if you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+- [Leave an organization as a guest user](leave-the-organization.md)

+ > - **As of November 1, 2021**, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. As part of this change, Microsoft will stop creating new, unmanaged ("viral") Azure AD accounts and tenants during B2B collaboration invitation redemption. To minimize disruptions during the holidays and deployment lockdowns, the majority of tenants will see changes rolled out in January 2022. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, if you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+## An error similar to "Failure to update policy due to object limit" appears while configuring cross-tenant access settings

+While configuring [cross-tenant access settings](cross-tenant-access-settings-b2b-collaboration.md), if you receive an error that says ΓÇ£Failure to update policy due to object limitΓÇ¥ you have reached the policy object limit of 25 KB. We're working toward increasing this limit. If you need to be able to calculate how close the current policy is to this limit, do the following:

+1. Open Microsoft Graph Explorer and run the following:

+ `GET https://graph.microsoft.com/beta/policies/crosstenantaccesspolicy`

+1. Copy the entire JSON response and save it as a txt file, for example `policyobject.txt`.

+1. Open PowerShell and run the following script, substituting the file location in the first line with your text file:

+```powershell

+$policy = Get-Content ΓÇ£C:\policyobject.txtΓÇ¥ | ConvertTo-Json

+$maxSize = 1024*25

+$size = [System.Text.Encoding]::UTF8.GetByteCount($policy)

+write-host "Remaining Bytes available in policy object"

+$maxSize - $size

+write-host "Is current policy within limits?"

+if ($size -le $maxSize) { return ΓÇ£validΓÇ¥ }; else { return ΓÇ£invalidΓÇ¥ }

+```

+## Users can no longer read email encrypted with Microsoft Rights Management Service (OME))

+When [configuring cross-tenant access settings](cross-tenant-access-settings-b2b-collaboration.md), if you block access to all apps by default, users will be unable to read emails encrypted with Microsoft Rights Management Service (also known as OME). To avoid this issue, we recommend configuring your outbound settings to allow your users to access this app ID: 00000012-0000-0000-c000-000000000000. If this is the only application you allow, access to all other apps will be blocked by default.

+[Get support for B2B collaboration](../fundamentals/active-directory-troubleshooting-support-howto.md)

+- [Conditional Access for B2B collaboration users](authentication-conditional-access.md)

+B2B collaboration is a capability of Azure AD External Identities that lets you collaborate with users and partners outside of your organization. With B2B collaboration, an external user is invited to sign in to your Azure AD organization using their own credentials. This B2B collaboration user can then access the apps and resources you want to share with them. A user object is created for the B2B collaboration user in the same directory as your employees. B2B collaboration user objects have limited privileges in your directory by default, and they can be managed like employees, added to groups, and so on. This article discusses the properties of this user object and ways to manage it.

+The following table describes B2B collaboration users based on how they authenticate (internally or externally) and their relationship to your organization (guest or member).

+

+- **External guest**: Most users who are commonly considered external users or guests fall into this category. This B2B collaboration user has an account in an external Azure AD organization or an external identity provider (such as a social identity), and they have guest-level permissions in the resource organization. The user object created in the resource Azure AD directory has a UserType of Guest.

+- **External member**: This B2B collaboration user has an account in an external Azure AD organization or an external identity provider (such as a social identity) and member-level access to resources in your organization. This scenario is common in organizations consisting of multiple tenants, where users are considered part of the larger organization and need member-level access to resources in the organizationΓÇÖs other tenants. The user object created in the resource Azure AD directory has a UserType of Member.

+- **Internal guest**: Before Azure AD B2B collaboration was available, it was common to collaborate with distributors, suppliers, vendors, and others by setting up internal credentials for them and designating them as guests by setting the user object UserType to Guest. If you have internal guest users like these, you can invite them to use B2B collaboration instead so they can use their own credentials, allowing their external identity provider to manage authentication and their account lifecycle.

+- **Internal member**: These users are generally considered employees of your organization. The user authenticates internally via Azure AD, and the user object created in the resource Azure AD directory has a UserType of Member.

+> [!IMPORTANT]

+> **As of November 1, 2021**, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. As part of this change, Microsoft will stop creating new, unmanaged ("viral") Azure AD accounts and tenants during B2B collaboration invitation redemption. We're enabling the email one-time passcode feature because it provides a seamless fallback authentication method for your guest users. However, if you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+## Invitation redemption

+B2B collaboration user accounts are the result of inviting guest users to collaborate by using the guest users' own credentials. When the invitation is initially sent to the guest user, an account is created in your tenant. This account doesnΓÇÖt have any credentials associated with it because authentication is performed by the guest user's identity provider. The **Issuer** property for the guest user account in your directory is set to the host's organization domain until the guest redeems their invitation. In the portal, the **Invitation accepted** property in the invited userΓÇÖs Azure AD portal profile will be set to **No** and querying for `externalUserState` using the Microsoft Graph API will return `Pending Acceptance`.

+

+After the B2B collaboration user accepts the invitation, the **Issuer** property is updated based on the userΓÇÖs identity provider.

+If the B2B collaboration user is using credentials from another Azure AD organization, the **Issuer** is **External Azure AD**.

+

+If the B2B collaboration user is using a Microsoft account or credentials from another external identity provider, the **Issuer** reflects the identity provider, for example **Microsoft Account**, **google.com**, or **facebook.com**.

+

+For external users who are using internal credentials, the **Issuer** property is set to the hostΓÇÖs organization domain. The **Directory synced** property is **Yes** if the account is homed in the organizationΓÇÖs on-premises Active Directory and synced with Azure AD, or **No** if the account is a cloud-only Azure AD account. The directory sync information is also available via the `onPremisesSyncEnabled` property in Microsoft Graph.

+### User Principal Name

+The user principal name for a B2B collaboration user object contains an #EXT# identifier.

+### User type

+- **Member**: This value indicates an employee of the host organization and a user in the organization's payroll. For example, this user expects to have access to internal-only sites. This user isn't considered an external collaborator.

+- **Guest**: This value indicates a user who isn't considered internal to the company, such as an external collaborator, partner, or customer. Such a user isn't expected to receive a CEO's internal memo or receive company benefits, for example.

+> [!NOTE]

+> The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property simply indicates the user's relationship to the host organization and allows the organization to enforce policies that depend on this property.

+This property indicates the userΓÇÖs primary identity provider. A user can have several identity providers, which can be viewed by selecting issuer in the userΓÇÖs profile or by querying the `onPremisesSyncEnabled` property via the Microsoft Graph API.

+> [!NOTE]

+> Issuer and UserType are independent properties. A value of issuer does not imply a particular value for UserType

+External Azure AD | This user is homed in an external organization and authenticates by using an Azure AD account that belongs to the other organization.

+Microsoft account | This user is homed in a Microsoft account and authenticates by using a Microsoft account.

+{hostΓÇÖs domain} | This user authenticates by using an Azure AD account that belongs to this organization.

+google.com | This user has a Gmail account and has signed up by using self-service to the other organization.

+facebook.com | This user has a Facebook account and has signed up by using self-service to the other organization.

+mail | This user has an email address that doesn't match with verified Azure AD or SAML/WS-Fed domains, and is not a Gmail address or a Microsoft account.

+phone | This user has an email address that doesn't match a verified Azure AD domain or a SAML/WS-Fed domain, and is not a Gmail address or Microsoft account.

+{issuer URI} | This user is homed in an external organization that doesn't use Azure Active Directory as their identity provider, but instead uses a SAML/WS-Fed-based identity provider. The issuer URI is shown when the issuer field is clicked.

+### Directory synced

+The **Directory synced** property indicates whether the user is being synced with on-premises Active Directory and is authenticated on-premises. This property is **Yes** if the account is homed in the organizationΓÇÖs on-premises Active Directory and synced with Azure AD, or **No** if the account is a cloud-only Azure AD account. In Microsoft Graph, the Directory synced property corresponds to `onPremisesSyncEnabled`.

+Typically, an Azure AD B2B user and guest user are synonymous. Therefore, an Azure AD B2B collaboration user is added as a user with **UserType** set to **Guest** by default. However, in some cases, the partner organization is a member of a larger organization to which the host organization also belongs. If so, the host organization might want to treat users in the partner organization as members instead of guests. Use the Azure AD B2B Invitation Manager APIs to add or invite a user from the partner organization to the host organization as a member.

+It's possible to convert UserType from Member to Guest and vice-versa by editing the user's profile in the Azure portal or by using PowerShell. However, the UserType property represents the user's relationship to the organization. Therefore, you should change this property only if the relationship of the user to the organization changes. If the relationship of the user changes, should the user principal name (UPN) change? Should the user continue to have access to the same resources? Should a mailbox be assigned?

+* [B2B collaboration user claims mapping](claims-mapping.md)

+ Title: B2B collaboration overview - Azure AD

+# B2B collaboration overview

+Azure Active Directory (Azure AD) B2B collaboration is a feature within External Identities that lets you invite guest users to collaborate with your organization. With B2B collaboration, you can securely share your company's applications and services with guest users from any other organization, while maintaining control over your own corporate data. Work safely and securely with external partners, large or small, even if they don't have Azure AD or an IT department.

+

+A simple invitation and redemption process lets partners use their own credentials to access your company's resources. You can also enable self-service sign-up user flows to let external users sign up for apps or resources themselves. Once the external user has redeemed their invitation or completed sign-up, they're represented in your directory as a [user object](user-properties.md). B2B collaboration user objects are typically given a user type of "guest" and can be identified by the #EXT# extension in their user principal name.

+Developers can use Azure AD business-to-business APIs to customize the invitation process or write applications like self-service sign-up portals. For licensing and pricing information related to guest users, refer to [Azure Active Directory External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/).

+> **As of November 1, 2021**, Microsoft no longer supports the redemption of invitations by creating unmanaged Azure AD accounts and tenants for B2B collaboration scenarios. At that time, we began rolling out a change to turn on the email one-time passcode feature for all existing tenants and enable it by default for new tenants. If you don't want to allow this feature to turn on automatically, you can [disable it](one-time-passcode.md#disable-email-one-time-passcode).

+- The partner uses their own identities and credentials, whether or not they have an Azure AD account.

+- You don't need to sync accounts or manage account lifecycles.

+## Manage external access with inbound and outbound settings

+B2B collaboration is enabled by default, but comprehensive admin settings let you control your B2B collaboration with external partners and organizations:

+- For B2B collaboration with other Azure AD organizations, you can use [cross-tenant access settings](cross-tenant-access-overview.md) to manage inbound and outbound B2B collaboration and scope access to specific users, groups, and applications. You can set a default configuration that applies to all external organizations, and then create individual, organization-specific settings as needed. Using cross-tenant access settings, you can also trust multi-factor (MFA) and device claims (compliant claims and hybrid Azure AD joined claims) from other Azure AD organizations.

+- You can use [external collaboration settings](external-collaboration-settings-configure.md) to limit who can invite external users, allow or block B2B specific domains, and set restrictions on guest user access to your directory.

+## Allow self-service sign-up

+With a self-service sign-up user flow, you can create a sign-up experience for external users who want to access your apps. As part of the sign-up flow, you can provide options for different social or enterprise identity providers, and collect information about the user. Learn about [self-service sign-up and how to set it up](self-service-sign-up-overview.md).

+You can also use [API connectors](api-connectors-overview.md) to integrate your self-service sign-up user flows with external cloud systems. You can connect with custom approval workflows, perform identity verification, validate user-provided information, and more.

+

+You can use authentication and authorization policies to protect your corporate content. Conditional Access policies, such as multi-factor authentication, can be enforced:

+- [Understand the invitation redemption process](redemption-experience.md)

+- [Conditional Access for B2B collaboration users](authentication-conditional-access.md)

+- [Enable B2B external collaboration and manage who can invite guests](external-collaboration-settings-configure.md)

+- [What are External Identities in Azure Active Directory?](external-identities-overview.md)

+- [Conditional Access for B2B collaboration users](authentication-conditional-access.md)

+- [Enable B2B external collaboration and manage who can invite guests](external-collaboration-settings-configure.md)

+- [Conditional Access for B2B collaboration users](authentication-conditional-access.md)

+- [Enable B2B external collaboration and manage who can invite guests](external-collaboration-settings-configure.md)

+Once youΓÇÖve done those things, you're ready to move into controlled collaboration. This article will guide you to move all your external collaboration into [Azure Active Directory B2B collaboration](../external-identities/what-is-b2b.md) (Azure AD B2B). Azure AD B2B is a feature of [Azure AD External Identities](../external-identities/external-identities-overview.md).

+* The most restrictive setting is to allow only administrators and those users granted the [guest inviter role](../external-identities/external-collaboration-settings-configure.md) to invite guests.

+| Mid-tier/Daemon services|Services running in on-premises environments normally use AD service accounts or group Managed Service Accounts (gMSA) to run. These apps will then inherit the permissions of the service account.| Azure AD provides [managed identities](../managed-identities-azure-resources/index.yml) to run other workloads in the cloud. The lifecycle of these identities is managed by Azure AD and is tied to the resource provider and it can't be used for other purposes to gain backdoor access.|

+- **External Users** - external collaboration can happen organically in the enterprise with services like Teams, Power BI, SharePoint Online, and Azure Information Protection. If you have explicit constraints to control user-initiated external collaboration, it is recommended you enable external users by using [Azure AD Entitlement management](../governance/entitlement-management-overview.md) or a controlled operation such as through your help desk. If you don't want to allow organic external collaboration for services, you can [block members from inviting external users completely](../external-identities/external-collaboration-settings-configure.md). Alternatively, you can also [allow or block specific domains](../external-identities/allow-deny-list.md) in external user invitations.

+1. If **Only allow predefined values to be assigned** is **Yes**, click **Add value** to add predefined values.

+ An active value is available for assignment to objects. A value that is not active is defined, but not yet available for assignment.

+ 

+1. When finished, click **Save**.

+#### Add a custom security attribute with a list of predefined values

+Use the [Create customSecurityAttributeDefinition](/graph/api/directory-post-customsecurityattributedefinitions) API to add a new custom security attribute definition with a list of predefined values.

+- Attribute set: `Engineering`

+- Attribute: `Project`

+- Attribute data type: Collection of Strings

+- Predefined values: `Alpine`, `Baker`, `Cascade`

+```http

+POST https://graph.microsoft.com/beta/directory/customSecurityAttributeDefinitions

+{

+ "attributeSet": "Engineering",

+ "description": "Active projects for user",

+ "isCollection": true,

+ "isSearchable": true,

+ "name": "Project",

+ "status": "Available",

+ "type": "String",

+ "usePreDefinedValuesOnly": true,

+ "allowedValues": [

+ {

+ "id": "Alpine",

+ "isActive": true

+ },

+ {

+ "id": "Baker",

+ "isActive": true

+ },

+ {

+ "id": "Cascade",

+ "isActive": true

+ }

+ ]

+}

+```

+#### Update the predefined values for a custom security attribute

+Use the [Update customSecurityAttributeDefinition](/graph/api/customsecurityattributedefinition-update) API to update the predefined values for a custom security attribute definition.

+- Attribute set: `Engineering`

+- Attribute: `Project`

+- Attribute data type: Collection of Strings

+- Update predefined value: `Baker`

+- New predefined value: `Skagit`

+> [!NOTE]

+> For this request, you must add the **OData-Version** header and assign it the value `4.01`.

+```http

+PATCH https://graph.microsoft.com/beta/directory/customSecurityAttributeDefinitions/Engineering_Project

+{

+ "allowedValues@delta": [

+ {

+ "id": "Baker",

+ "isActive": false

+ },

+ {

+ "id": "Skagit",

+ "isActive": true

+ }

+ ]

+}

+```

+* Define [access control policies](../external-identities/authentication-conditional-access.md) to control access to resources.

+| [Conditional access for B2B](../external-identities/authentication-conditional-access.md)| Describes how conditional access and MFA work for guest users.|

+* [Azure portal ](../external-identities/add-users-administrator.md) End users given the [Guest Inviter role](../external-identities/external-collaboration-settings-configure.md) can sign in to the Azure portal and invite guest users from the Users menu in Azure Active Directory.

+* [Programmatic (PowerShell, Graph API)](../external-identities/customize-invitation-api.md) End users given the [Guest Inviter role](../external-identities/external-collaboration-settings-configure.md) can invite guest users via PowerShell or Graph API.

+[Azure Active Directory B2B collaboration](../external-identities/what-is-b2b.md) (Azure AD B2B) is a feature of [External Identities](../external-identities/external-collaboration-settings-configure.md) that enables collaboration with other organizations and individuals. It enables the secure onboarding of guest users into your Azure AD tenant without having to manage their credentials. External users bring their identity and credentials with them from an external identity provider (IdP), so they donΓÇÖt have to remember a new credential.

+**Guests can invite** | Setting this option to **Yes** allows guests to invite other guests. To learn more, see [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md).

+**Members can invite** | Setting this option to **Yes** allows non-admin members of your directory to invite guests. To learn more, see [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md).

+**Admins and users in the guest inviter role can invite** | Setting this option to **Yes** allows admins and users in the guest inviter role to invite guests. When you set this option to **Yes**, users in the guest inviter role will still be able to invite guests, regardless of the **Members can invite** setting. To learn more, see [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md).

+Azure Government tenants using the B2B collaboration features can now invite users that have a Microsoft or Google account. To find out if your tenant can use these capabilities, follow the instructions at [How can I tell if B2B collaboration is available in my Azure US Government tenant?](../external-identities/b2b-government-national-clouds.md#how-can-i-tell-if-b2b-collaboration-is-available-in-my-azure-us-government-tenant).

+The Azure AD B2B collaboration features are now available between some Azure Government tenants. To find out if your tenant is able to use these capabilities, follow the instructions at [How can I tell if B2B collaboration is available in my Azure US Government tenant?](../external-identities/b2b-government-national-clouds.md#how-can-i-tell-if-b2b-collaboration-is-available-in-my-azure-us-government-tenant).

+ **Users not in your directory** refers to users who are in another Azure AD directory or domain. These users may not have yet been invited into your directory. Azure AD directories must be configured to be allow invitations in **Collaboration restrictions**. For more information, see [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md).

+- For more information about Azure AD B2B external collaboration settings, see [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md).

+Azure AD can [automatically create accounts in AD for guest users](../external-identities/hybrid-cloud-to-on-premises.md) as needed, enabling business guests to access on-premises AD-integrated applications without needing another password. Organizations can set up [multi-factor authentication (MFA) policies for guest user](../external-identities/authentication-conditional-access.md)s so MFA checks are done during application proxy authentication. Also, any [access reviews](../governance/manage-guest-access-with-access-reviews.md) that are done on cloud B2B users apply to on-premises users. For example, if the cloud user is deleted through lifecycle management policies, the on-premises user is also deleted.

+ 

+Before a client or service can access Microsoft Graph, it must be [trusted by the Microsoft identity platform.](/develop/quickstart-register-app)

+The Easy Button client must also be registered in Azure AD, before it is allowed to establish a trust between each SAML SP instance of a BIG-IP published application, and Azure AD as the SAML IdP.

+ 

+These are general and service account properties. The **Configuration Properties** tab creates up a new application config and SSO object that will be managed through the BIG-IPΓÇÖs Guided Configuration UI. This configuration can then be reused for publishing more applications through the Easy Button template.

+Consider the **Azure Service Account Details** be the BIG-IP client application you registered in your Azure AD tenant earlier. This section allows the BIG-IP to programmatically register a SAML application directly in your tenant, along with the other properties you would normally configure manually in the portal. Easy Button will do this for every BIG-IP APM service being published and enabled for SHA.

+ 

+The optional **Security Settings** specify whether Azure AD should encrypt issued SAML assertions. Encrypting assertions between Azure AD and the BIG-IP APM provides additional assurance that the content tokens canΓÇÖt be intercepted, and personal or corporate data be compromised.

+3. From the **Assertion Decryption Private Key** list, select **Create New**

+

+ 

+4. Select **OK**. This opens the **Import SSL Certificate and Keys** dialog in a new tab

+6. Select **PKCS 12 (IIS) ** to import your certificate and private key. Once provisioned close the browser tab to return to the main tab.

+ 

+6. Check **Enable Encrypted Assertion**

+7. If you have enabled encryption, select your certificate from the **Assertion Decryption Private Key** list. This is the private key for the certificate that BIG-IP APM will use to decrypt Azure AD assertions

+8. If you have enabled encryption, select your certificate from the **Assertion Decryption Certificate** list. This is the certificate that BIG-IP will upload to Azure AD for encrypting the issued SAML assertions.

+ 

+3. Select the refresh icon next to the **Signing Key** and **Signing Certificate** to locate the certificate you imported earlier

+

+5. Enter the certificateΓÇÖs password in **Signing Key Passphrase**

+6. Enable **Signing Option** (optional). This ensures that BIG-IP only accepts tokens and claims that are signed by Azure AD

+ 

+CA policies are enforced post Azure AD pre-authentication, to control access based on device, application, location, and risk signals.

+The **Available Policies** view, by default, will list all CA policies that do not include user based actions.

+The **Selected Policies** view, by default, displays all policies targeting All cloud apps. These policies cannot be deselected or moved to the Available Policies list as they are enforced at a tenant level.

+1. Select the desired policy in the **Available Policies** list

+2. Select the right arrow and move it to the **Selected Policies** list

+Selected policies should either have an **Include** or **Exclude** option checked. If both options are checked, the selected policy is not enforced.

+ 

+1. Enter **Destination Address**. This is any available IPv4/IPv6 address that the BIG-IP can use to receive client traffic. A corresponding record should also exist in DNS, enabling clients to resolve the external URL of your BIG-IP published application to this IP.

+ 

+ 

+This last step provides a breakdown of your configurations. Select **Deploy** to commit all settings and verify that the application now exists in your tenants list of ΓÇÿEnterprise applications.

+From a browser, **connect** to the applicationΓÇÖs external URL or select the **applicationΓÇÖs icon** in the [Microsoft MyApps portal](https://myapplications.microsoft.com/). After authenticating against Azure AD, youΓÇÖll be redirected to the BIG-IP virtual server for the application and automatically signed in through SSO.

+ 

+There may be cases where the Guided Configuration templates lacks the flexibility to achieve more specific requirements. For those scenarios, see [Advanced Configuration for headers-based SSO](./f5-big-ip-header-advanced.md).

+Alternatively, the BIG-IP gives you the option to disable **Guided ConfigurationΓÇÖs strict management mode**. This allows you to manually tweak your configurations, even though bulk of your configurations are automated through the wizard-based templates.

+You can navigate to **Access > Guided Configuration** and select the **small padlock icon** on the far right of the row for your applicationsΓÇÖ configs.

+ 

+At that point, changes via the wizard UI are no longer possible, but all BIG-IP objects associated with the published instance of the application will be unlocked for direct management.

+> Re-enabling strict mode and deploying a configuration will overwrite any settings performed outside of the Guided Configuration UI, therefore we recommend the advanced configuration method for production services.

+ 

+Before a client or service can access Microsoft Graph, it must be [trusted by the Microsoft identity platform.](/develop/quickstart-register-app)

+The Easy Button client must also be registered in Azure AD, before it is allowed to establish a trust between each SAML SP instance of a BIG-IP published application, and Azure AD as the SAML IdP.

+ 

+These are general and service account properties. The **Configuration Properties** tab creates up a new application config and SSO object that will be managed through the BIG-IPΓÇÖs Guided Configuration UI. This configuration can then be reused for publishing more applications through the Easy Button template.

+Consider the **Azure Service Account Details** be the BIG-IP client application you registered in your Azure AD tenant earlier. This section allows the BIG-IP to programmatically register a SAML application directly in your tenant, along with the other properties you would normally configure manually in the portal. Easy Button will do this for every BIG-IP APM service being published and enabled for SHA.

+The optional **Security Settings** specify whether Azure AD should encrypt issued SAML assertions. Encrypting assertions between Azure AD and the BIG-IP APM provides additional assurance that the content tokens canΓÇÖt be intercepted, and personal or corporate data be compromised.

+3. From the **Assertion Decryption Private Key** list, select **Create New**

+

+ 

+4. Select **OK**. This opens the **Import SSL Certificate and Keys** dialog in a new tab

+6. Select **PKCS 12 (IIS) ** to import your certificate and private key. Once provisioned close the browser tab to return to the main tab.

+ 

+6. Check **Enable Encrypted Assertion**

+8. If you have enabled encryption, select your certificate from the **Assertion Decryption Private Key** list. This is the private key for the certificate that BIG-IP APM will use to decrypt Azure AD assertions

+10. If you have enabled encryption, select your certificate from the **Assertion Decryption Certificate** list. This is the certificate that BIG-IP will upload to Azure AD for encrypting the issued SAML assertions.

+ 

+3. Select the refresh icon next to the **Signing Key** and **Signing Certificate** to locate the certificate you imported earlier

+

+5. Enter the certificateΓÇÖs password in **Signing Key Passphrase**

+6. Enable **Signing Option** (optional). This ensures that BIG-IP only accepts tokens and claims that are signed by Azure AD

+ 

+ 

+ 

+CA policies are enforced post Azure AD pre-authentication, to control access based on device, application, location, and risk signals.

+The **Available Policies** view, by default, will list all CA policies that do not include user based actions.

+The **Selected Policies** view, by default, displays all policies targeting All cloud apps. These policies cannot be deselected or moved to the Available Policies list as they are enforced at a tenant level.

+1. Select the desired policy in the **Available Policies** list

+2. Select the right arrow and move it to the **Selected Policies** list

+Selected policies should either have an **Include** or **Exclude** option checked. If both options are checked, the selected policy is not enforced.

+ 

+1. Enter **Destination Address**. This is any available IPv4/IPv6 address that the BIG-IP can use to receive client traffic. A corresponding record should also exist in DNS, enabling clients to resolve the external URL of your BIG-IP published application to this IP.

+ 

+ 

+ 

+There may be cases where the Guided Configuration templates lacks the flexibility to achieve more specific requirements. For those scenarios, see [Advanced Configuration for kerberos-based SSO](./f5-big-ip-kerberos-advanced.md).

+Alternatively, the BIG-IP gives you the option to disable **Guided ConfigurationΓÇÖs strict management mode**. This allows you to manually tweak your configurations, even though bulk of your configurations are automated through the wizard-based templates.

+You can navigate to **Access > Guided Configuration** and select the **small padlock icon** on the far right of the row for your applicationsΓÇÖ configs.

+

+ 

+At that point, changes via the wizard UI are no longer possible, but all BIG-IP objects associated with the published instance of the application will be unlocked for direct management.

+[!NOTE] Re-enabling strict mode and deploying a configuration will overwrite any settings performed outside of the Guided Configuration UI, therefore we recommend the advanced configuration method for production services.

+You can refer to our [App Proxy guidance](../app-proxy/application-proxy-back-end-kerberos-constrained-delegation-how-to.md) to validate an IIS application is configured appropriately for KCD. F5ΓÇÖs article on [how the APM handles Kerberos SSO](https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-single-sign-on-concepts-configuration/kerberos-single-sign-on-method.html) is also a valuable resource.

+### Log analysis

+See [BIG-IP APM variable assign examples]( https://devcentral.f5.com/s/articles/apm-variable-assign-examples-1107) and [F5 BIG-IP session variables reference]( https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-access-policy-manager-visual-policy-editor/session-variables.html) for more info.

+ 

+- An [SSL certificate](./f5-bigip-deployment-guide.md#ssl-profile) for publishing services over HTTPS, or use default certificates while testing

+- A user directory that supports LDAP, such as Windows Active Directory Lightweight Directory Services (AD LDS), OpenLDAP etc.

+Before a client or service can access Microsoft Graph, it must be [trusted by the Microsoft identity platform.](/develop/quickstart-register-app)

+The Easy Button client must also be registered in Azure AD, before it is allowed to establish a trust between each SAML SP instance of a BIG-IP published application, and Azure AD as the SAML IdP.

+ Once provisioned, the certificate can be used for every application published through Easy Button. You can also choose to upload a separate certificate for individual applications.

+ 

+ 

+ 

+ 

+These are general and service account properties. The **Configuration Properties** tab creates up a new application config and SSO object that will be managed through the BIG-IPΓÇÖs Guided Configuration UI. This configuration can then be reused for publishing more applications through the Easy Button template.

+Consider the **Azure Service Account Details** be the BIG-IP client application you registered in your Azure AD tenant earlier. This section allows the BIG-IP to programmatically register a SAML application directly in your tenant, along with the other properties you would normally configure manually in the portal. Easy Button will do this for every BIG-IP APM service being published and enabled for SHA.

+ 

+ 

+ The optional **Security Settings** specify whether Azure AD should encrypt issued SAML assertions. Encrypting assertions between Azure AD and the BIG-IP APM provides additional assurance that the content tokens canΓÇÖt be intercepted, and personal or corporate data be compromised.

+3. From the **Assertion Decryption Private Key** list, select **Create New**

+

+ 

+4. Select **OK**. This opens the **Import SSL Certificate and Keys** dialog in a new tab

+6. Select **PKCS 12 (IIS)** to import your certificate and private key. Once provisioned close the browser tab to return to the main tab.

+ 

+6. Check **Enable Encrypted Assertion**.

+8. If you have enabled encryption, select your certificate from the **Assertion Decryption Private Key** list. This is the private key for the certificate that BIG-IP APM will use to decrypt Azure AD assertions.

+9. If you have enabled encryption, select your certificate from the **Assertion Decryption Certificate** list. This is the certificate that BIG-IP will upload to Azure AD for encrypting the issued SAML assertions.

+ 

+ 

+ 

+3. Select the refresh icon next to the **Signing Key** and **Signing Certificate** to locate the certificate you imported earlier

+

+5. Enter the certificateΓÇÖs password in **Signing Key Passphrase**

+6. Enable **Signing Option** (optional). This ensures that BIG-IP only accepts tokens and claims that are signed by Azure AD

+ 

+ 

+ 

+ 

+ 

+CA policies are enforced post Azure AD pre-authentication, to control access based on device, application, location, and risk signals.

+The **Available Policies** view, by default, will list all CA policies that do not include user based actions.

+The **Selected Policies** view, by default, displays all policies targeting All cloud apps. These policies cannot be deselected or moved to the Available Policies list as they are enforced at a tenant level.

+1. Select the desired policy in the **Available Policies** list.

+2. Select the right arrow and move it to the **Selected Policies** list.

+Selected policies should either have an **Include** or **Exclude** option checked. If both options are checked, the selected policy is not enforced.

+ 

+1. Enter **Destination Address**. This is any available IPv4/IPv6 address that the BIG-IP can use to receive client traffic. A corresponding record should also exist in DNS, enabling clients to resolve the external URL of your BIG-IP published application to this IP.

+ 

+ 

+ 

+This last step provides a breakdown of your configurations. Select **Deploy** to commit all settings and verify that the application now exists in your tenants list of ΓÇÿEnterprise applications.

+From a browser, **connect** to the applicationΓÇÖs external URL or select the **applicationΓÇÖs icon** in the [Microsoft MyApps portal](https://myapplications.microsoft.com/). After authenticating against Azure AD, youΓÇÖll be redirected to the BIG-IP virtual server for the application and automatically signed in through SSO.

+ 

+There may be cases where the Guided Configuration templates lacks the flexibility to achieve more specific requirements.

+The BIG-IP gives you the option to disable **Guided ConfigurationΓÇÖs strict management mode**. This allows you to manually tweak your configurations, even though bulk of your configurations are automated through the wizard-based templates.

+You can navigate to **Access > Guided Configuration** and select the **small padlock icon** on the far right of the row for your applicationsΓÇÖ configs.

+ 

+At that point, changes via the wizard UI are no longer possible, but all BIG-IP objects associated with the published instance of the application will be unlocked for direct management.

+> [!NOTE]

+> Re-enabling strict mode and deploying a configuration overwrites any settings performed outside of the Guided Configuration UI. We recommend the advanced configuration method for production services.

+ 

+This last step provides a breakdown of your configurations. Select **Deploy** to commit all settings and verify that the application now exists in your tenants list of ΓÇÿEnterprise applications.

+There may be cases where the Guided Configuration templates lack the flexibility to achieve more specific requirements. For those scenarios, see [Advanced Configuration for headers-based SSO](./f5-big-ip-header-advanced.md). Alternatively, the BIG-IP gives the option to disable **Guided ConfigurationΓÇÖs strict management mode**. This allows you to manually tweak your configurations, even though bulk of your configurations are automated through the wizard-based templates.

+For more information, see [Conditional Access for B2B collaboration users](../external-identities/authentication-conditional-access.md).

+ Title: Cross-tenant access activity workbook in Azure AD | Microsoft Docs

+description: Learn how to use the cross-tenant access activity workbook.

+documentationcenter: ''

+editor: ''

+# Cross-tenant access activity workbook

+As an IT administrator, you want insights into how your users are collaborating with other organizations. The cross-tenant access activity workbook helps you understand which external users are accessing resources in your organization, and which organizationsΓÇÖ resources your users are accessing. This workbook combines all your organizationΓÇÖs inbound and outbound collaboration into a single view.

+This article provides you with an overview of this workbook.

+## Description

+

+Tenant administrators who are making changes to policies governing cross-tenant access can use this workbook to visualize and review existing access activity patterns before making policy changes. For example, you can identify the apps your users are accessing in external organizations so that you don't inadvertently block critical business processes. Understanding how external users access resources in your tenant (inbound access) and how users in your tenant access resources in external tenants (outbound access) will help ensure you have the right cross-tenant policies in place.

+For more information, see the [Azure AD External Identities documentation](../external-identities/index.yml).

+## Sections

+This workbook has four sections:

+- All inbound and outbound activity by tenant ID

+- Sign-in status summary by tenant ID for inbound and outbound collaboration

+- Applications accessed for inbound and outbound collaboration by tenant ID

+- Individual users for inbound and outbound collaboration by tenant ID

+

+## Filters

+This workbook supports multiple filters:

+- Time range (up to 90 days)

+- External tenant ID

+- User principal name

+- Application

+- Status of the sign-in (success or failure)

+

+## Best practices

+Use this workbook to:

+- Get the information you need to manage your cross-tenant access settings effectively, without breaking legitimate collaborations

+- Identify all inbound sign-ins from external Azure AD organizations

+- Identify all outbound sign-ins by your users to external Azure AD organizations

+## Next steps

+- [How to use Azure AD workbooks](howto-use-azure-monitor-workbooks.md)

+Configuration names in Azure Automation must be limited to no more than 100 characters.

+Review the code below and note the presence of two node [configurations](/powershell/dsc/configurations/configurations): `IsPresent` and `IsNotPresent`. This configuration calls one resource in each node block: the [nxPackage resource](/powershell/dsc/reference/resources/linux/lnxpackageresource). This resource manages the presence of the **apache2** package. Configuration names in Azure Automation must be limited to no more than 100 characters.

+Then, in a text editor, copy the following code to a local file and name it `LinuxConfig.ps1`:

+> [Compose DSC configurations](./compose-configurationwithcompositeresources.md)

+> Configuration names in Azure Automation must be limited to no more than 100 characters.

+>

+## December 2021

+### New scripts added for Azure VM management based on Azure Monitor Alert

+**Type:** New feature

+New scripts are added to the Azure Automation [GitHub repository](https://github.com/azureautomation) to address one of Azure Automation's key scenarios of VM management based on Azure Monitor alert. For more information, see [Trigger runbook from Azure alert](/azure/automation/automation-create-alert-triggered-runbook).

+- Stop-Azure-VM-On-Alert

+- Restart-Azure-VM-On-Alert

+- Delete-Azure-VM-On-Alert

+- ScaleDown-Azure-VM-On-Alert

+- ScaleUp-Azure-VM-On-Alert

+- [Azure Resiliency whitepaper](https://azure.microsoft.com/resources/resilience-in-azure-whitepaper/)

+- [Azure Resiliency whitepaper](https://azure.microsoft.com/resources/resilience-in-azure-whitepaper/)

+ a. Choose the **virtual network** and **subnet** that you want to connect to your Azure-Arc enabled server.

+ - If the Redis server exceeds the available bandwidth, clients requests could time out because the server can't push data to the client fast enough. Check "Cache Read" and "Cache Write" metrics to see how much server-side bandwidth is being used. If your Redis server is exceeding available network bandwidth, you should consider scaling up to a larger cache size with higher network bandwidth.

+- In some cases, such as scaling or migrating your cache to a different cluster, the underlying IP address of the cache can change. The DNS record for the cache changes and is transparent to most applications. However, if you use an IP address to configure the connection to your cache, or to configure NSGs, or firewalls allowing traffic to the cache, your application might have trouble connecting sometime after that the DNS record updates.

+- When you scale a **Standard** cache to a larger size or tier, or a **Premium** cache is scaled to a larger size, all data is typically preserved. When you scale a Standard or Premium cache to a smaller size, data can be lost if the data size exceeds the new smaller size when it's scaled down. If data is lost when scaling down, keys are evicted using the [allkeys-lru](https://redis.io/topics/lru-cache) eviction policy.

+- When you scale to a pricing tier with a lower `databases` limit than the current tier:

+- When you scale to a pricing tier with the same or higher `databases` limit than the current tier, your `databases` setting is kept and no data is lost.

+With geo-replication configured, you might notice that you canΓÇÖt scale a cache or change the shards in a cluster. A geo-replication link between two caches prevents you from scaling operation or changing the number of shards in a cluster. You must unlink the cache to issue these commands. For more information, see [Configure Geo-replication](cache-how-to-geo-replication.md).

+ - For more information about B2B collaboration limitations in Azure Government and to find out if B2B collaboration is available in your Azure Government tenant, see [Azure AD B2B in government and national clouds](../active-directory/external-identities/b2b-government-national-clouds.md).

+| Clipperton Island | | | | Γ£ô | Γ£ô |

+| Dominican Republic | | | Γ£ô | Γ£ô | Γ£ô |

+| Turks & Caicos Islands | | | | Γ£ô | Γ£ô |

+| U.S. Outlying Islands | | | | Γ£ô | Γ£ô |

+| United States | Γ£ô | Γ£ô | Γ£ô | Γ£ô | Γ£ô |

+| South Korea | | | | Γ£ô | Γ£ô |

+| Isle of Man | | Γ£ô | Γ£ô | Γ£ô | Γ£ô |

+| Congo (DRC) | | | Γ£ô | Γ£ô | Γ£ô |

+| Cape Verde | Γ£ô | | | Γ£ô |

+> [!NOTE]

+> If you rename your Application Insights resource after migrating to workspace-based model, the Application Insights Logs tab will no longer show the telemetry collected before renaming. You will be able to see all data (old and new) on the Logs tab of the associated Log Analytics resource.

+| [InstallDependencyAgent-Windows.exe](https://aka.ms/dependencyagentwindows) | Windows | 9.10.13.19190 | 0882504FE5828C4C4BA0A869BD9F6D5B0020A52156DDBD21D55AAADA762923C4 |

+| [InstallDependencyAgent-Linux64.bin](https://aka.ms/dependencyagentlinux) | Linux | 9.10.13.19190 | 7D90A2A7C6F1D7FB2BCC274ADC4C5D6C118E832FF8A620971734AED4F446B030 |

+

+ > [!WARNING]

+ > Make sure the format of the JSON file is exactly as described above. Especially with the URLs enclosed in double quotes (").

+> | virtualclusters | No | No | No |

+To learn about Azure Resource Manager templates (ARM templates), see the [ARM template overview](../templates/overview.md). To learn about Bicep, see [Bicep overview](../bicep/overview.md).

+* **declarative syntax** - Syntax that lets you state "Here's what I intend to create" without having to write the sequence of programming commands to create it. ARM templates and Bicep files are examples of declarative syntax. In those files, you define the properties for the infrastructure to deploy to Azure.

+* **ARM template** - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group, subscription, management group, or tenant. The template can be used to deploy the resources consistently and repeatedly. See [Template deployment overview](../templates/overview.md).

+* **Bicep file** - A file for declaratively deploying Azure resources. Bicep is a language that's been designed to provide the best authoring experience for infrastructure as code solutions in Azure. See [Bicep overview](../bicep/overview.md).

+ You may be wondering, "Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?"

+ The resource group stores metadata about the resources. When you specify a location for the resource group, you're specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.

+ If a resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them. This condition doesn't apply to global resources like Azure Content Delivery Network, Azure DNS, Azure Traffic Manager, and Azure Front Door.

+* Distributed across Availability Zones (and regions) in locations that have multiple Availability Zones.

+> - [Microsoft.Chaos](#microsoftchaos)

+> - [Microsoft.Communication](#microsoftcommunication)

+> - [Microsoft.IoTFirmwareDefense](#microsoftiotfirmwaredefense)

+> - [Microsoft.Scheduler](#microsoftscheduler)

+> | prometheusRuleGroups | Yes | Yes |

+> | deletedConfigurationStores | No | No |

+> | accounts / devices / sensors | No | No |

+> | accounts / solutioninstances | No | No |

+> | accounts / solutions | No | No |

+> | accounts / targets | No | No |

+> | clusters / arcSettings | No | No |

+> | clusters / arcSettings / extensions | No | No |

+> | galleryimages | No | No |

+> | networkinterfaces | No | No |

+> | virtualharddisks | No | No |

+> | virtualnetworks | No | No |

+> | savingsPlans | No | No |

+## Microsoft.Chaos

+> [!div class="mx-tableFixed"]

+> | Resource type | Supports tags | Tag in cost report |

+> | - | -- | -- |

+> | artifactSetDefinitions | No | No |

+> | artifactSetSnapshots | No | No |

+> | chaosExperiments | Yes | Yes |

+> | chaosProviderConfigurations | No | No |

+> | chaosTargets | No | No |

+> | experiments | Yes | Yes |

+> | targets | No | No |

+> | accounts / networkSecurityPerimeterAssociationProxies | No | No |

+> | capacityReservationGroups | Yes | Yes |

+> | capacityReservationGroups / capacityReservations | Yes | Yes |

+> | restorePointCollections / restorePoints / diskRestorePoints | No | No |

+> | virtualMachineScaleSets / virtualMachines / extensions | No | No |

+## Microsoft.Communication

+> [!div class="mx-tableFixed"]

+> | Resource type | Supports tags | Tag in cost report |

+> | - | -- | -- |

+> | CommunicationServices | No | No |

+> | CommunicationServices / eventGridFilters | No | No |

+> | EmailServices | No | No |

+> | EmailServices / Domains | No | No |

+> | registeredSubscriptions | No | No |

+> | partnerDestinations | Yes | Yes |

+> | instances / chambers | No | No |

+> | instances / chambers / accessProfiles | No | No |

+> | instances / chambers / workloads | No | No |

+> | instances / consortiums | No | No |

+> | provisionedClusters / agentPools | No | No |

+> | provisionedClusters / hybridIdentityMetadata | No | No |

+## Microsoft.IoTFirmwareDefense

+> [!div class="mx-tableFixed"]

+> | Resource type | Supports tags | Tag in cost report |

+> | - | -- | -- |

+> | firmwareGroups | No | No |

+> | firmwareGroups / firmwares | No | No |

+> | namespaces | No | No |

+> | privateStores / fetchAllSubscriptionsInTenant | No | No |

+> | customIpPrefixes | Yes | Yes |

+> | dscpConfigurations | Yes | Yes |

+> | ipAllocations | Yes | Yes |

+> | networkManagers | Yes | Yes |

+> | networkVirtualAppliances | Yes | Yes |

+> | securityPartnerProviders | Yes | Yes |

+> | vpnServerConfigurations | Yes | Yes |

+> | accounts / kafkaConfigurations | No | No |

+## Microsoft.Scheduler

+> [!div class="mx-tableFixed"]

+> | Resource type | Supports tags | Tag in cost report |

+> | - | -- | -- |

+> | jobcollections | Yes | Yes |

+> | assessments / governanceAssignments | No | No |

+> | attackPaths | No | No |

+> | dataScanners | Yes | Yes |

+> | governanceRules | No | No |

+> | dryruns | No | No |

+> | instancePools | Yes | Yes |

+> | managedInstances / administrators | No | No |

+> | managedInstances / databases / backupLongTermRetentionPolicies | No | No |

+> | managedInstances / sqlAgent | No | No |

+> | servers / advisors | No | No |

+> | servers / auditingSettings | No | No |

+> | servers / databases / advisors | No | No |

+> | servers / databases / auditingSettings | No | No |

+> | servers / databases / backupLongTermRetentionPolicies | No | No |

+> | servers / databases / backupShortTermRetentionPolicies | No | No |

+> | servers / databases / dataMaskingPolicies | No | No |

+> | servers / databases / extensions | No | No |

+> | servers / databases / securityAlertPolicies | No | No |

+> | servers / databases / syncGroups | No | No |

+> | servers / databases / syncGroups / syncMembers | No | No |

+> | servers / databases / transparentDataEncryption | No | No |

+> | servers / databases / workloadGroups | No | No |

+> | servers / elasticpools | Yes | Yes |

+> | servers / failoverGroups | No | No |

+> | servers / jobAgents | Yes | Yes |

+> | servers / jobAgents / jobs | No | No |

+> | servers / jobAgents / jobs / steps | No | No |

+> | servers / jobAgents / jobs / executions | No | No |

+> | servers / virtualNetworkRules | No | No |

+> | dataMovers | Yes | Yes |

+> | dataMovers / agents | No | No |

+> | dataMovers / endpoints | No | No |

+> | dataMovers / projects | No | No |

+> | dataMovers / projects / jobDefinitions | No | No |

+> | dataMovers / projects / jobDefinitions / jobRuns | No | No |

+> - [Microsoft.Chaos](#microsoftchaos)

+> - [Microsoft.Communication](#microsoftcommunication)

+> - [Microsoft.IoTFirmwareDefense](#microsoftiotfirmwaredefense)

+> - [Microsoft.Scheduler](#microsoftscheduler)

+> | prometheusRuleGroups | Yes |

+> | deletedConfigurationStores | No |

+> | accounts / devices / sensors | No |

+> | accounts / solutioninstances | No |

+> | accounts / solutions | No |

+> | accounts / targets | No |

+> | clusters / arcSettings | No |

+> | clusters / arcSettings / extensions | No |

+> | galleryimages | No |

+> | networkinterfaces | No |

+> | virtualharddisks | No |

+> | virtualnetworks | No |

+> | savingsPlans | No |

+## Microsoft.Chaos

+> [!div class="mx-tableFixed"]

+> | Resource type | Complete mode deletion |

+> | - | -- |

+> | artifactSetDefinitions | No |

+> | artifactSetSnapshots | No |

+> | chaosExperiments | Yes |

+> | chaosProviderConfigurations | No |

+> | chaosTargets | No |

+> | experiments | Yes |

+> | targets | No |

+> | accounts / networkSecurityPerimeterAssociationProxies | No |

+> | capacityReservationGroups | Yes |

+> | capacityReservationGroups / capacityReservations | Yes |

+> | restorePointCollections / restorePoints / diskRestorePoints | No |

+> | virtualMachineScaleSets / virtualMachines / extensions | No |

+## Microsoft.Communication

+> [!div class="mx-tableFixed"]

+> | Resource type | Complete mode deletion |

+> | - | -- |

+> | CommunicationServices | No |

+> | CommunicationServices / eventGridFilters | No |

+> | EmailServices | No |

+> | EmailServices / Domains | No |

+> | registeredSubscriptions | No |

+> | partnerDestinations | Yes |

+> | instances / chambers | No |

+> | instances / chambers / accessProfiles | No |

+> | instances / chambers / workloads | No |

+> | instances / consortiums | No |

+> | provisionedClusters / agentPools | No |

+> | provisionedClusters / hybridIdentityMetadata | No |

+## Microsoft.IoTFirmwareDefense

+> [!div class="mx-tableFixed"]

+> | Resource type | Complete mode deletion |

+> | - | -- |

+> | firmwareGroups | No |

+> | firmwareGroups / firmwares | No |

+> | namespaces | No |

+> | privateStores / fetchAllSubscriptionsInTenant | No |

+> | customIpPrefixes | Yes |

+> | dscpConfigurations | Yes |

+> | ipAllocations | Yes |

+> | networkManagers | Yes |

+> | networkVirtualAppliances | Yes |

+> | securityPartnerProviders | Yes |

+> | vpnServerConfigurations | Yes |

+> | accounts / kafkaConfigurations | No |

+## Microsoft.Scheduler

+> [!div class="mx-tableFixed"]

+> | Resource type | Complete mode deletion |

+> | - | -- |

+> | jobcollections | Yes |

+> | assessments / governanceAssignments | No |

+> | attackPaths | No |

+> | dataScanners | Yes |

+> | governanceRules | No |

+> | dryruns | No |

+> | instancePools | Yes |

+> | managedInstances / administrators | No |

+> | managedInstances / databases / backupLongTermRetentionPolicies | No |

+> | managedInstances / sqlAgent | No |

+> | servers / advisors | No |

+> | servers / auditingSettings | No |

+> | servers / databases / advisors | No |

+> | servers / databases / auditingSettings | No |

+> | servers / databases / backupLongTermRetentionPolicies | No |

+> | servers / databases / backupShortTermRetentionPolicies | No |

+> | servers / databases / dataMaskingPolicies | No |

+> | servers / databases / extensions | No |

+> | servers / databases / securityAlertPolicies | No |

+> | servers / databases / syncGroups | No |

+> | servers / databases / syncGroups / syncMembers | No |

+> | servers / databases / transparentDataEncryption | No |

+> | servers / databases / workloadGroups | No |

+> | servers / elasticpools | Yes |

+> | servers / failoverGroups | No |

+> | servers / jobAgents | Yes |

+> | servers / jobAgents / jobs | No |

+> | servers / jobAgents / jobs / steps | No |

+> | servers / jobAgents / jobs / executions | No |

+> | servers / virtualNetworkRules | No |

+> | dataMovers | Yes |

+> | dataMovers / agents | No |

+> | dataMovers / endpoints | No |

+> | dataMovers / projects | No |

+> | dataMovers / projects / jobDefinitions | No |

+> | dataMovers / projects / jobDefinitions / jobRuns | No |

+For more information, see [vCore-based purchasing model](service-tiers-vcore.md), [DTU-based purchasing model](service-tiers-dtu.md), or [compare purchasing models](purchasing-models.md).

+> [!div class="op_single_selector"]

+> * [Azure SQL Database](doc-changes-updates-release-notes-whats-new.md)

+> * [Azure SQL Managed Instance](../managed-instance/doc-changes-updates-release-notes-whats-new.md)

+This article summarizes the documentation changes associated with new features and improvements in the recent releases of [Azure SQL Database](https://azure.microsoft.com/products/azure-sql/database/). To learn more about Azure SQL Database, see the [overview](sql-database-paas-overview.md).

+- A stateful data layer with the database files (.mdf/.ldf) that are stored in ZRS(zone-redundant storage). Using [ZRS](../../storage/common/storage-redundancy.md) the data and log files are synchronously copied across three physically isolated Azure availability zones.

+> Zone-redundant configuration is not available in SQL Managed Instance. In SQL Database this feature is only available when the Gen5 compute hardware is selected. Additionally, for serverless and provisioned general purpose tier, the zone-redundant configuration is only available in the following regions: East US, East US 2, West US 2, North Europe, West Europe, Southeast Asia, Australia East, Japan East, UK South, and France Central.

+> This feature is not available in SQL Managed Instance. In SQL Database, when using the Business Critical tier, zone-redundant configuration is only available when the Gen5 compute hardware is selected. For up to date information about the regions that support zone-redundant databases, see [Services support by region](../../availability-zones/az-region.md).

+If you're using a database under the [DTU-based purchasing model](service-tiers-dtu.md), you will need to use Transact-SQL to query the database's vCore count.

+You can add more CPU resources to your Azure SQL Database by configuring the vCore count or the [hardware generation](service-tiers-sql-database-vcore.md#hardware-generations) for databases using the [vCore purchasing model](service-tiers-sql-database-vcore.md).

+Under the [DTU-based purchasing model](service-tiers-dtu.md), you can raise your service tier and increase the number of database transaction units (DTUs). A DTU represents a blended measure of CPU, memory, reads, and writes. One benefit of the vCore purchasing model is that it allows more granular control over the hardware in use and the number of vCores. You can [migrate Azure SQL Database from the DTU-based model to the vCore-based model](migrate-dtu-to-vcore.md) to transition between purchasing models.

+In the DTU model, the system may select any available [hardware generation](service-tiers-dtu.md#hardware-generations) for your database or elastic pool. Further, in the DTU model you have only indirect control over the number of vCores (logical CPUs) by choosing higher or lower DTU or eDTU values.

+description: "Learn about the purchasing models that are available for Azure SQL Database: the vCore purchasing model and the DTU purchasing model."

+# Compare vCore and DTU-based purchasing models of Azure SQL Database

+Azure SQL Database lets you easily purchase a fully managed platform as a service (PaaS) database engine that fits your performance and cost needs. Depending on the deployment model you've chosen for Azure SQL Database, you can select the purchasing model that works for you:

+- [Virtual core (vCore)-based purchasing model](service-tiers-sql-database-vcore.md) (recommended). This purchasing model provides a choice between a provisioned compute tier and a serverless compute tier. With the provisioned compute tier, you choose the exact amount of compute resources that are always provisioned for your workload. With the serverless compute tier, you specify the autoscaling of the compute resources over a configurable compute range. The serverless compute tier automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns. The vCore unit price per unit of time is lower in the provisioned compute tier than it is in the serverless compute tier. The [Hyperscale service tier](service-tier-hyperscale.md) is available for single databases that are using the [vCore-based purchasing model](service-tiers-vcore.md).

+## Purchasing models

+The following table and chart compares and contrasts the vCore-based and the DTU-based purchasing models:

+|DTU-based|This model is based on a bundled measure of compute, storage, and I/O resources. Compute sizes are expressed in DTUs for single databases and in elastic database transaction units (eDTUs) for elastic pools. For more information about DTUs and eDTUs, see [What are DTUs and eDTUs?](purchasing-models.md#dtu-purchasing-model).|Customers who want simple, preconfigured resource options|

+|vCore-based|This model allows you to independently choose compute and storage resources. The vCore-based purchasing model also allows you to use [Azure Hybrid Benefit](https://azure.microsoft.com/pricing/hybrid-benefit/) for SQL Server to save costs.|Customers who value flexibility, control, and transparency|

+## vCore purchasing model

+In the vCore-based purchasing model for SQL Database, you can choose between the General Purpose and Business Critical service tiers. Review [service tiers](service-tiers-sql-database-vcore.md#service-tiers) to learn more. For single databases, you can also choose the [Hyperscale service tier](service-tier-hyperscale.md).

+In the vCore-based purchasing model, you pay for:

+- Backup storage.

+## DTU purchasing model

+The DTU-based purchasing model uses a database transaction unit (DTU) to calculate and bundle compute costs. A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes. The DTU-based purchasing model offers a set of preconfigured bundles of compute resources and included storage to drive different levels of application performance. If you prefer the simplicity of a preconfigured bundle and fixed payments each month, the DTU-based model might be more suitable for your needs.

+In the DTU-based purchasing model, you can choose between the basic, standard, and premium service tiers for Azure SQL Database. Review [DTU service tiers](service-tiers-dtu.md#compare-service-tiers) to learn more.

+To convert from the DTU-based purchasing model to the vCore-based purchasing model, see [Migrate from DTU to vCore](migrate-dtu-to-vcore.md).

+## Compute costs

+Compute costs are calculated differently based on each purchasing model.

+### DTU compute costs

+In the DTU purchasing model, DTUs are offered in preconfigured bundles of compute resources and included storage to drive different levels of application performance. You are billed by the number of DTUs you allocate to your database for your application.

+### vCore compute costs

+In the vCore-based purchasing model, choose between the provisioned compute tier, or the [serverless compute tier](serverless-tier-overview.md). In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the application. In the serverless compute tier, compute resources are auto-scaled based on workload capacity and billed for the amount of compute used, per second.

+For single databases, compute resources, I/O, and data and log storage are charged per database. For elastic pools, these resources are charged per pool. However, backup storage is always charged per database.

+Since three additional replicas are automatically allocated in the Business Critical service tier, the price is approximately 2.7 times higher than it is in the General Purpose service tier. Likewise, the higher storage price per GB in the Business Critical service tier reflects the higher IO limits and lower latency of the local SSD storage.

+## Storage costs

+Storage costs are calculated differently based on each purchasing model.

+### DTU storage costs

+Storage is included in the price of the DTU. It's possible to add extra storage in the standard and premium tiers. See the [Azure SQL Database pricing options](https://azure.microsoft.com/pricing/details/sql-database/single/) for details on provisioning extra storage. [Long-term backup retention](long-term-retention-overview.md) is not included, and is billed separately.

+## vCore storage costs

+Different types of storage are billed differently. For data storage, you're charged for the provisioned storage based upon the maximum database or pool size you select. The cost doesn't change unless you reduce or increase that maximum. Backup storage is associated with automated backups of your databases and is allocated dynamically. Increasing your backup retention period may increase the backup storage that's consumed by your databases.

+By default, seven days of automated backups of your databases are copied to a storage account. This storage is used by full backups, differential backups, and transaction log backups. The size of differential and transaction log backups depends on the rate of change of the database. A minimum storage amount equal to 100 percent of the maximum data size for the database is provided at no extra charge. Additional consumption of backup storage is charged in GB per month.

+The cost of backup storage is the same for the Business Critical service tier and the General Purpose service tier because both tiers use standard storage for backups.

+For more information about storage prices, see the [pricing](https://azure.microsoft.com/pricing/details/sql-database/single/) page.

+## Tempdb sizes

+The following table lists tempdb sizes for single databases in Azure SQL Database:

+|Service-level objective|Maximum `tempdb` data file size (GB)|Number of `tempdb` data files|Maximum `tempdb` data size (GB)|

+||:|:|:|

+|Basic Elastic Pools (all DTU configurations)|13.9|12|166.7|

+|Standard Elastic Pools (50 eDTU)|13.9|12|166.7|

+|Standard Elastic Pools (100 eDTU)|32|1|32|

+|Standard Elastic Pools (200 eDTU)|32|2|64|

+|Standard Elastic Pools (300 eDTU)|32|3|96|

+|Standard Elastic Pools (400 eDTU)|32|3|96|

+|Standard Elastic Pools (800 eDTU)|32|6|192|