Connecting identity platforms securely and seamlessly is critical for modern cloud applications. When integrating Microsoft Entra External ID (EEID) with Entra ID as an external identity provider, ensuring robust authentication between the parties is paramount. Traditional client_secret authentication introduces risks by sharing static secrets vulnerable to leakage or misuse.

This post explores using the private_key_jwt client authentication method, a recommended approach defined in the OpenID Connect specification, to connect EEID and Entra ID. Unlike client_secret, private_key_jwt leverages cryptographic keys and signed JSON Web Tokens (JWTs) for stronger, certificate-based authentication.

We'll dive into how EEID authenticates to Entra ID’s token endpoint using signed JWTs derived from public/private key pairs and the role of JWKS metadata. Then we’ll cover the necessary EEID and Entra ID configurations to establish this trust relationship. Finally, we walk through testing steps and highlight key practical insights and caveats from Rory Braybrook’s detailed Medium walkthrough.

Whether you manage Azure AD or external identity federation scenarios, this guide will deepen your understanding of secure OIDC client authentication using private_key_jwt between Entra platforms.

Architecture Overview

┌────────────────────────────────────────────┐
│Architecture                                │
├────────────────────────────────────────────┤
│• Enterprise data sources                   │
│• Foundry platform                          │
│• AI applications                           │
└────────────────────────────────────────────┘

Key Technical Observations

• private_key_jwt as a Secure Client Auth Method — EEID authenticates without exposing a static client_secret by signing JWTs with its private key, aligning with best practices in the OpenID Connect 1.0 spec.

• JWT Claims and Signature Verification — EEID’s JWT includes precise claims—iss, sub, aud, jti, exp, and iat—ensuring contextual identity and nonce to prevent replay attacks. Entra ID rigorously validates all these claims and signature correctness.

• JWKS Endpoint for Key Discovery — EEID exposes a JWKS URI containing multiple public keys. Entra ID consumes these to verify JWT signatures. Uploading all keys into Entra ID app registration allows for key rotation and multiple keys without immediate configuration changes.

• Client ID Consistency in Claims — iss and sub claims both use EEID application’s client_id, enforcing clear identity in the JWT and simplifying validation logic on Entra ID.

• Operational Limitations on Key “kid” Discovery — The exact “kid” used in authentication JWTs is unknown to the external operator because EEID and Entra ID communicate internally. This necessitates uploading all possible keys to Entra ID to avoid signature validation errors.

• Token Expiration and Replay Protections — JWTs are short-lived (60–300 seconds) and include unique JWT IDs to prevent replay, bolstering security in token exchanges.

How It Works

1. EEID Creates the Signed Client Assertion JWT

EEID generates a signed JWT for client authentication when requesting tokens from Entra ID's token endpoint. The JWT payload contains these claims:

{
  "iss": "",
  "sub": "",
  "aud": "https://login.microsoftonline.com/<tenant-id>/oauth2/token",
  "jti": "<unique-jwt-id>",
  "exp": "<expiry-timestamp>",
  "iat": "<issued-at-timestamp>"
}

This JWT is signed by EEID’s private key corresponding to one of the public keys registered with Entra ID, using the kid header to indicate the key ID.

2. EEID Posts the JWT for Client Authentication

Instead of sending a client_secret, EEID posts this signed JWT (called a client assertion) to Entra ID’s token endpoint as per OIDC’s private_key_jwt protocol:

POST /<tenant-id>/oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=<signed-jwt>&
grant_type=client_credentials

3. Entra ID Validates the Client Assertion JWT

Upon receiving the assertion, Entra ID:

• Looks up the EEID public keys registered via JWKS endpoint or manual upload
• Uses the kid header to select the correct public key for signature verification
• Validates the JWT signature correctness
• Confirms all claims (iss, sub, aud, jti, exp, iat) are valid and the JWT has not been replayed
• If any checks fail, it returns a signature validation error (e.g., error code 700027)

4. Token Issuance and Authentication Flow Continuation

Once validated, Entra ID issues an access token or ID token depending on the request. This token enables downstream authentication flows such as user sign-in federation via custom OIDC identity providers configured in Entra ID user flows.

5. EEID and Entra ID Configuration

• EEID exposes the JWKS endpoint containing six certificates. Operators must extract all six certificates, convert them to .cer files with PEM headers, then upload them all into Entra ID app registrations to handle key rotation and signature verification.

• The custom OIDC provider in Entra ID utilizes the private_key_jwt authentication method and correctly references EEID’s tenant ID (not tenant name) for issuer and well-known endpoints.

• Testing involves running the EEID user flow and verifying federation sign-in completes successfully, producing valid JWTs seen in user logs within Entra ID.

Quick Tips & Tricks

1. Use private_key_jwt Instead of client_secret for Stronger Security — Avoid shared secrets that can leak; signing JWTs with private keys reduces attack surface.

2. Upload All Public Keys from JWKS to Entra ID App Registration — Since you cannot predict which kid EEID will use, upload every key to prevent signature validation failures.

3. Extract and Save Certificates with Proper PEM Formatting — Wrap each base64 x5c key in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines before uploading.

4. Check Entra ID Sign-in Logs for Failure Diagnostics — Look under interactive and non-interactive user flow logs for client assertion errors like 700027 to verify JWT validation issues.

5. Short JWT Expiry Times Mitigate Replay Risk — Keep JWT validity to a few minutes (60-300s) and enforce unique jti claims for each request.

6. Plan for Key Rotation Despite Multi-Year Certificates — EEID keys may be valid for years, but prepare an update process to re-upload new keys when they eventually expire.

Conclusion

This walkthrough of connecting Entra External ID to Entra ID as an external OIDC provider highlights the benefits of using the private_key_jwt client authentication method over traditional client secrets. By leveraging signed JWT assertions backed by public/private keys, the integration ensures significantly enhanced security and aligns with OpenID Connect best practices.

The process involves configuring EEID to generate signed JWTs with precise claims, registering EEID public keys with Entra ID, and setting up custom OIDC identity providers referencing this mechanism. While the need to upload and maintain multiple keys poses some operational overhead, the long-validity certificates ease rotation concerns.

As enterprises increasingly federate identities across clouds and platforms, techniques like private_key_jwt authentication will form cornerstone best practices for secure, scalable, and manageable identity interoperability in Microsoft’s Entra ecosystem and beyond.

References

1. Connecting Entra External ID (EEID) to Entra ID as an external provider via OIDC, using private_key_jwt - Rory Braybrook (Medium)
2. OpenID Connect Core 1.0 - Client Authentication — Specification describing private_key_jwt method
3. Entra External ID Tag on Medium — Related articles and tutorials on Entra External ID
4. private_key_jwt Tag on Medium — Additional posts discussing private_key_jwt usage
5. OIDC Tag on Medium — OpenID Connect articles covering federation and authentication
6. Federation Tag on Medium — Insights on identity federation with Microsoft Entra

Image credit: Rory Braybrook, The new control plane

Source: The new control plane, Medium