How to validate JWT with only a public key

Question

How to validate JWT with only a public key

Neščivera Ján (ERNI) 65

Hello,

we have an APIM policy attempting to validate incoming JWT using public key modulus, exponent and id.

This policy however seems to not validate JWT signature for some reason. When I change key modulus, exponent or id, the validation still passes and request is forwarder to backend. If I change audience or issuer in the policy, the validation fails as expected.

What is the proper way to validate incoming JWT when we only have acess to public key of the identity provider?

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T09:14:33.48+00:00

unfortunatelly I can not add the coresponding policy to the question, as it immedietely gets deleted for violating code of conduct (altought its just a simple XML)
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T09:22:34.9566667+00:00

the screenshot of corresponding policy fragment (as when adding as XML its flagged as violating Code of conduct)
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T11:28:56.4233333+00:00

hi, I already have the setup as you describe in option #1 - I added the screenshot of the policy fragment as the separate comment (as a screenshot, becasue adding XML immediatelly flags the comment as violating the Code of conduct).
The problem is that its not working. As decribed in my original question - the JWTs pass as valid even if the kid is not matching the one specified in the policy. Also modulus and exponet seem to be ignored as when I chage them in policy to have some wrong values, the validation passes and request is forwarded to backend.

The only change to your sample is that I am using named values in the policy fragment. But even if I alter the policy to use the values directly, it still passes validation, when it should not.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-05-18T12:33:54.9566667+00:00
Based on the additional details you provided, the behavior—where JWT validation succeeds even when the kid, modulus (n), or exponent (e) are incorrect—strongly indicates that signature validation is not being enforced at all, even though the policy appears correctly configured. When using <openid-config>, APIM dynamically retrieves signing keys (JWKS) and performs signature validation internally based on the kid in the token header. However, if APIM fails to correctly resolve or bind the signing keys (for example, due to JWKS fetch issues, caching inconsistencies, missing kid handling, or internal fallback behavior), it may silently skip signature validation and still validate issuer and audience. This explains why modifying issuer/audience fails as expected, but changing kid, n, or e does not impact validation. Additionally, specifying issuer-signing-keys alongside <openid-config> or relying on named values does not override this behavior if APIM prioritizes the OpenID configuration. In such cases, incorrect or mismatched keys are effectively ignored, resulting in requests being forwarded without cryptographic verification.

Refer below points to resolve this issue or this is the workaround

Force strict signature validation and confirm APIM is actually validating signatures Ensure the following attribute is present:

require-signed-tokens="true"

Then test with a deliberately tampered token (modify payload slightly). If the request still succeeds, it confirms signature validation is being skipped.

Verify JWKS retrieval and key resolution via APIM trace Enable tracing and specifically check:

Whether OpenID configuration is successfully fetched

Whether JWKS keys are retrieved

Whether a key is selected based on kid

Whether signature validation step is executed

If trace does not show key selection or signature validation, APIM is not applying the signing keys.

Check behavior when JWT has incorrect or missing kid APIM relies on kid to select the correct key from JWKS. If:

kid does not exist in JWKS

or token has no kid

APIM should fail validation. If it does not, this indicates a fallback or incorrect validation path. Validate token header explicitly:

{ "alg": "RS256", "kid": "expected-key-id" }

Ensure OpenID configuration is the only source of truth (remove any manual key overrides) Do not mix <issuer-signing-keys> with <openid-config>. Keep policy strictly as:

<validate-jwt header-name="Authorization" require-scheme="Bearer" require-signed-tokens="true"> <openid-config url="https://<issuer>/.well-known/openid-configuration" /> <audiences> <audience>your-audience</audience> </audiences> <issuers> <issuer>https://your-issuer</issuer> </issuers> </validate-jwt>

Rule out named values issue by testing hardcoded configuration Although you mentioned trying this, ensure:

No encoding issues in named values

No extra whitespace/formatting issues Sometimes named values can introduce subtle formatting problems that cause APIM to ignore parts of the configuration.

