Enable the use of Azure Workload Identities with `.AddClient(options => { options.UseWebProviders().AddMicrosoft...})` about openiddict-core HOT 3 OPEN

What is important is that the microsoft identity library is able to exchange that identity token for an access token against the Microsoft Entra application, thereby establishing authenticating client. Normally you would need a client secret to achieve that.

The thing is we can't - or more exactly don't want to 😄 - depend on the Azure (Identity) SDK, which is where all that sorcery is implemented, so it might not be straightforward to support.

Essentially, workload identities are nothing more than Azure-managed asymmetric keys that are used to generate client assertions - stored in a file referenced by the AZURE_FEDERATED_TOKEN_FILE environment variable - that will be used with the standard private_key_jwt client authentication method (see https://github.com/Azure/azure-sdk-for-net/blob/2869a4b020f8575fec4a6bfb362ba1496961fafe/sdk/identity/Azure.Identity/src/Credentials/WorkloadIdentityCredential.cs).

private_key_jwt client authentication is something the OpenIddict client itself already fully supports but it is not (yet) easily configurable via OpenIddictClientWebIntegrationBuilder.Microsoft, that only offers to register a client secret and not a RSA/ECDSA key or a X.509 certificate.

Exposing a new builder method to allow specifying a RSA/ECDSA signing key or a X.509 signing certificate should be easy, but anything more involved will require more work: not a strong "no", but if it's not sponsored work, we'll need a stronger demand to justify spending time on that 😃

from openiddict-core.

The only real motivation I can offer is that Workload Identities (as they are known on Azure and GCP) and IAM Roles for Service Accounts (as they are known on AWS, but which are basically the same thing) are by far the most secure way to do identity access management on Kubernetes-based workloads. The fact that we never need to generate, store, rotate or mount client secrets essentially eliminates all the external interaction points where those credentials can leak. You still have to keep the Pod itself and the Webhook that does the mutating locked down, but that is a much more manageable problem.

As to the magic that the identity sdk does, you are right that it is just working with client assertions. The Kubernetes cluster becomes a federated OIDC provider to an Azure AD Application, and the service account (identitfied as system:serviceaccount:<namespace>:<service-account>) is the identity about which the assertion is made. You are obviously much more versed in how this works, but I can imagine that you could piggy-back on a more generic private_key_jwt auth mechanism to make something like this work.

The webhook periodically refreshes the token at AZURE_FEDERATED_TOKEN_FILE, so as long as it is re-read with every authentication attempt you also don't need to worry about managing refreshes.

By the way here is an example of the token located at AZURE_FEDERATED_TOKEN_FILE

{
  "alg": "RS256",
  "kid": "asdfsa32344sadvcxbxbsdfg435r"
}
{
  "aud": [
    "api://AzureADTokenExchange"
  ],
  "exp": 1715103340,
  "iat": 1715016940,
  "iss": "https://xxx.oic.prod-aks.azure.com/xxxx-xxx-xxx-xxx-xxxxxx/xxx-xxx-xxx-xxx-xxx/",
  "kubernetes.io": {
    "namespace": "mynamespace",
    "pod": {
      "name": "mypod-86d45b9cd9-bglrc",
      "uid": "xxxx-xxx-yyy-yyyyy-yyyyyyy"
    },
    "serviceaccount": {
      "name": "openiddict-server",
      "uid": "yyyyyy-ccc-vvvv-yyyyy-xxxxxx"
    }
  },
  "nbf": 1715016940,
  "sub": "system:serviceaccount:mynamespace:openiddict-server"
}

from openiddict-core.

The only real motivation I can offer is that Workload Identities (as they are known on Azure and GCP) and IAM Roles for Service Accounts (as they are known on AWS, but which are basically the same thing) are by far the most secure way to do identity access management on Kubernetes-based workloads. The fact that we never need to generate, store, rotate or mount client secrets essentially eliminates all the external interaction points where those credentials can leak. You still have to keep the Pod itself and the Webhook that does the mutating locked down, but that is a much more manageable problem.

I'm not denying "managed identities" are a good thing from both a security and usability perspective, but they are proprietary/provider-specific (the client authentication method is standard, but how the token is exposed by the host and retrieved is 100% implementation-specific): Microsoft can afford implementing that in their Azure Identity library because they own the whole chain, but OpenIddict is not tied to Azure and is meant to be usable everywhere, so such an Azure-specific feature would objectively have a limited audience 😃

As I said, I'm not fundamentally opposed to supporting such features, but there must be a stronger demand for them (or a company willing to fund the work needed to implement that and maintain it long-term).

from openiddict-core.