How to add client authentication with workload identity federation without a configured secret?

[jesperkristensen]

Which version of Duende IdentityServer are you using?

Which version of .NET are you using?
.NET 8

Additional context

I am investigating if it is possible for clients to authenticate to IdentityServer without manually managing client secrets or keys. I am running my client applications in Kubernetes on-premises. I am thinking something similar to how Azure Entra ID (https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust) and Google cloud support Workload Identity Federation, where I can configure the Kubernetes discovery endpoint URL https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery and a valid subject and audience for the client. Is this possible with Duende IdentityServer?

[narbit]

@AndersAbel, do you have any recommendation or thoughts on how this could be implemented in Duende? Should this be based on a custom token-exchange extension grant where client doesn't have a secret assigned OR is it a client_credentials token request that authenticates client with"client_assertion": id_token, "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" ?

[josephdecock]

My initial reaction is that you can achieve client authentication without needing a shared secret by using the private key jwt client authentication mechanism. Basically the clients have a public private key pair that they use to sign requests, and IdentityServer is configured with the public key only to verify the signature. We have more docs here on that: https://docs.duendesoftware.com/identityserver/v7/tokens/authentication/jwt/. I'm not sure if this is exactly what you're looking for, but it would mean that you didn't have to have a shared secret between the services.

[narbit]

@josephdecock , a key pair is still just another type of secret. This is a bit different since WLI federation assumes no secrets at all. The links @jesperkristensen posted explain the approach. Here is an additional reference with a nice diagram demonstrating it from the Azure side of things - https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation. GCP has similar docs.

The approach assumes there's a preconfigured trust in IDP that maps an IDP "service account" (client/executor) to a subject and issuer from the external entity so it can act "on-behalf-of" that external entity, i.e. get tokens and allow the external entity call IDP protected resources with a swapped token. This way secrets are not needed, the external entity token is validated against pre-configured trust values.

I'm thinking Duende token exchange w/out secret and with trust (mapped subject, issuer) configured via client's properties could accomplish this. Still deciding on the best approach though.

[RolandGuijt]

@narbit Checking to see if you are still waiting for a reaction or can we close the issue?

[narbit]

@RolandGuijt , it'd be nice to get your guys' opinion on potential options for workload identity implementation in Duende. Right now I'm using a token exchange approach combined with Client Properties to configure federated credentials. Would love to know if this is something that could be supported out of the box at some point but this can be closed for now. Thank you!