Merge pull request #5400 from MicrosoftDocs/main

10/2/2024 AM Publish

docs/identity-platform/v2-oauth2-implicit-grant-flow.md

@@ -20,7 +20,7 @@ The Microsoft identity platform supports the OAuth 2.0 implicit grant flow as de
 [!INCLUDE [suggest-msal-from-protocols](includes/suggest-msal-from-protocols.md)]
 
 > [!WARNING]
-> Microsoft recommends you do *not* use the implicit grant flow flow. In most scenarios, more secure alternatives are available and recommended. Certain configurations of 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, see the [security concerns with implicit grant flow](#security-concerns-with-implicit-grant-flow).
+> Microsoft recommends you do *not* use the implicit grant flow. In most scenarios, more secure alternatives are available and recommended. Certain configurations of 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, see the [security concerns with implicit grant flow](#security-concerns-with-implicit-grant-flow).
 
 ## Protocol diagram
 
@@ -36,7 +36,7 @@ The implicit grant is only reliable for the initial, interactive portion of your
 
 With some browsers [removing support for third party cookies](reference-third-party-cookies-spas.md), the **implicit grant flow is no longer a suitable authentication method**. The [silent single sign-on (SSO) features](#acquire-access-tokens-silently) of the implicit flow don't work without third party cookies, causing applications to break when they attempt to get a new token. We strongly recommend that all new applications use the [authorization code flow](v2-oauth2-auth-code-flow.md) that now supports single-page apps in place of the implicit flow. Existing single-page apps should also [migrate to the authorization code flow](migrate-spa-implicit-to-auth-code.md).
 
-### Security Concerns with Implicit Grant Flow
+### Security concerns with implicit grant flow
 
 The implicit grant flow is intended for traditional web applications where the server has control over processing POST data securely. There are two main ways to deliver tokens with the implicit grant flow: where `response_mode` is returned as a URL fragment or as a query parameter (using `form POST` and `GET` ). In the implicit flow where `response_mode=form_post`, the token is delivered securely through an HTML form POST to the client's redirect URI. This method ensures that the token isn't exposed in the URL fragment, which in turn avoids the risks of token leakage through browser history or referrer headers. 
 

docs/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication.md

@@ -76,7 +76,7 @@ Users should have at least two authentication methods registered. With another m
 >It is always recommended that users have at least two authentication methods registered. This ensures the user has a backup method available if something happens to their primary method, such as in cases of device loss or theft. For example, it is a good practice for users to have passkeys registered both on their phone and locally on their workstation in Windows Hello for Business.
 
 >[!NOTE] 
->This guidance is tailored for currently existing support for passkeys in Microsoft Entra ID, which includes device-bound passkeys in Microsoft Authenticator and device-bound passkeys on physical security keys. Microsoft Entra ID plans to add support for synced passkeys. For more information, see [Public preview: Expanding passkey support in Microsoft Entra ID](https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-expanding-passkey-support-in-microsoft-entra-id/ba-p/4062702). 
+>This guidance is tailored for currently existing support for passkeys in Microsoft Entra ID, which includes device-bound passkeys in Microsoft Authenticator and device-bound passkeys on physical security keys. Microsoft Entra ID plans to add support for synced passkeys. For more information, see [Public preview: Expanding passkey support in Microsoft Entra ID](https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-expanding-passkey-support-in-microsoft-entra-id/ba-p/4062702). This guide will be updated to include synced passkey guidance once available. For example, many organizations may benefit from relying on sync for phase 3 in the preceding diagram rather than bootstrapping entirely new credentials.
 
 ### Onboarding step 1: Identity verification
 

docs/identity/authentication/how-to-plan-persona-phishing-resistant-passwordless-authentication.md

@@ -22,7 +22,9 @@ Each persona has its own challenges and considerations that commonly come up dur
 
 ## Information workers
 
-Information workers typically have the simplest requirements and are the easiest to begin your phishing-resistant passwordless deployment with. However, there are still some issues that frequently arise when deploying for these users. 
+Information workers typically have the simplest requirements and are the easiest to begin your phishing-resistant passwordless deployment with. However, there are still some issues that frequently arise when deploying for these users. Common examples include:
+
+:::image type="content" border="true" source="media/how-to-deploy-phishing-resistant-passwordless-authentication/information-worker-examples.png" alt-text="Diagram that shows examples of requirements for information workers.":::
 
 Information worker deployments, just like any other user persona, require proper communication and support. This commonly involves convincing users to install certain apps on their phones, distributing security keys where users won’t use apps, addressing concerns about biometrics, and developing processes for helping users recover from partial or total loss of their credentials.
 
@@ -73,6 +75,8 @@ Phases 1-3 of the deployment flow for frontline workers should typically follow
 
 IT pros and DevOps workers are especially reliant on remote access and multiple user accounts, which is why they are considered different from information workers. Many of the challenges posed by phishing-resistant passwordless for IT pros are caused by their increased need for remote access to systems and ability to run automations.
 
+:::image type="content" border="true" source="media/how-to-deploy-phishing-resistant-passwordless-authentication/it-pro-examples.png" alt-text="Diagram that shows examples of requirements for IT pro workers.":::
+
 Understand the supported options for phishing-resistant with RDP especially for this persona. 
 
 Make sure to understand where users are using scripts that run in the user context and are therefore not using MFA today. Instruct your IT pros on the proper way to run automations using service principals and managed identities. You should also consider processes to allow IT pros and other professionals to request new service principals and get the proper permissions assigned to them.

docs/identity/authentication/how-to-plan-prerequisites-phishing-resistant-passwordless-authentication.md

@@ -34,7 +34,7 @@ Microsoft Entra ID offers the following phishing-resistant passwordless authenti
   - Platform credential for macOS (preview)
   - Microsoft Authenticator app passkeys (preview)
   - FIDO2 security keys
-  - Other passkeys and providers
+  - Other passkeys and providers, such as iCloud Keychain - [**_on roadmap_**](https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-expanding-passkey-support-in-microsoft-entra-id/ba-p/4062702)
 - Certificate-based authentication/smart cards
 
 ## Prerequisites

docs/standards/nist-authenticator-assurance-level-1.md

@@ -38,7 +38,7 @@ To achieve AAL1, you can use any NIST single-factor or multifactor [permitted au
 
 
 > [!TIP]
-> We recommend you select at a minimum phishing resistant AAL2 authneticators. Select AAL3 authenticators as necessary for business reasons, industry standards, or compliance requirements.
+> We recommend you select at a minimum phishing resistant AAL2 authenticators. Select AAL3 authenticators as necessary for business reasons, industry standards, or compliance requirements.
 
 ## FIPS 140 validation
 

docs/verified-id/how-to-create-a-free-developer-account.md

@@ -44,7 +44,6 @@ If you decide to sign up for the free Microsoft 365 developer program, you need
 
 At this point, you've created a tenant with 25 E5 user licenses. The E5 licenses include Microsoft Entra ID P2 licenses. Optionally, you can add sample data packs with users, groups, mail, and SharePoint to help you test in your development environment. For the verifiable credential issuing service, they're not required.
 
-For your convenience, you could add your own work account as [guest](~/external-id/b2b-quickstart-add-guest-users-portal.md) in the newly created tenant and use that account to administer the tenant. If you want the guest account to be able to manage the verifiable credential service, you need to assign the *Global Administrator* role to that user.
 
 ## Next steps