-To register an application in your Azure AD B2C tenant, you can use Azure portal's new unified **App registrations** experience the legacy **Applications (Legacy)** experience. [Learn more about the new experience](./app-registrations-training-guide.md).

-Your application is registered to call the protected web API. A user authenticates with Azure AD B2C to use the application. The application obtains an authorization grant from Azure AD B2C to access the protected web API.

-If the application needs to distinguish between app-only access tokens and access tokens for users, use the `idtyp` [optional claim](active-directory-optional-claims.md). Add the `idtyp` claim to the `accessToken` field, and check for the value `app`, app-only access tokens can be detected. ID tokens and access tokens for users won't have the `idtyp` claim included.

-> | Angular | &#8226; [Sign in users](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/1-Authentication/1-sign-in/README.md)<br/>&#8226; [Sign in users (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/1-Authentication/2-sign-in-b2c/README.md) <br/> &#8226; [Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/2-Authorization-I/1-call-graph/README.md)<br/>&#8226; [Call .NET Core web API](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/3-Authorization-II/1-call-api)<br/>&#8226; [Call .NET Core web API (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/3-Authorization-II/2-call-api-b2c)<br/>&#8226; [Call Microsoft Graph via OBO](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/7-AdvancedScenarios/1-call-api-obo/README.md)<br/>&#8226; [Call .NET Core web API using PoP](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/7-AdvancedScenarios/2-call-api-pop/README.md)<br/>&#8226; [Use App Roles for access control](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/5-AccessControl/1-call-api-roles/README.md)<br/> &#8226; [Use Security Groups for access control](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/5-AccessControl/2-call-api-groups/README.md)<br/>&#8226; [Deploy to Azure Storage and App Service](https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/4-Deployment/README.md)| MSAL Angular | &#8226; Authorization code with PKCE<br/>&#8226; On-behalf-of (OBO) <br/>&#8226; Proof of Possession (PoP)|

-> | React | &#8226; [Sign in users](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/1-Authentication/1-sign-in/README.md)<br/>&#8226; [Sign in users (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/1-Authentication/2-sign-in-b2c/README.md) <br/> &#8226; [Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/2-Authorization-I/1-call-graph/README.md)<br/>&#8226; [Call Node.js web API](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/1-call-api)<br/>&#8226; [Call Node.js web API (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/2-call-api-b2c)<br/>&#8226; [Call Microsoft Graph via OBO](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/6-AdvancedScenarios/1-call-api-obo/README.md)<br/>&#8226; [Call Node.js web API using PoP](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/6-AdvancedScenarios/2-call-api-pop/README.md)<br/>&#8226; [Use App Roles for access control](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/5-AccessControl/1-call-api-roles/README.md)<br/>&#8226; [Use Security Groups for access control](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/5-AccessControl/2-call-api-groups/README.md)<br/>&#8226; [Deploy to Azure Storage and App Service](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/4-Deployment/1-deploy-storage/README.md)<br/>&#8226; [Deploy to Azure Static Web Apps](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/4-Deployment/2-deploy-static/README.md)| MSAL React | &#8226; Authorization code with PKCE<br/>&#8226; On-behalf-of (OBO) <br/>&#8226; Conditional Access<br/>&#8226; Proof of Possession (PoP) |

-> | Node.js | &#8226; [Protect a Node.js web API](https://github.com/Azure-Samples/active-directory-javascript-nodejs-webapi-v2) <br/> &#8226; [Protect a Node.js Web API with Azure AD B2C](https://github.com/Azure-Samples/active-directory-b2c-javascript-nodejs-webapi) | MSAL Node | Authorization bearer |

-Check out a [deployment sample](https://github.com/Azure-Samples/ms-identity-javascript-angular-spa-aspnet-webapi-multitenant/tree/master/Chapter3) for learning how to deploy your SPA and Web API projects with Azure Storage and Azure App Services, respectively.

-These code samples demonstrate several key operations for a single-page app.

->This information last updated on September 22nd, 2022.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).

-description: Security default policies that help protect organizations from common attacks in Azure AD

-Microsoft is making security defaults available to everyone, because managing security can be difficult. Identity-related attacks like password spray, replay, and phishing are common in today's environment. More than 99.9% of these identity-related attacks are stopped by using multi-factor authentication (MFA) and blocking legacy authentication. The goal is to ensure that all organizations have at least a basic level of security enabled at no extra cost.

-All users in your tenant must register for multi-factor authentication (MFA) in the form of the Azure AD Multi-Factor Authentication. Users have 14 days to register for Azure AD Multi-Factor Authentication by using the Microsoft Authenticator app. After the 14 days have passed, the user can't sign in until registration is completed. A user's 14-day period begins after their first successful interactive sign-in after enabling security defaults.

