https://duendesoftware.com/blog/20260903-client-secrets-mutual-tls-and-private-key-jwt

[giscus[bot]]

https://duendesoftware.com/blog/20260903-client-secrets-mutual-tls-and-private-key-jwt

Compare three OAuth client authentication methods in ASP.NET Core: Client Secrets, Private Key JWT, and Mutual TLS, with code examples for Duende IdentityServer.

https://duendesoftware.com/blog/20260903-client-secrets-mutual-tls-and-private-key-jwt

[chandlerkent]

We have extended Identity Server to support what we call a federated credential (seems the industry may now be standardizing on workload identity or workload identity federation). The pattern is broadly applicable that we would love to see some version of this in Identity Server so we can remove this customization. Would love some feedback on this.

The basic concept is you establish trust with another OIDC provider and then you can accept tokens from this provider and map them to a an Identity Server client. To implement this in Identity Server, there are 3 components involved:

1. A FederatedOpenIDConnectCredential that is a sub-class of Secret which accepts an issuer, audience, and a way to extract claims from the credential to map to an Identity Server client.
2. A FederatedOpenIDConnectClientAssertionSecretParser that implements ISecretParser which extracts the token from the request (it is really an implementation of JwtBearerClientAssertionSecretParser and perhaps we don't need this)
3. A FederatedOpenIDConnectCredentialValidator that implements ISecretValidator which maps the incoming token to a FederatedOpenIDConnectCredential and then validates it using standard JWT validation (validate issuer, audience, expiration, etc.)

We are in Azure, so for us this means we have establish a trust relationship with Entra ID. In Entra ID there's an App Registration which has App Roles. Each App Role represents an Identity Server client. We use Entra ID functionality to protect which Entra identities are allowed to access the App Registration and which App Role they can access. Our applications then use standard libraries (Azure.Identity in .NET) to request an Entra ID token and then exchange it for a token from Identity Server. This means we have no secrets in Identity Server or even no public keys to manage. And even better, we can rely on Entra ID's support for secret-less authentication and use their federated credential support (Managed Identities, etc.) and the whole flow works without any secrets.

Here's the real world workflow we use. First the setup:

1. We run our workloads in Kubernetes (Azure Kubernetes Service)
2. We give each workload a Service Account
3. We create an Entra ID federated credential on our Entra identity to trust the Service Account's token
4. We create an App Registration to represent our instance of Identity Server
5. We create App Roles to map to Identity Server clients
6. We assign Entra identities to access the App Registration and give them an App Role

With this setup, we get a full end-to-end flow where our workloads can get a token from Identity Server without secrets:

1. Kubernetes mounts the JWT for the Service Account on the pod
2. Azure.Identity library automatically exchanges the Service Account JWT for the Entra ID JWT (due to trust established in step #3 above)
3. Our application code exhcnages the Entra ID JWT for an Identity Server JWT

I believe what I described works in any of the major clouds and should be applicable more broadly than Azure.

[maartenba]

That's pretty cool! I think this deserves a re-post on our show and tell, or under feature requests if this is indeed one.

[chandlerkent]

Posted to show and tell:

#619

Our feature request would be similar to this, so I didn't create a new one:

#175