Merge pull request #25078 from microsoftgraph/nickludwig-patch-1

Update federatedidentitycredentials-overview.md

Author: Lauragra

api-reference/v1.0/resources/federatedidentitycredentials-overview.md

@@ -1,6 +1,6 @@
 ---
 title: "Overview of federated identity credentials in Microsoft Entra ID"
-description: "Federated identity credentials allow you to access Azure and Microsoft Graph resources without having to manage secrets. This is part of workload identity federation in Azure AD."
+description: "Federated identity credentials allow you to access Microsoft Entra and Microsoft Graph resources without having to manage secrets. Federated identity credentials are part of workload identity federation in Microsoft Entra ID."
 author: "nickludwig"
 ms.localizationpriority: medium
 ms.subservice: "entra-applications"
@@ -13,7 +13,7 @@ ms.date: 08/03/2022
 Namespace: microsoft.graph
 
 
-Traditionally, developers use certificates or client secrets for their application's credentials to authenticate with and access services in Microsoft Entra ID. To access the services in their Microsoft Entra tenant, developers have had to store and manage application credentials outside Azure, introducing the following bottlenecks:
+Traditionally, developers use certificates or client secrets for their application's credentials to authenticate with and access services in Microsoft Entra ID. To access the services in their Microsoft Entra tenant, developers had to store and manage application credentials outside Azure, introducing the following bottlenecks:
 
 + A maintenance burden for certificates and secrets.
 + The risk of leaking secrets.
@@ -23,7 +23,10 @@ Traditionally, developers use certificates or client secrets for their applicati
 
 ## How do federated identity credentials work?
 
-You create a trust relationship between an external identity provider (IdP) and an app in Microsoft Entra ID by configuring a federated identity credential. The federated identity credential is used to indicate which token from the external IdP should be trusted by your application. After that trust relationship is created, your software workload can exchange trusted tokens from the external identity provider for access tokens from the Microsoft identity platform. Your software workload then uses that access token to access the Microsoft Entra protected resources to which the workload has been granted access. This eliminates the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire. For more information and supported scenarios, see [workload identity federation](/azure/active-directory/develop/workload-identity-federation).
+You create a trust relationship between an external identity provider (IdP) and an app in Microsoft Entra ID by configuring a federated identity credential. The federated identity credential is used to indicate which token from the external IdP your application can trust. After that trust relationship is created, your software workload can exchange trusted tokens from the external identity provider for access tokens from the Microsoft identity platform. Your software workload then uses that access token to access the Microsoft Entra protected resources to which the workload has access. This process eliminates the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire. For more information and supported scenarios, see [workload identity federation](/azure/active-directory/develop/workload-identity-federation).
+
+> [!NOTE]
+> The match performed between the Federated Identity Credential `issuer`, `subject`, and `audience` values and the corresponding values in the token being sent to Microsoft Entra ID by the external IdP is case-sensitive. These values must match exactly in order for the scenario to be authorized. For more information,see [Federated Identity Credentials now use case-sensitive matching](/entra/identity-platform/reference-breaking-changes#federated-identity-credentials-now-use-case-sensitive-matching).
 
 ## Set up federated identity credentials through Microsoft Graph
 
@@ -34,7 +37,7 @@ The [federatedIdentityCredential](federatedidentitycredential.md) resource repre
 + **subject** - The identifier of the external software workload within the external identity provider. Like the audience value, it has no fixed format, as each IdP uses their own - sometimes a GUID, sometimes a colon delimited identifier, sometimes arbitrary strings. The value here must match the `sub` claim within the token presented to Microsoft Entra ID.
 + **name** - A unique string to identify the credential. This property is an alternate key and the value can be used to reference the federated identity credential via the [GET](../api/federatedidentitycredential-get.md) and [UPSERT](../api/federatedidentitycredential-upsert.md) operations.
 
-The combination of **issuer** and **subject** must be unique on the app.  When the external software workload requests Microsoft identity platform to exchange the external token for an access token, the **issuer** and **subject** values of the federated identity credential are checked against the `issuer` and `subject` claims provided in the external token. If that validation check passes, Microsoft identity platform issues an access token to the external software workload.
+The combination of **issuer** and **subject** must be unique on the app. When the external software workload requests Microsoft identity platform to exchange the external token for an access token, the **issuer** and **subject** values of the federated identity credential are checked against the `issuer` and `subject` claims provided in the external token. If that validation check passes, Microsoft identity platform issues an access token to the external software workload.
 
 
 ## Design considerations