Consider APIM caching or gateway inconsistency APIM caches OpenID configuration and JWKS. Try:

Re-deploying the policy

Restarting gateway (if self-hosted)

Waiting for cache refresh

Answer accepted by question author

Siddhesh Desai 8,210 Microsoft External Staff Moderator

Hey @Neščivera Ján (ERNI)

Thank you for reaching out to Microsoft Q&A.

As discussed on teams and with the Product team backend.

The validation is failing as expected now when n/e changes to some wrong value however when key id in policy is changed to some wrong value (aka. value not matching kid claim in JWT), the JWT validation passes which is an expected behavior. The Product team will update the Documentation accordingly.

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Neščivera Ján (ERNI) 65 Reputation points

2026-05-25T11:01:55.1533333+00:00

Hello,

as written in my original question and as visible in provided policy configuration, there is no <openid-config> in our policy, so the suggestions you provided are not relewant
Pravallika KV 18,855 Reputation points Microsoft External Staff Moderator

2026-05-25T13:57:00.8133333+00:00
@Neščivera Ján (ERNI) ,Could you please confirm the following:

What is the alg value in the JWT header, for example RS256, HS256?

Is the policy fragment containing <validate-jwt> definitely applied in the inbound processing pipeline of the API being tested?
Neščivera Ján (ERNI) 65 Reputation points

2026-05-25T15:31:34.35+00:00

Hello,

the alg value in our JWTs is RS256. The policy fragment is applied to in the inbound processing pipeline of our API operations that need the JWT validated (but seems to work for audience/issuer only, unfortunatelly).

Is there a way to debug the pipeline processing and see why the policy fragment cosidered the JWT valid even with mismatched key id? It really seems that signature validation is for some reason skipped/ignored, only audience and issuer work.
Pravallika KV 18,855 Reputation points Microsoft External Staff Moderator

2026-05-25T15:45:54.9066667+00:00

You can try debugging this using APIM Trace.

Enable Trace in the Azure Portal: Go to your API in APIM=> Open Test tab => Send a request with a valid JWT=>Enable Trace and inspect the validate-jwt step.

You should see whether APIM is selecting the signing key (kid), performing signature verification or only validating issuer/audience/claims.

If there is no key resolution or signature validation step in the trace, then the <issuer-signing-keys> block is not being applied during execution. Also verify the effective policy at runtime (API / operation / product level), since another policy layer can override or bypass signature validation.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-26T12:51:35.8266667+00:00

hello,

I checked it with tracing and I can see that the policy fragmet is included as expected. If I change the audence in policy fragment I can see in trace that it evaluated the audience and failed. With correct audience I can see in trace the message "JWT validation succeeded". Nothing regarding evaluating the signature.

Even if i change the kid to some wrong value, the only message in trace is "JWT validation succeeded", so the <issuer-sogning-key> is ignored for some reason.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-05-26T14:11:03.65+00:00

Hi @Neščivera Ján (ERNI)

Can you send me your email id in the Private chat?

I'd like to connect with you on teams and check the set up?
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-06-01T02:05:11.4933333+00:00

Hi @Neščivera Ján (ERNI)

I received an update from the backend team. They have provided below hypothesis:

The observed behavior is by-design. The id attribute on <key> in the validate-jwt policy is a key selection hint (JWT kid matching), not a security validation constraint. The Microsoft.IdentityModel library's default behavior when no key matches by kid is to try all configured signing keys. With only one RSA key configured, the correct n/e parameters always result in successful cryptographic validation regardless of kid value.

So, what you are observing is a default behavior by design and they are going to update the MS Documentation outlining this limitation.
Neščivera Ján (ERNI) 65 Reputation points

2026-06-01T06:38:34.1766667+00:00

Hello,

the ignorance of kid is not the main issue. The main issue is that even when key's n or e are changed to some icorrect value, the validation of JWT passes, allowing the JWTs that are not signed with correct key to be acecped and this is a security issue
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-06-01T14:47:24.2+00:00

