Microsoft Entra Workload ID and On-Behalf-Of tokens

eirikm 20 Reputation points
2024-06-18T08:22:11.4466667+00:00

My team is using Microsoft Entra Workload ID in a Kubernetes cluster for both accessing Azure resources and communicating with our other services (m2m, API calls). Our apps are Web APIs implemented using ASP.NET Core 8.0 and WorkloadIdentityCredential through DefaultAzureCredentials from the Azure.Identity package. This works well without the need for Client Secrets.

We have a use case were we want an App/API to call a downstream API on-behalf-of an authenticated human user. I've done this before we transitioned from ClientId + ClientSecret to Workload Identity using the apps Client Credentials. However, in our current setup with Workload Identity we do no longer have any Client Secret, and we don't want any Client Secrets. How can we implement On-Behalf-Of using Workload Identity (or any of the other credential types other than Client Credentials)? Is it even supported?

ASP.NET Core
ASP.NET Core
A set of technologies in the .NET Framework for building web applications and XML web services.
4,345 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,357 questions
0 comments
Accepted answer
  1. Akshay-MSFT 17,641 Reputation points Microsoft Employee
    2024-06-19T10:53:31.99+00:00

    @eirikm

    In your current architecture, the AKS cluster acts as the token issuer. Microsoft Entra ID uses OpenID Connect to discover public signing keys and verify the authenticity of the service account token before exchanging it for a Microsoft Entra token. Your workload can exchange a service account token projected to its volume for a Microsoft Entra token using the Azure Identity client library or the Microsoft Authentication Library (MSAL).

    Diagram of the AKS workload identity security model.

    AKS with workload.png

    There are only 2 ways to request access token via OBO:

    First case: Access token request with a shared secret which requires both client ID and client secret.

    OR

    Second case: Access token request with a certificate which requires client ID and client_assertion

    My recommendation here would be to share this as a feature request on our feedback portal.

    If you don't have any further queries and the suggestion above answers your ask, please "Accept the answer", This will help us and others in the community as well.

    Thanks,

    Akshay Kaushik

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Fabio Andrade 725 Reputation points Microsoft Employee
    2024-06-18T22:36:19.9966667+00:00

    Hi @eirikm

    Thanks for reaching out to Microsoft Q&A

    When your API needs to access another API, it becomes a confidential client application. That's why extra registration information is required: the app needs to share secrets (client credentials) with the Microsoft identity platform.

    I totally understand that you don't want to use client secrets, but you could use a client certificate instead. The documentation below has more details about how to configure it and there are also sample codes to acquire a token and call the Web APIs

    https://video2.skills-academy.com/en-us/entra/identity-platform/scenario-web-api-call-api-app-registration

    Thanks,

    Fabio