EEID to Entra ID OIDC federation with private_key_jwt not client_secret

Question

EEID to Entra ID OIDC federation with private_key_jwt not client_secret

RoryB 705

You can now federate EEID with Entra ID via OIDC not via guest:

https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-entra-id-federation-customers

I have this working with client_secret, but cannot get it to work with the private_key_jwt option in the EEID custom OIDC provider.

I have retrieved the certificate from the EEID JWKS endpoint and uploaded it to the Entra ID app registration.

The error in the sign-in logs is:

Sign-in error code

700027

Failure reason

Client assertion failed signature validation.

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.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-08T00:23:15.03+00:00
Hello RoryB,

The error AADSTS700027: Client assertion failed signature validation usually indicates that the JWT signed by EEID does not match the certificate configured in the Microsoft Entra ID app registration.

Since client_secret authentication works, the federation setup itself appears correct. The issue is related specifically to private_key_jwt.

Please verify:

The correct public certificate from the EEID JWKS endpoint is uploaded in the Entra app registration.

The JWT kid/x5t matches the signing key exposed in the JWKS endpoint.

The assertion uses RS256.

The aud claim matches the token endpoint for which the assertion was created.

iss and sub are set to the application client_id.

You can decode the generated client assertion using:

jwt.ms

JWT.io

Reference:

Microsoft Entra External ID federation documentation
RoryB 705 Reputation points

2026-05-08T02:26:40.1166667+00:00

@Sridevi Machavarapu @Radwan Almsora

The problem is that the traffic between EEID and Entra ID is in the cloud.

I have no way of seeing the JWT, which rules out a lot of the suggestions.

The well-known endpoint and the issuer URI in the config. both use the tenant ID rather than the tenant name.

All the keys in the jwks endpoint have "use":"sig".

I used the first one - there are several.

How do you know which one of the keys Entra ID is using?

Is it worthwhile uploading all the possible certs?

Note: When I double-click the .cer file, it opens the certificate pop-up so the cert. seems correct.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-11T18:30:56.73+00:00

Hello RoryB,

Any update on this? Please confirm if you have further queries.
RoryB 705 Reputation points

2026-05-13T03:02:45.7266667+00:00

@Sridevi Machavarapu No - all good thanks.

Answer recommended by moderator

RoryB 705

In desperation, I uploaded every "sig" certificate in the JWKS endpoint, and it worked.

Surely, there must be an easier way?

0 comments

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.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-08T00:23:15.03+00:00

Hello RoryB,

The error AADSTS700027: Client assertion failed signature validation usually indicates that the JWT signed by EEID does not match the certificate configured in the Microsoft Entra ID app registration.

Since client_secret authentication works, the federation setup itself appears correct. The issue is related specifically to private_key_jwt.

Please verify:

The correct public certificate from the EEID JWKS endpoint is uploaded in the Entra app registration.

The JWT kid/x5t matches the signing key exposed in the JWKS endpoint.

The assertion uses RS256.

The aud claim matches the token endpoint for which the assertion was created.

iss and sub are set to the application client_id.

You can decode the generated client assertion using:

jwt.ms

JWT.io

Reference:

Microsoft Entra External ID federation documentation
RoryB 705 Reputation points

2026-05-08T02:26:40.1166667+00:00

@Sridevi Machavarapu @Radwan Almsora

The problem is that the traffic between EEID and Entra ID is in the cloud.

I have no way of seeing the JWT, which rules out a lot of the suggestions.

The well-known endpoint and the issuer URI in the config. both use the tenant ID rather than the tenant name.

All the keys in the jwks endpoint have "use":"sig".

I used the first one - there are several.

How do you know which one of the keys Entra ID is using?

Is it worthwhile uploading all the possible certs?

Note: When I double-click the .cer file, it opens the certificate pop-up so the cert. seems correct.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-11T18:30:56.73+00:00

Hello RoryB,

Any update on this? Please confirm if you have further queries.
RoryB 705 Reputation points

2026-05-13T03:02:45.7266667+00:00

@Sridevi Machavarapu No - all good thanks.

Answer 1

Hello RoryB,

At the moment, there does not appear to be a documented way to determine beforehand which signing key EEID will use for private_key_jwt. Since the JWT generation and exchange happen entirely cloud-side, you do not get visibility into the JWT header or selected kid.

If uploading all certificates with "use":"sig" resolved the issue, that indicates EEID was signing with a different key than the first certificate uploaded.

In practice, uploading all active signing certificates from the JWKS endpoint is currently the safest and most reliable approach, especially when multiple signing keys or key rotation are involved.