Merge pull request #301268 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/api-management/api-management-sample-send-request.md

@@ -59,7 +59,7 @@ There are certain tradeoffs when using a fire-and-forget style of request. If fo
 The `send-request` policy enables using an external service to perform complex processing functions and return data to the API management service that can be used for further policy processing.
 
 ### Authorizing reference tokens
-A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWT tokens](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
+A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWTs](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
 
 ### Standardized introspection
 In the past, there has been no standardized way of verifying a reference token with an authorization server. However a recently proposed standard [RFC 7662](https://tools.ietf.org/html/rfc7662) was published by the IETF that defines how a resource server can verify the validity of a token.

articles/api-management/validate-jwt-policy.md

@@ -115,15 +115,15 @@ The `validate-jwt` policy enforces existence and validity of a supported JSON we
 
 ### Usage notes
 
-* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT token, unless `require-expiration-time` attribute is specified and set to `false`.
+* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT, unless `require-expiration-time` attribute is specified and set to `false`.
 * The policy supports both symmetric and asymmetric signing algorithms: 
     * **Symmetric** - The following encryption algorithms are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512.
     	* If used in the policy, the key must be provided inline within the policy in the Base64-encoded form.
     * **Asymmetric** - The following encryption algorithms are supported: PS256, RS256, RS512, ES256. 
     	* If used in the policy, the key may be provided either via an OpenID configuration endpoint, or by providing the ID of an uploaded certificate (in PFX format) that contains the public key, or the modulus-exponent pair of the public key.
 * To configure the policy with one or more OpenID configuration endpoints for use with a self-hosted gateway, the OpenID configuration endpoints URLs must also be reachable by the cloud gateway.
 * You can use access restriction policies in different scopes for different purposes. For example, you can secure the whole API with Microsoft Entra authentication by applying the `validate-jwt` policy on the API level, or you can apply it on the API operation level and use `claims` for more granular control.
-* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWT tokens must be provided in the `Authorization` header.
+* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWTs must be provided in the `Authorization` header.
 
 ## Examples
 

includes/api-management-gateway-role.md

@@ -9,7 +9,7 @@ ms.date: 08/04/2022
 Specifically, the gateway:
 
 * Acts as a facade to backend services by accepting API calls and routing them to appropriate backends
-* Verifies [API keys](../articles/api-management/api-management-subscriptions.md) and other credentials such as [JWT tokens and certificates](../articles/api-management/api-management-access-restriction-policies.md) presented with requests
+* Verifies [API keys](../articles/api-management/api-management-subscriptions.md) and other credentials such as [JWTs and certificates](../articles/api-management/api-management-access-restriction-policies.md) presented with requests
 * Enforces [usage quotas and rate limits](../articles/api-management/api-management-access-restriction-policies.md)
 * Optionally transforms requests and responses as specified in [policy statements](../articles/api-management/api-management-howto-policies.md)
 * If configured, [caches responses](../articles/api-management/api-management-howto-cache.md) to improve response latency and minimize the load on backend services