📝 Modified Documentation Files

MODIFIED docs/identity/app-provisioning/use-scim-to-provision-users-and-groups.md

Modified by Jeevan Desarda on Jul 24, 2026 8:08 PM
📖 View on learn.microsoft.com

+34 / -0 lines changed

Commit: Document Workload Identity Federation for SCIM provisioning

Changes:

Before

After

|Username and password (not recommended or supported by Microsoft Entra ID)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
|Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for existing apps and non-gallery apps. Not supported for new apps. |
|OAuth 2.0 client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Provisioning can be automated, and new tokens can be silently requested without user interaction. Publishers can configure SCIM jobs using client credentials regardless of app type. Each customer must provide their own Client ID and Client Secret to authenticate against the SCIM API. |  | Supported for gallery apps and non-gallery apps.|
 
> [!NOTE]
> OAuth authorization code grant is retired. New connectors don't support OAuth authorization code grant, and existing connectors should use the OAuth 2.0 client credentials grant.
 
For more authentication and authorization methods, let us know on [UserVoice](https://aka.ms/appprovisioningfeaturerequest).
 
### Gallery go-to-market launch check list
To help drive awareness and demand of our joint integration, we recommend you update your existing documentation and amplify the integration in your marketing channels. We recommend you to complete the following checklist to support the launch:

|Username and password (not recommended or supported by Microsoft Entra ID)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
|Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for existing apps and non-gallery apps. Not supported for new apps. |
|OAuth 2.0 client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Provisioning can be automated, and new tokens can be silently requested without user interaction. Publishers can configure SCIM jobs using client credentials regardless of app type. Each customer must provide their own Client ID and Client Secret to authenticate against the SCIM API. |  | Supported for gallery apps and non-gallery apps.|
|Workload Identity Federation|No secrets are stored in the provisioning configuration. Microsoft Entra ID authenticates by presenting a short-lived, signed JWT assertion (OAuth 2.0 JWT bearer profile, [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), which removes the burden of secret storage and rotation and reduces the risk of credential leakage.|Requires the ISV to support JWKS-based validation of the Entra-issued JWT and a token endpoint that issues access tokens for the SCIM endpoint.|Supported for gallery apps and non-gallery apps.|
 
> [!NOTE]
> OAuth authorization code grant is retired. New connectors don't support OAuth authorization code grant, and existing connectors should use the OAuth 2.0 client credentials grant.
 
For more authentication and authorization methods, let us know on [UserVoice](https://aka.ms/appprovisioningfeaturerequest).
 
### Workload Identity Federation
 
The provisioning service supports Workload Identity Federation (WIF). With WIF, no long-lived secrets are stored in the provisioning configuration. Instead, Microsoft Entra ID presents a short-lived, signed JWT assertion to your token endpoint using the OAuth 2.0 JWT bearer profile ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)) and receives an access token that's used to call your SCIM endpoint. To support WIF, your service must trust tokens issued by Microsoft Entra ID and validate them against Microsoft's published JWKS. After submitting your request for publishing your app in the gallery, our team will work with you to enable this method.
 
When you configure WIF, Microsoft Entra ID provides the following values to be copied into your (the ISV's) portal so that your token endpoint can validate the assertion:
 
- **Issuer (iss):** The customer tenant v2.0 issuer, for example `https://login.microsoftonline.com/<TenantID>/v2.0`.
- **JWKS URL:** The public signing keys used to verify the assertion, for example `https://login.microsoftonline.com/<TenantID>/discovery/v2.0/keys`.
- **Subject (sub):** The Sync Fabric workload identity first-party app object ID.
- **Audience (aud):** The workload identity application ID URI, for example `api://{WorkloadIdentity_appid}/.default`.

MODIFIED docs/identity/saas-apps/salesforce-tutorial.md

Modified by Jeevan Desarda on Jul 24, 2026 6:11 PM
📖 View on learn.microsoft.com

+4 / -7 lines changed

Commit: Update Salesforce SSO tutorials: revise amr/acr note and add federation guidance

Changes:

Before

After

* Manage your accounts in one central location.
 
> [!Note]
> **Updated: June 24, 2026** - Starting June 29, 2026, Microsoft Entra ID will automatically include Authentication Method References (`amr`) and Authentication Context References (`acr`) claims in tokens issued for SAML 2.0 and OpenID Connect (OIDC) applications using the Microsoft identity platform v2.0 endpoint. These claims provide additional information about how the user authenticated and the authentication context satisfied during sign-in. No configuration changes are required in Microsoft Entra ID for Salesforce single sign-on. To help satisfy Salesforce [phishing-resistant MFA requirements](https://help.salesforce.com/s/articleView?id=005321563&type=1) for Salesforce admins, customers should apply Microsoft Entra Conditional Access policies that require phishing-resistant authentication methods for Salesforce administrator sign-ins
 
> [!Note]
>   We are aware that Salesforce has enforced the [device activation changes for Single Sign-On (SSO) Logins](https://help.salesforce.com/s/articleView?id=005237070&type=1) starting **February 3, 2026**. We have worked closely with the Salesforce team, and beginning February 3, Salesforce will start accepting the **authnmethodreferences** claim included by default in the SAML token issued by Entra ID. If the **authnmethodreferences** claim contains the value **multipleauthn**, Salesforce will treat the device as trusted. Please ensure that your Conditional Access policy which will enforce MFA is configured to satisfy this requirement. You can read more about this claim in [SAML single sign-on protocol AuthnMethodReferences](~/identity-platform/single-sign-on-saml-protocol.md#authnmethodreferences).
> 
>   For customers using [OpenID Connect Authentication with Salesforce](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_microsoft_only.htm&type=5) or if you have configured Salesforce with [custom OpenID Connect provider](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_plugin_custom.htm&type=5), you can switch back to the Microsoft identity platform v2.0 endpoint. The v2.0 endpoint now sends the `amr` claim in the token as needed by Salesforce based on the user's authentication.
>
>  For customers using AD FS as the federation provider with Entra ID, please follow the [MFA expected inbound assertions guidance for SAML 2.0 federated IdPs](~/identity/authentication/how-to-mfa-expected-inbound-assertions.md#using-saml-20-federated-idp) so that Entra ID will have this claim in the SAML token.
 
## Prerequisites
 

* Manage your accounts in one central location.
 
> [!Note]
> **Updated: July 24, 2026** - Starting June 29, 2026, Microsoft Entra ID will automatically include Authentication Method References (`amr`) and Authentication Context References (`acr`) claims in tokens issued for SAML 2.0 and OpenID Connect (OIDC) applications using the Microsoft identity platform v2.0 endpoint. **If you have configured External MFA Provider with Entra ID and if that provider is sending AMR signals then Entra ID will forward that AMR signal to Salesforce or other 3P applications as needed.** These claims provide additional information about how the user authenticated and the authentication context satisfied during sign-in. No configuration changes are required in Microsoft Entra ID for Salesforce single sign-on. To help satisfy Salesforce [phishing-resistant MFA requirements](https://help.salesforce.com/s/articleView?id=005321563&type=1) for Salesforce admins, customers should apply Microsoft Entra Conditional Access policies that require phishing-resistant authentication methods for Salesforce administrator sign-ins.
>
> For customers using AD FS as the federation provider with Entra ID, please follow the [MFA expected inbound assertions guidance for SAML 2.0 federated IdPs](~/identity/authentication/how-to-mfa-expected-inbound-assertions.md#using-saml-20-federated-idp) so that Entra ID will have this claim in the SAML token.
>
> If you are using any other federation provider then we are still working on standardizing the AMR and ACR signals first and will provide the update soon.
 
## Prerequisites

MODIFIED docs/identity/saas-apps/salesforce-sandbox-tutorial.md

Modified by Jeevan Desarda on Jul 24, 2026 6:11 PM
📖 View on learn.microsoft.com

+3 / -6 lines changed

Commit: Update Salesforce SSO tutorials: revise amr/acr note and add federation guidance

Changes:

Before

After

* Manage your accounts in one central location.
 
> [!Note]
> **Updated: June 24, 2026** - Starting June 29, 2026, Microsoft Entra ID will automatically include Authentication Method References (`amr`) and Authentication Context References (`acr`) claims in tokens issued for SAML 2.0 and OpenID Connect (OIDC) applications using the Microsoft identity platform v2.0 endpoint. These claims provide additional information about how the user authenticated and the authentication context satisfied during sign-in. No configuration changes are required in Microsoft Entra ID for Salesforce Sandbox single sign-on. To help satisfy Salesforce [phishing-resistant MFA requirements](https://help.salesforce.com/s/articleView?id=005321563&type=1) for Salesforce admins, customers should apply Microsoft Entra Conditional Access policies that require phishing-resistant authentication methods for Salesforce administrator sign-ins. 
 
> [!Note]
>   We are aware that Salesforce will enforce the [device activation changes for Single Sign-On (SSO) Logins](https://help.salesforce.com/s/articleView?id=005237070&type=1) starting **February 3, 2026**. We have worked closely with the Salesforce team, and beginning February 3, Salesforce will start accepting the **authnmethodreferences** claim included by default in the SAML token issued by Entra ID. If the **authnmethodreferences** claim contains the value **multipleauthn**, Salesforce will treat the device as trusted. Please ensure that your Conditional Access policy which will enforce MFA is configured to satisfy this requirement. You can read more about this claim [here](~/identity-platform/single-sign-on-saml-protocol.md#authnmethodreferences).
>
>   For customers using [OpenID Connect Authentication with Salesforce](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_microsoft_only.htm&type=5) or if you have configured Salesforce with [custom OpenID Connect provider](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_plugin_custom.htm&type=5), you can switch back to the Microsoft identity platform v2.0 endpoint. The v2.0 endpoint now sends the `amr` claim in the token as needed by Salesforce based on the user's authentication.
>
>  For customers using AD FS as the federation provider with Entra ID, please follow the guidance published [here](~/identity/authentication/how-to-mfa-expected-inbound-assertions.md#using-saml-20-federated-idp) so that Entra ID will have this claim in the SAML token.
 
## Prerequisites
The scenario outlined in this article assumes that you already have the following prerequisites:

* Manage your accounts in one central location.
 
> [!Note]
> **Updated: July 24, 2026** - Starting June 29, 2026, Microsoft Entra ID will automatically include Authentication Method References (`amr`) and Authentication Context References (`acr`) claims in tokens issued for SAML 2.0 and OpenID Connect (OIDC) applications using the Microsoft identity platform v2.0 endpoint. **If you have configured External MFA Provider with Entra ID and if that provider is sending AMR signals then Entra ID will forward that AMR signal to Salesforce or other 3P applications as needed.** These claims provide additional information about how the user authenticated and the authentication context satisfied during sign-in. No configuration changes are required in Microsoft Entra ID for Salesforce Sandbox single sign-on. To help satisfy Salesforce [phishing-resistant MFA requirements](https://help.salesforce.com/s/articleView?id=005321563&type=1) for Salesforce admins, customers should apply Microsoft Entra Conditional Access policies that require phishing-resistant authentication methods for Salesforce administrator sign-ins.
>
> For customers using AD FS as the federation provider with Entra ID, please follow the [MFA expected inbound assertions guidance for SAML 2.0 federated IdPs](~/identity/authentication/how-to-mfa-expected-inbound-assertions.md#using-saml-20-federated-idp) so that Entra ID will have this claim in the SAML token.
>
> If you are using any other federation provider then we are still working on standardizing the AMR and ACR signals first and will provide the update soon.
 
## Prerequisites
The scenario outlined in this article assumes that you already have the following prerequisites:
 
 
 

MODIFIED docs/identity/enterprise-apps/v2-howto-app-gallery-listing.md

Modified by Jeevan Desarda on Jul 24, 2026 8:03 PM
📖 View on learn.microsoft.com

+6 / -3 lines changed

Commit: Add WIF auth method to App Gallery listing and remove SCIM Validator references

Changes:

Before

After

- To implement support of SCIM 2.0 Provisioning follow this tutorial: [build a SCIM endpoint and configure user provisioning with Microsoft Entra ID](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md)
 
    - If you already support SCIM 2.0 in your application, then you must support client credentials flow for authentication in SCIM. We aren't onboarding applications that use basic authentication, long lived bearer tokens or using code grants for authentication. We recommend you use Client Credentials flow as articulated [here](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#oauth-20-client-credentials-grant-flow)
    - Make sure that you're testing the SCIM implementation and client credentials authentication flow using SCIM Validator tool. You can learn more about it from here: [Use the SCIM validator tool to validate your SCIM endpoint](~/identity/app-provisioning/scim-validator-tutorial.md)
    - Additionally you also need to test the provisioning implementation using the non-gallery application in Microsoft Entra ID. You can also test the Client Credentials flow using non-gallery application template. You can learn more about it from here: [Test user provisioning with a non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started)
 
You can sign up for a free, test Development account. It's free for 90 days and you get all of the premium Microsoft Entra features with it. You can also extend the account if you use it for development work: [Join the Microsoft 365 Developer Program](/office/developer-program/microsoft-365-developer-program).
 
- Support a SCIM 2.0 user and group endpoint (Only User Provisioning is required but User and Group Provisioning both are recommended).
- Support at least 25 requests per second per tenant to ensure that users and groups are provisioned and deprovisioned without delay (Required).
- Validate and test your SCIM User and/or Group Provisioning integration with [SCIM Validator](~/identity/app-provisioning/scim-validator-tutorial.md) and [non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started) template (Required).
- Validate your Client Credentials authentication or any other supported authentication using [non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started) or using [SCIM Validator](~/identity/app-provisioning/scim-validator-tutorial.md) (Required).
- Support either soft delete or hard delete of users. Either one is needed, both are also supported (Required).
- On querying a nonexistent user your SCIM server shouldn't return bad request, rather success with 0 results (Required).
- Support Schema Discovery feature on your SCIM endpoint (Required).
    - Provide the ability to rotate client secrets regularly. ISVs should enable smooth rotation by allowing multiple active secrets and supporting deletion of old secrets. Alternatively, customers can create new client_id and client_secret.
    - Access Token should be only valid for 60 minutes (1 hour) to 6 hours but not less than 60 minutes (Required)
 
### ISV requirements for SCIM apps
 

- To implement support of SCIM 2.0 Provisioning follow this tutorial: [build a SCIM endpoint and configure user provisioning with Microsoft Entra ID](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md)
 
    - If you already support SCIM 2.0 in your application, then you must support client credentials flow for authentication in SCIM. We aren't onboarding applications that use basic authentication, long lived bearer tokens or using code grants for authentication. We recommend you use Client Credentials flow as articulated [here](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#oauth-20-client-credentials-grant-flow)
    - Additionally you also need to test the provisioning implementation using the non-gallery application in Microsoft Entra ID. You can also test the Client Credentials flow using non-gallery application template. You can learn more about it from here: [Test user provisioning with a non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started)
 
You can sign up for a free, test Development account. It's free for 90 days and you get all of the premium Microsoft Entra features with it. You can also extend the account if you use it for development work: [Join the Microsoft 365 Developer Program](/office/developer-program/microsoft-365-developer-program).
 
- Support a SCIM 2.0 user and group endpoint (Only User Provisioning is required but User and Group Provisioning both are recommended).
- Support at least 25 requests per second per tenant to ensure that users and groups are provisioned and deprovisioned without delay (Required).
- Validate and test your SCIM User and/or Group Provisioning integration with [non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started) template (Required).
- Validate your Client Credentials authentication or any other supported authentication using [non-gallery application](~/identity/app-provisioning/use-scim-to-provision-users-and-groups.md#getting-started) (Required).
- Support either soft delete or hard delete of users. Either one is needed, both are also supported (Required).
- On querying a nonexistent user your SCIM server shouldn't return bad request, rather success with 0 results (Required).
- Support Schema Discovery feature on your SCIM endpoint (Required).
    - Provide the ability to rotate client secrets regularly. ISVs should enable smooth rotation by allowing multiple active secrets and supporting deletion of old secrets. Alternatively, customers can create new client_id and client_secret.
    - Access Token should be only valid for 60 minutes (1 hour) to 6 hours but not less than 60 minutes (Required)
 
- Workload Identity Federation (Recommended)
 
    Workload Identity Federation (WIF) is a newer authentication method that lets the Microsoft Entra provisioning service authenticate to your SCIM endpoint without storing any long-lived secrets. Instead of a shared client secret or bearer token, Entra ID presents a signed JWT assertion to your token endpoint using the OAuth 2.0 JWT bearer profile defined in [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523), and receives a short-lived access token in return. Because trust is established through cryptographic verification of Entra-issued tokens rather than stored credentials, there are no secrets to rotate and less risk of credential leakage. To support WIF, your token endpoint must validate the Entra-issued JWT against Microsoft's published JWKS and issue access tokens scoped to your SCIM endpoint. For the full configuration flow, token claims, and ISV implementation requirements, see the [Workload Identity Federation for SCIM provisioning guide](https://github.com/AzureAD/SCIMReferenceCode/blob/master/Workload-Identity-Federation-for-SCIM-Provisioning.md).

MODIFIED docs/identity-platform/access-token-claims-reference.md

Modified by vimrang on Jul 24, 2026 6:56 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Revise 'amr' claim description in access token reference

Changes:

Before

After

| `exp` | int, a Unix timestamp | Specifies the expiration time before which the JWT can be accepted for processing. A resource may reject the token before this time as well. The rejection can occur for a required change in authentication or when a token is revoked. | |
| `aio` | Opaque String | An internal claim used by Microsoft Entra ID to record data for token reuse. Resources shouldn't use this claim. | |
| `acr` | String, a `0` or `1`, only present in v1.0 tokens | A value of `0` for the "Authentication context class" claim indicates the end-user authentication didn't meet the requirements of ISO/IEC 29115. | |
| `amr` | JSON array of strings, only present in v1.0 tokens | Identifies the authentication method of the subject of the token. | |
| `appid` | String, a GUID, only present in v1.0 tokens | The application ID of the client using the token. The application can act as itself or on behalf of a user. The application ID typically represents an application object, but it can also represent a service principal object in Microsoft Entra ID. |  `appid` may be used in authorization decisions. |
| `azp` | String, a GUID, only present in v2.0 tokens | A replacement for `appid`. The application ID of the client using the token. The application can act as itself or on behalf of a user. The application ID typically represents an application object, but it can also represent a service principal object in Microsoft Entra ID. | `azp` may be used in authorization decisions. |
| `appidacr` | String, a `0`, `1`, or `2`, only present in v1.0 tokens | Indicates authentication method of the client. For a public client, the value is `0`. When you use the client ID and client secret, the value is `1`. When you use a client certificate for authentication, the value is `2`. | |

| `exp` | int, a Unix timestamp | Specifies the expiration time before which the JWT can be accepted for processing. A resource may reject the token before this time as well. The rejection can occur for a required change in authentication or when a token is revoked. | |
| `aio` | Opaque String | An internal claim used by Microsoft Entra ID to record data for token reuse. Resources shouldn't use this claim. | |
| `acr` | String, a `0` or `1`, only present in v1.0 tokens | A value of `0` for the "Authentication context class" claim indicates the end-user authentication didn't meet the requirements of ISO/IEC 29115. | |
| `amr` | JSON array of strings | Identifies the authentication method of the subject of the token. | |
| `appid` | String, a GUID, only present in v1.0 tokens | The application ID of the client using the token. The application can act as itself or on behalf of a user. The application ID typically represents an application object, but it can also represent a service principal object in Microsoft Entra ID. |  `appid` may be used in authorization decisions. |
| `azp` | String, a GUID, only present in v2.0 tokens | A replacement for `appid`. The application ID of the client using the token. The application can act as itself or on behalf of a user. The application ID typically represents an application object, but it can also represent a service principal object in Microsoft Entra ID. | `azp` may be used in authorization decisions. |
| `appidacr` | String, a `0`, `1`, or `2`, only present in v1.0 tokens | Indicates authentication method of the client. For a public client, the value is `0`. When you use the client ID and client secret, the value is `1`. When you use a client certificate for authentication, the value is `2`. | |

📋 Microsoft Entra Documentation Changes

📊 Summary

📝 Modified Documentation Files