Hi @Neščivera Ján (ERNI) I have forwarded your query to the backend team, they have asked for below API inspector trace:

Can you please provide me the API Trace by referring this Document: Tutorial: Debug APIs in Azure API Management using request tracing | Microsoft Learn >> I need to send it to the backend team.

1 additional answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T09:14:33.48+00:00

unfortunatelly I can not add the coresponding policy to the question, as it immedietely gets deleted for violating code of conduct (altought its just a simple XML)
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T09:22:34.9566667+00:00

the screenshot of corresponding policy fragment (as when adding as XML its flagged as violating Code of conduct)
Neščivera Ján (ERNI) 65 Reputation points

2026-05-12T11:28:56.4233333+00:00

hi, I already have the setup as you describe in option #1 - I added the screenshot of the policy fragment as the separate comment (as a screenshot, becasue adding XML immediatelly flags the comment as violating the Code of conduct).
The problem is that its not working. As decribed in my original question - the JWTs pass as valid even if the kid is not matching the one specified in the policy. Also modulus and exponet seem to be ignored as when I chage them in policy to have some wrong values, the validation passes and request is forwarded to backend.

The only change to your sample is that I am using named values in the policy fragment. But even if I alter the policy to use the values directly, it still passes validation, when it should not.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-25T11:01:55.1533333+00:00

Hello,

as written in my original question and as visible in provided policy configuration, there is no <openid-config> in our policy, so the suggestions you provided are not relewant
Pravallika KV 18,855 Reputation points Microsoft External Staff Moderator

2026-05-25T13:57:00.8133333+00:00

@Neščivera Ján (ERNI) ,Could you please confirm the following:

What is the alg value in the JWT header, for example RS256, HS256?

Is the policy fragment containing <validate-jwt> definitely applied in the inbound processing pipeline of the API being tested?
Neščivera Ján (ERNI) 65 Reputation points

2026-05-25T15:31:34.35+00:00

Hello,

the alg value in our JWTs is RS256. The policy fragment is applied to in the inbound processing pipeline of our API operations that need the JWT validated (but seems to work for audience/issuer only, unfortunatelly).

Is there a way to debug the pipeline processing and see why the policy fragment cosidered the JWT valid even with mismatched key id? It really seems that signature validation is for some reason skipped/ignored, only audience and issuer work.
Pravallika KV 18,855 Reputation points Microsoft External Staff Moderator

2026-05-25T15:45:54.9066667+00:00

You can try debugging this using APIM Trace.

Enable Trace in the Azure Portal: Go to your API in APIM=> Open Test tab => Send a request with a valid JWT=>Enable Trace and inspect the validate-jwt step.

You should see whether APIM is selecting the signing key (kid), performing signature verification or only validating issuer/audience/claims.

If there is no key resolution or signature validation step in the trace, then the <issuer-signing-keys> block is not being applied during execution. Also verify the effective policy at runtime (API / operation / product level), since another policy layer can override or bypass signature validation.
Neščivera Ján (ERNI) 65 Reputation points

2026-05-26T12:51:35.8266667+00:00

hello,

I checked it with tracing and I can see that the policy fragmet is included as expected. If I change the audence in policy fragment I can see in trace that it evaluated the audience and failed. With correct audience I can see in trace the message "JWT validation succeeded". Nothing regarding evaluating the signature.

Even if i change the kid to some wrong value, the only message in trace is "JWT validation succeeded", so the <issuer-sogning-key> is ignored for some reason.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-05-26T14:11:03.65+00:00

Hi @Neščivera Ján (ERNI)

Can you send me your email id in the Private chat?

I'd like to connect with you on teams and check the set up?
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-06-01T02:05:11.4933333+00:00

Hi @Neščivera Ján (ERNI)

I received an update from the backend team. They have provided below hypothesis:

