From b8c1ef1021f7645c6dd5be2cf52da55c2d564d39 Mon Sep 17 00:00:00 2001 From: Dickson Mwendia <64727760+Dickson-Mwendia@users.noreply.github.com> Date: Tue, 21 May 2024 17:42:06 +0300 Subject: [PATCH] Update content that features the ROPC Flow --- .../acquiring-tokens/desktop-mobile/adfs-support.md | 4 ++++ .../desktop-mobile/social-identities.md | 13 +++++++------ .../acquiring-tokens/desktop-mobile/wam.md | 2 +- msal-dotnet-articles/acquiring-tokens/overview.md | 4 ++-- .../advanced/testing-apps-using-msal.md | 4 ++-- msal-dotnet-articles/getting-started/scenarios.md | 3 +-- .../how-to/migrate-public-client.md | 8 ++++---- .../how-to/token-cache-serialization.md | 3 +-- msal-dotnet-articles/resources/handling-pii.md | 12 ++++++------ 9 files changed, 28 insertions(+), 25 deletions(-) diff --git a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/adfs-support.md b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/adfs-support.md index 78097ea05..92ff4e4c3 100644 --- a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/adfs-support.md +++ b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/adfs-support.md @@ -47,6 +47,10 @@ Supported ADFS versions in this federated scenario are ADFS v2 , ADFS v3 (Window When acquiring a token using the `AcquireTokenByIntegratedAuthentication` or `AcquireTokenByUsernamePassword` methods, MSAL.NET gets the identity provider to contact based on the username. MSAL.NET receives a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) after contacting the identity provider. MSAL.NET then provides the SAML token to Microsoft Entra ID as a user assertion (similar to the [on-behalf-of flow](../web-apps-apis/on-behalf-of-flow.md) to get back a JWT. + +Microsoft recommends you **do not use** the username and password flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information about why you want to avoid using this grant, see [why Microsoft is working to make passwords a thing of the past](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/). + + ## Case where MSAL connects directly to ADFS MSAL.NET supports connecting to AD FS 2019, which is OpenID Connect compliant and understands PKCE and scopes. This support requires that a service pack [KB 4490481](https://support.microsoft.com/help/4490481/windows-10-update-kb4490481) is applied to Windows Server. When connecting directly to AD FS, the authority you'll want to use to build your application is similar to `https://mysite.contoso.com/adfs/`. diff --git a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/social-identities.md b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/social-identities.md index 36c33d3f8..c7fb92fcf 100644 --- a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/social-identities.md +++ b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/social-identities.md @@ -9,7 +9,7 @@ ms.service: msal ms.subservice: msal-dotnet ms.topic: conceptual ms.workload: identity -ms.date: 08/24/2023 +ms.date: 05/21/2024 ms.author: dmwendia ms.reviewer: ddelimarsky, saeeda, jeferrie ms.custom: devx-track-csharp, aaddev, devx-track-dotnet @@ -148,11 +148,12 @@ Or whichever special logic you were doing to process the `AADB2C90118` error. ## Resource Owner Password Credentials (ROPC) With B2C -For more details on the ROPC flow, please see this [documentation](./username-password-authentication.md). +For more details on the ROPC flow, please see the [username and password flow documentation](./username-password-authentication.md). ### This flow is not recommended -This flow is **not recommended** because your application asking a user for their password is not secure. For more information about this problem, see [this article](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/). +This flow is **not recommended** because your application asking a user for their password is not secure. For more information about this problem, see [why Microsoft is working to make passwords a thing of the past](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/). + By using username/password you are giving-up a number of things: @@ -160,9 +161,9 @@ By using username/password you are giving-up a number of things: - Users who need to do MFA won't be able to sign-in (as there is no interaction) - Users won't be able to do single sign-on -### Configure the ROPC flow in AzureAD B2C +### Configure the ROPC flow in Azure AD B2C -In your AzureAD B2C tenant, create a new user flow and select **Sign in using ROPC**. This will enable the ROPC policy for your tenant. See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details. +In your Azure AD B2C tenant, create a new user flow and select **Sign in using ROPC**. This will enable the ROPC policy for your tenant. See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details. `IPublicClientApplication` contains a method called `AcquireTokenByUsernamePassword`: @@ -191,7 +192,7 @@ If you are a B2C developer using Google as an identity provider we recommend you ## Caching with B2C in MSAL.NET -### Known issue with Azure B2C +### Known issue with Azure AD B2C MSAL.Net supports a [token cache](/dotnet/api/microsoft.identity.client.tokencache). The token caching key is based on the claims returned by the Identity Provider. Currently MSAL.Net needs two claims to build a token cache key: diff --git a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/wam.md b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/wam.md index a77ca4db1..31db94a27 100644 --- a/msal-dotnet-articles/acquiring-tokens/desktop-mobile/wam.md +++ b/msal-dotnet-articles/acquiring-tokens/desktop-mobile/wam.md @@ -152,7 +152,7 @@ ms-appx-web://microsoft.aad.brokerplugin/{client_id} This flow, also known as Resource Owner Password Credentials (ROPC), is not recommended except in test scenarios or in scenarios where service principal access to a resource gives it too much access and you can only scope it down with user flows. When using WAM, [`AcquireTokenByUsernamePassword`](xref:Microsoft.Identity.Client.PublicClientApplication.AcquireTokenByUsernamePassword*) will let WAM manage the protocol and fetch tokens. >[!WARNING] ->There are a few important considerations that you need to account for when using the ROPC flow. One of the main ones is that it **doesn't support personal Microsoft accounts** and **Microsoft Entra accounts with enabled multi-factor authentication**. Check out [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](/azure/active-directory/develop/v2-oauth-ropc) for the full overview. +>Microsoft does not recommend using the username and password flow as the application will be asking a user for their password directly, which is an insecure pattern. Additionally, the ROPC flow **doesn't support personal Microsoft accounts** and **Microsoft Entra accounts with enabled multi-factor authentication**. Check out [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](/azure/active-directory/develop/v2-oauth-ropc) for the full overview. ## WAM limitations diff --git a/msal-dotnet-articles/acquiring-tokens/overview.md b/msal-dotnet-articles/acquiring-tokens/overview.md index 666a477ca..ba4185f1d 100644 --- a/msal-dotnet-articles/acquiring-tokens/overview.md +++ b/msal-dotnet-articles/acquiring-tokens/overview.md @@ -8,10 +8,10 @@ ms.service: msal ms.subservice: msal-dotnet ms.topic: reference ms.workload: identity -ms.date: 03/17/2023 +ms.date: 05/20/2024 ms.author: dmwendia ms.reviewer: localden -ms.custom: devx-track-csharp, aaddev, engagement-fy23 +ms.custom: devx-track-csharp, aaddev # Customer intent: As an application developer, I want to learn how to acquire security tokens in public and confidential client applications using MSAL.NET --- diff --git a/msal-dotnet-articles/advanced/testing-apps-using-msal.md b/msal-dotnet-articles/advanced/testing-apps-using-msal.md index 506896ee1..b091c1024 100644 --- a/msal-dotnet-articles/advanced/testing-apps-using-msal.md +++ b/msal-dotnet-articles/advanced/testing-apps-using-msal.md @@ -25,9 +25,9 @@ Pros: end to end testing with real tokens Cons: UI automation is flaky. It's tedious to automate the login screens. Live accounts and "Work and School" have slightly different UI flows. -**Strategy 2**: Use ROPC (Username/Password flow) to get tokens and test only your controllers +**Strategy 2**: Use ROPC (Username/Password flow) to get tokens and test only your controllers. Microsoft does not recommend using the ROPC flow in production as it presents some security risks not present in other flows. Use this flow for testing purposes only. -Pros: no ui automation +Pros: No ui automation Cons: Does not work for Live accounts, where ROPC is not supported. diff --git a/msal-dotnet-articles/getting-started/scenarios.md b/msal-dotnet-articles/getting-started/scenarios.md index f0a293bc7..639e6386a 100644 --- a/msal-dotnet-articles/getting-started/scenarios.md +++ b/msal-dotnet-articles/getting-started/scenarios.md @@ -1,7 +1,6 @@ --- title: MSAL.NET scenarios description: Learn the application scenarios and authentication flows supported by MSAL.NET -services: active-directory author: Dickson-Mwendia manager: CelesteDG @@ -12,7 +11,7 @@ ms.workload: identity ms.date: 03/17/2023 ms.author: dmwendia ms.reviewer: localden -ms.custom: devx-track-csharp, aaddev, engagement-fy23 +ms.custom: devx-track-csharp, aaddev # Customer intent: As an application developer, I want to know the application scenarios and authentication flows supported by MSAL.NET. --- diff --git a/msal-dotnet-articles/how-to/migrate-public-client.md b/msal-dotnet-articles/how-to/migrate-public-client.md index 2224ac68c..1ab562124 100644 --- a/msal-dotnet-articles/how-to/migrate-public-client.md +++ b/msal-dotnet-articles/how-to/migrate-public-client.md @@ -1,7 +1,6 @@ --- title: Migrate public client applications to MSAL.NET description: Learn how to migrate a public client application from Azure Active Directory Authentication Library for .NET to Microsoft Authentication Library for .NET. -services: active-directory author: Dickson-Mwendia manager: CelesteDG @@ -9,7 +8,7 @@ ms.service: msal ms.subservice: msal-dotnet ms.topic: how-to ms.workload: identity -ms.date: 08/31/2021 +ms.date: 05/20/2024 ms.author: dmwendia ms.reviewer: celested, saeeda, shermanouko, jmprieur ms.custom: devx-track-csharp, aaddev, has-adal-ref, devx-track-dotnet @@ -38,7 +37,7 @@ This article describes how to migrate a public client application from Azure Act - [Web Authentication Manager](/azure/active-directory/develop/scenario-desktop-acquire-token-wam) the preferred broker-based authentication on Windows. - [Interactive authentication](/azure/active-directory/develop/scenario-desktop-acquire-token-interactive) where the user is shown a web-based interface to complete the sign-in process. - [Integrated Windows authentication](/azure/active-directory/develop/scenario-desktop-acquire-token-integrated-windows-authentication) where a user signs using the same identity they used to sign into a Windows domain (for domain-joined or Microsoft Entra joined machines). - - [Username/password](/azure/active-directory/develop/scenario-desktop-acquire-token-username-password) where the sign-in occurs by providing a username/password credential. + - [Username/password](/azure/active-directory/develop/scenario-desktop-acquire-token-username-password) where the sign-in occurs by providing a username/password credential. Microsoft does not recommend the username and password flow because the application will be asking a user for their password directly, which is an insecure pattern. - [Device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token-device-code-flow) where a device of limited UX shows you a device code to complete the authentication flow on an alternate device. @@ -235,7 +234,8 @@ result = await context.AcquireTokenAsync(resource, clientId, ## [Username Password](#tab/up) -Username Password authentication is where the sign-in occurs by providing a username/password credential. +Username Password authentication is where the sign-in occurs by providing a username/password credential. Microsoft does not recommend this flow because it presents security risks that are not present in other flows.If you're using the username and password flow in production, we recommend switching to other secure alternatives available for your scenario. + #### Find out if your code uses Username Password authentication The ADAL code for your app uses Username password authentication scenarios if it contains a call to `AcquireTokenAsync` available as an extension method of the `AuthenticationContextIntegratedAuthExtensions` class, with the following parameters: diff --git a/msal-dotnet-articles/how-to/token-cache-serialization.md b/msal-dotnet-articles/how-to/token-cache-serialization.md index ea4e45dd4..d6e10d47e 100644 --- a/msal-dotnet-articles/how-to/token-cache-serialization.md +++ b/msal-dotnet-articles/how-to/token-cache-serialization.md @@ -1,7 +1,6 @@ --- title: Token cache serialization description: Learn about serialization and custom serialization of the token cache using the Microsoft Authentication Library for .NET (MSAL.NET). -services: active-directory author: Dickson-Mwendia manager: CelesteDG @@ -9,7 +8,7 @@ ms.service: msal ms.subservice: msal-dotnet ms.topic: conceptual ms.workload: identity -ms.date: 08/24/2023 +ms.date: 05/20/2024 ms.author: dmwendia ms.reviewer: ddelimarsky, jmprieur ms.custom: devx-track-csharp, aaddev, has-adal-ref, devx-track-dotnet diff --git a/msal-dotnet-articles/resources/handling-pii.md b/msal-dotnet-articles/resources/handling-pii.md index 21c695d78..f8e7d7679 100644 --- a/msal-dotnet-articles/resources/handling-pii.md +++ b/msal-dotnet-articles/resources/handling-pii.md @@ -11,13 +11,13 @@ Microsoft defines the following [data classification](https://www.microsoft.com/ ## What MSAL will never log -- tokens (access tokens, ID tokens, refresh tokens, client assertions generated by MSAL, etc.) -- passwords (MSAL is only given the password during the Username / Password (ROPC) flow. MSAL does not have access to the password entered by the user in a browser.) -- authorization codes +- Tokens (access tokens, ID tokens, refresh tokens, client assertions generated by MSAL, etc.) +- Passwords (MSAL is only given the password during the Username / Password (ROPC) flow. MSAL does not have access to the password entered by the user in a browser.) +- Authorization codes - PKCE code -- successful network responses from the _/authorize_ or _/token_ endpoints (because they may contain tokens or auth codes) -- network requests (they may contain passwords) -- private keys of certificates +- Successful network responses from the _/authorize_ or _/token_ endpoints (because they may contain tokens or auth codes) +- Network requests (they may contain passwords) +- Private keys of certificates ## What MSAL considers as PII