-### Require administrators to do multi-factor authentication

-Administrators have increased access to your environment. Because of the power these highly privileged accounts have, you should treat them with special care. One common method to improve the protection of privileged accounts is to require a stronger form of account verification for sign-in. In Azure AD, you can get a stronger account verification by requiring multi-factor authentication.

-### Require users to do multi-factor authentication when necessary

-One common method to improve protection for all users is to require a stronger form of account verification, such as Multi-Factor Authentication, for everyone. After users complete Multi-Factor Authentication registration, they'll be prompted for another authentication whenever necessary. Azure AD decides when a user will be prompted for Multi-Factor Authentication, based on factors such as location, device, role and task. This functionality protects all applications registered with Azure AD including SaaS applications.

-Today, most compromising sign-in attempts come from legacy authentication. Legacy authentication doesn't support Multi-Factor Authentication. Even if you have a Multi-Factor Authentication policy enabled on your directory, an attacker can authenticate by using an older protocol and bypass Multi-Factor Authentication.

-After you enable security defaults in your tenant, any user accessing the following services must complete multi-factor authentication:

-> The Azure AD Connect synchronization account is excluded from security defaults and will not be prompted to register for or perform multi-factor authentication. Organizations should not be using this account for other purposes.

-### B2B guest users

-Any B2B Guest users that access your directory will be subject to the same controls as your organization's users.

-You can use Conditional Access to configure policies similar to security defaults, but with more granularity including selecting other authentication methods and the ability to exclude users, which aren't available in security defaults. If you're using Conditional Access in your environment today, security defaults won't be available to you.

-Before you can use an existing Azure Logic App with the custom task extension feature of Lifecycle Workflows, it must first be made compatible. This reference guide provides a list of steps that must be taken to make the Azure Logic App compatible the custom task extension. For a simpler guide on creating a new Logic App with the custom task extension via the Lifecycle Workflows portal, see [Trigger Logic Apps based on custom task extensions (preview)](trigger-custom-task.md).

-## Configure existing Logic Apps for LCW use with Microsoft Graph

-1. On the left of the screen select **Logic App code view**.

-1. On the left of the screen select **Identity**.

-1. Under the system assigned tab enable the status to register it with Azure Active Directory.

-1. Create a new authorization policy based on the table below:

-

-## Linking Lifecycle Workflows with Logic Apps using Microsoft Graph

-After the Logic App, we can now integrate it with Lifecycle Workflows. As outlined in the high-level steps we first need to create the customTaskExtension and afterwards, we can reference the customTaskExtension in our ΓÇ£Run a custom task extensionΓÇ¥ task.

-The API call for creating a customTaskExtension is as follows:

-```http

-POST https://graph.microsoft.com/beta/identityGovernance/lifecycleManagement/customTaskExtensions

-Content-type: application/json

-{

- "displayName": "<Custom task extension name>",

- "description": "<description for custom task extension>",

- "callbackConfiguration": {

- "@odata.type": "#microsoft.graph.identityGovernance.customTaskExtensionCallbackConfiguration",

- "durationBeforeTimeout": "PT1H"

- },

- "endpointConfiguration": {

- "@odata.type": "#microsoft.graph.logicAppTriggerEndpointConfiguration",

- "subscriptionId": "<Your Azure subscription>",

- "resourceGroupName": "<Resource group where the Logic App is located>",

- "logicAppWorkflowName": "<Logic App workflow name>"

- },

- "authenticationConfiguration": {

- "@odata.type": "#microsoft.graph.azureAdTokenAuthentication",

- "resourceId": " f9c5dc6b-d72b-4226-8ccd-801f7a290428"

- },

- "clientConfiguration": {

- "timeoutInMilliseconds": 1000,

- "maximumRetries": 1

- }

-}

-```

-> [!NOTE]

-> To create a custom task extension instance that does not wait for a response from the logic app, remove the **callbackConfiguration** parameter.

-After the task is created, you can run the following GET call to retrieve its details:

-```http

-GET https://graph.microsoft.com/beta/identityGovernance/lifecycleWorkflows/customTaskExtensions

-```

-An example response is as follows:

- ```Example Custom Task Extension return

-{

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#identityGovernance/lifecycleWorkflows/customTaskExtensions",

- "@odata.count": 1,

- "value": [

- {

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#identityGovernance/lifecycleWorkflows/customTaskExtensions",

- "@odata.count": 1,

- "value": [

- {

- "id": "def9685c-e0f6-45aa-8fe8-a9f7ee6d30d6",

- "displayName": "My Custom Task Extension",

- "description": "My Custom Task Extension to test Lifecycle workflows Logic App integration",

- "createdDateTime": "2022-06-28T10:47:08.9359567Z",

- "lastModifiedDateTime": "2022-06-28T10:47:08.936017Z",

- "endpointConfiguration": {

- "@odata.type": "#microsoft.graph.logicAppTriggerEndpointConfiguration",

- "subscriptionId": "c500b67c-e9b7-4ad2-a90d-77d41385ae55",

- "resourceGroupName": "RG-LCM",

- "logicAppWorkflowName": "LcwDocsTest"

- },

- "authenticationConfiguration": {

- "@odata.type": "#microsoft.graph.azureAdTokenAuthentication",

- "resourceId": "f74118f0-849a-457d-a7e4-ee97eab6017a"

- },

- "clientConfiguration": {

- "maximumRetries": 1,

- "timeoutInMilliseconds": 1000

- },

- "callbackConfiguration": {

- "@odata.type": "#microsoft.graph.identityGovernance.customTaskExtensionCallbackConfiguration",

- "timeoutDuration": "PT1H"

- }

- }

- ]

-}

-```

-You'll then take the custom extension **ID**, and use it as the value in the customTaskExtensionId parameter for the custom task example here:

-> [!NOTE]

-> The new ΓÇ£Run a Custom Task ExtensionΓÇ¥ task is already available in the Public Preview UI.

-```Example of Custom Task extension task

-"tasks":[

- {

- "taskDefinitionId": "4262b724-8dba-4fad-afc3-43fcbb497a0e",

- "continueOnError": false,

- "displayName": "<Custom Task Extension displayName>",

- "description": "<Custom Task Extension description>",

- "isEnabled": true,

- "arguments": [

- {

- "name": "customTaskExtensionID",

- "value": "<ID of your Custom Task Extension>"

- }

- ]

-}

-```

-1. In the search box, enter a domain name to search for the Azure AD directory or domain. You can also add domains that are not in Azure AD. Be sure to enter the entire domain name.

-1. Confirm that the organization name(s) and authentication type(s) are correct. User sign in, prior to being able to access the MyAccess portal, depends on the authentication type for their organization. If the authentication type for a connected organization is Azure AD, all users with an account in any verified domain of that Azure AD directory will sign into their directory, and then can request access to access packages that allow that connected organization. If the authentication type is One-time passcode, this allows users with email addresses from just that domain to visit the MyAccess portal. After they authenticate with the passcode, the user can make a request.

-1. Select **Add** to add the Azure AD directory or domain. **You can add multiple Azure AD directories and domains**.

-1. After you've added the Azure AD directories or domains, select **Select**.

- The organization(s) appears in the list.

-|[Generate Temporary Access Password and send via email to user's manager](lifecycle-workflow-tasks.md#generate-temporary-access-password-and-send-via-email-to-users-manager) | 1b555e50-7f65-41d5-b514-5894a026d10d |

-|[Add user to group](lifecycle-workflow-tasks.md#add-user-to-group) | 22085229-5809-45e8-97fd-270d28d66910 |

-|[Add user to team](lifecycle-workflow-tasks.md#add-user-to-team) | e440ed8d-25a1-4618-84ce-091ed5be5594 |

-|[Remove user from group](lifecycle-workflow-tasks.md#remove-user-from-groups) | 1953a66c-751c-45e5-8bfe-01462c70da3c |

-|executionSequence | An integer that is read-only which states in what order the task will run in a workflow. For more information about executionSequence and workflow order, see: [Execution conditions](understanding-lifecycle-workflows.md#parts-of-a-workflow). |

-|arguments | Contains unique parameters relevant for the given task |

-### Generate Temporary Access Password and send via email to user's manager

-When a compatible user joins your organization, Lifecycle Workflows allow you to automatically generate a Temporary Access Password(TAP) and have it sent to the new user's manager.

-The Azure AD prerequisites to run the **Generate Temporary Access Password and send via email to user's manager** task are:

-> A user having this task run for them in a workflow must also not have any other authentication methods, sign ins, or AAD role assignments for this task to work for them.

-For Microsoft Graph the parameters for the **Generate Temporary Access Password and send via email to user's manager** task are as follows:

-|description | Generate Temporary Access Password and send via email to user's manager (Customizable by user) |

-|arguments | Argument contains the name parameter "tapLifetimeInMinutes", which is the lifetime of the temporaryAccessPass in minutes starting at startDateTime. Minimum 10, Maximum 43200 (equivalent to 30 days). The argument also contains the tapIsUsableOnce parameter, which determines whether the password is limited to a one time use. If true, the pass can be used once; if false, the pass can be used multiple times within the temporaryAccessPass lifetime. |

- "description": "Generate Temporary Access Password and send via email to user's manager",

-### Add user to group

-Allows users to be added to a cloud-only group. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

-For Microsoft Graph the parameters for the **Add user to group** task are as follows:

-|description | Add user to group (Customizable by user) |

- "description": "Add user to group",

-### Add user to team

-For Microsoft Graph the parameters for the **Add user to team** task are as follows:

-|description | Add user to team (Customizable by user) |

-### Remove user from groups

-Allows you to remove a user from cloud-only groups. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

-For Microsoft Graph the parameters for the **Remove user from groups** task are as follows:

-Allows users to be removed from every cloud-only group they are a member of. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

-This task uses 1b555e50-7f65-41d5-b514-5894a026d10d, which is the taskDefinitionID for [Generate Temporary Access Password and send via email to user's manager](lifecycle-workflow-tasks.md#generate-temporary-access-password-and-send-via-email-to-users-manager). This is a pre-defined task created by Microsoft and will send a user's manager an email that contains a temporary access pass. This task requires the following more arguments.

-# Azure Active Directory Identity Protection and the Microsoft Graph PowerShell SDK

-Microsoft Graph is the Microsoft unified API endpoint and the home of [Azure Active Directory Identity Protection](./overview-identity-protection.md) APIs. This article will show you how to use the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/get-started) to get risky user details using PowerShell. Organizations that want to query the Microsoft Graph APIs directly can use the article, [Tutorial: Identify and remediate risks using Microsoft Graph APIs](/graph/tutorial-riskdetection-api) to begin that journey.

-## Connect to Microsoft Graph

-There are four steps to accessing Identity Protection data through Microsoft Graph:

-1. [Create a certificate](#create-a-certificate)

-1. [Create a new app registration](#create-a-new-app-registration)

-1. [Configure API permissions](#configure-api-permissions)

-1. [Configure a valid credential](#configure-a-valid-credential)

-### Create a certificate

-In a production environment you would use a certificate from your production Certificate Authority, but in this sample we'll use a self-signed certificate. Create and export the certificate using the following PowerShell commands.

-$cert = New-SelfSignedCertificate -Subject "CN=MSGraph_ReportingAPI" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256

-Export-Certificate -Cert $cert -FilePath "C:\Reporting\MSGraph_ReportingAPI.cer"

-### Create a new app registration

-1. In the Azure portal, browse to **Azure Active Directory** > **App registrations**.

-1. Select **New registration**.

-1. On the **Create** page, perform the following steps:

- 1. In the **Name** textbox, type a name for your application (for example: Azure AD Risk Detection API).

- 1. Under **Supported account types**, select the type of accounts that will use the APIs.

- 1. Select **Register**.

-1. Take note of the **Application (client) ID** and **Directory (tenant) ID** as you'll need these items later.

-### Configure API permissions

-In this example, we configure application permissions allowing this sample to be used unattended. If granting permissions to a user who will be logged on, choose delegated permissions instead. More information about different permission types can be found in the article, [Permissions and consent in the Microsoft identity platform](../develop/v2-permissions-and-consent.md#permission-types).

-1. From the **Application** you created, select **API permissions**.

-1. On the **Configured permissions** page, in the toolbar on the top, click **Add a permission**.

-1. On the **Add API access** page, click **Select an API**.

-1. On the **Select an API** page, select **Microsoft Graph**, and then click **Select**.

-1. On the **Request API permissions** page:

- 1. Select **Application permissions**.

- 1. Select the checkboxes next to `IdentityRiskEvent.Read.All` and `IdentityRiskyUser.Read.All`.

- 1. Select **Add permissions**.

-1. Select **Grant admin consent for domain**

-### Configure a valid credential

-1. From the **Application** you created, select **Certificates & secrets**.

-1. Under **certificates**, select **Upload certificate**.

- 1. Select the previously exported certificate from the window that opens.

- 1. Select **Add**.

-1. Take note of the **Thumbprint** of the certificate as you'll need this information in the next step.

-To enable the ability to query Microsoft Graph, we need to install the `Microsoft.Graph` module in our PowerShell window, using the `Install-Module Microsoft.Graph` command.

-Modify the following variables to include the information generated in the previous steps, then run them as a whole to get risky user details using PowerShell.

-$ClientID = "<your client ID here>" # Application (client) ID gathered when creating the app registration

-$tenantdomain = "<your tenant domain here>" # Directory (tenant) ID gathered when creating the app registration

-$Thumbprint = "<your client secret here>" # Certificate thumbprint gathered when configuring your credential

-Select-MgProfile -Name "beta"

-

-Connect-MgGraph -ClientId $ClientID -TenantId $tenantdomain -CertificateThumbprint $Thumbprint

-Get-MgRiskyUser -All