The observed behavior is by-design. The id attribute on <key> in the validate-jwt policy is a key selection hint (JWT kid matching), not a security validation constraint. The Microsoft.IdentityModel library's default behavior when no key matches by kid is to try all configured signing keys. With only one RSA key configured, the correct n/e parameters always result in successful cryptographic validation regardless of kid value.

So, what you are observing is a default behavior by design and they are going to update the MS Documentation outlining this limitation.
Neščivera Ján (ERNI) 65 Reputation points

2026-06-01T06:38:34.1766667+00:00

Hello,

the ignorance of kid is not the main issue. The main issue is that even when key's n or e are changed to some icorrect value, the validation of JWT passes, allowing the JWTs that are not signed with correct key to be acecped and this is a security issue
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-06-01T14:47:24.2+00:00

Hi @Neščivera Ján (ERNI) I have forwarded your query to the backend team, they have asked for below API inspector trace:

Can you please provide me the API Trace by referring this Document: Tutorial: Debug APIs in Azure API Management using request tracing | Microsoft Learn >> I need to send it to the backend team.

Answer 1

Use the validate-jwt policy with an asymmetric issuer signing key configured from the public key. The signature is validated against the public key; if the modulus/exponent are wrong, validation must fail.

To validate with only a public key, configure one of these options in the validate-jwt policy:

Use an OpenID configuration endpoint (recommended)

<validate-jwt header-name="Authorization" require-scheme="Bearer">
  <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
  <audiences>
    <audience>api://your-api-app-id</audience>
  </audiences>
  <issuers>
    <issuer>https://login.microsoftonline.com/{tenant}/v2.0</issuer>
  </issuers>
</validate-jwt>

openid-config causes API Management to pull the JWKS (public keys) from the identity provider and use them to validate the JWT signature. This is the simplest and most robust way when only the public key is available.

Use modulus and exponent directly

If the OpenID configuration endpoint cannot be used, specify the RSA public key via issuer-signing-keys with n and e:

<validate-jwt header-name="Authorization" require-scheme="Bearer">
  <issuer-signing-keys>
    <key id="your-kid" n="{base64url-modulus}" e="{base64url-exponent}" />
  </issuer-signing-keys>
  <audiences>
    <audience>api://your-api-app-id</audience>
  </audiences>
  <issuers>
    <issuer>https://your-issuer</issuer>
  </issuers>
</validate-jwt>

Key points to ensure signature is actually validated:

Do not disable signing

Make sure require-signed-tokens is not set to false:

<validate-jwt header-name="Authorization" require-scheme="Bearer" require-signed-tokens="true">
  ...
</validate-jwt>

If require-signed-tokens is false, the token is accepted without signature validation, which matches the behavior described (changing key values has no effect).

Configure issuer-signing-keys correctly

Within issuer-signing-keys:

Use <key id="..." n="..." e="..." /> for an RSA public key.
n and e must be Base64url-encoded values of the modulus and exponent.
If id is set, it is matched to the token’s kid claim; if no kid matches, API Management will try all keys.

If the key element is misconfigured but require-signed-tokens is false, the token still passes. With require-signed-tokens="true", a mismatched n/e causes validation to fail.

Ensure other required elements are present

For full validation, configure:

<audiences>
  <audience>...</audience>
</audiences>
<issuers>
  <issuer>...</issuer>
</issuers>

and keep require-expiration-time at its default true unless there is a specific reason to allow tokens without exp.

Alternative: certificate-based public key

If the public key is available as a certificate uploaded to API Management, use certificate-id instead of n/e:

<issuer-signing-keys>
  <key certificate-id="your-cert-id" />
</issuer-signing-keys>

This also validates the signature using the public key from the certificate.

In summary, to ensure the JWT signature is actually validated when only a public key is available, configure validate-jwt with either openid-config or issuer-signing-keys (n/e or certificate-id) and keep require-signed-tokens="true". If changing modulus/exponent has no effect, the policy is likely not using those keys (for example, because require-signed-tokens is disabled or the token is not signed with an asymmetric algorithm supported by the policy).

References: