Secret-less authentication with workload identity federation

[chandlerkent]

(Cross-posted from https://github.com/orgs/DuendeSoftware/discussions/617#discussioncomment-18290039 per request from @maartenba!)

We have extended Identity Server to support what we call a federated credential (seems the industry may now be standardizing on calling it "workload identity federation") which allows a secret-less authentication flow with Identity Server. We think the pattern is broadly applicable that we would love to see some version of this built-in to Identity Server so we can remove this customization.

The basic concept is you establish trust with another OIDC provider and then you can accept tokens from this provider and map them to 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. You add this secret to the Identity Server Client's ClientSecrets.
2. A FederatedOpenIDConnectClientAssertionSecretParser that implements ISecretParser which extracts the token from the incoming HTTP request (it is really an implementation of JwtBearerClientAssertionSecretParser and perhaps we could use the built-in instead of creating our own).
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.).

With this foundation in place, Identity Server can accept a token from another OIDC provider and exchange it for a token representing a Client in Identity Server. There's no shared secret or even public keys (in the case of private key JWT or mutual TLS) to configure. You can then allow your users to integrate with popular OIDC providers such as GitHub actions or your cloud Identity Provider without needing to set up or store any secrets.

For our use case, we use Azure and Azure Kubernetes Service, which allows us to get tokens from Identity Server without creating or managing 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 (managed identity or otherwise) 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 automatically creates and mounts the JWT for the Service Account on the pod
2. Azure.Identity .NET library automatically exchanges the Service Account JWT for the Entra ID JWT (due to trust established in step #3 above), via the (WorkloadIdentityCredential)[https://learn.microsoft.com/en-us/dotnet/api/azure.identity.workloadidentitycredential?view=azure-dotnet&preserve-view=true]
3. Our application code exchanges the Entra ID JWT for an Identity Server JWT. The request looks like:

   POST /connect/token
   
   grant_type=client_credentials&client_id=XXX&scope=YYY&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=<Entra ID token>

   Identity Server validates the incoming token, extracts the roles claim (which Entra ID adds), uses mapping logic to map the roles to an Identity Server Client, and then return a token.

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