Microsoft connector - support for using signed assertions from managed identity instead of client secrets #3852
Comments
ItalyPaleAle
added a commit
to ItalyPaleAle/dex
that referenced
this issue
Dec 5, 2024
Fixes dexidp#3852 Maintaining shared secrets in the application's configuration is not good, and should be avoided as possible. This includes the client secret used by the Microsoft connector to exchange authorization codes for access tokens using Entra ID (fka Azure AD). It is possible to avoid using secrets by leveraging a [signed assertion](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow#request-an-access-token-with-a-certificate-credential), which comes from managed identity (when the app is running on Azure) or [Workload Identity](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation) (when the app is running on a supported platform, including K8s anywhere). This is configured with a new configuration key `federatedIdentity` which can have 3 values (all case-insensitive): - `ManagedIdentity` -> Uses a system-assigned managed identity - `ManagedIdentity=00000000-0000-0000-0000-000000000000` -> Uses a user-assigned managed identity, where the value is the client ID of the MI - `WorkloadIdentity` -> uses Workload Identity Signed-off-by: ItalyPaleAle <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Preflight Checklist
Problem Description
Using Dex with the Microsoft connector with an Entra ID (Azure AD) app requires setting a client secret in the configuration. Applications are generally discouraged to work with pre-shared keys (like client secrets) whenever possible, as they can pose a security risk.
Apps that are running in Azure, or in environments that can be federated with Entra (e.g. Workload Identity Federation, that works on Kubernetes clusters hosted anywhere, as well as a bunch of other places including Google Cloud, AWS, etc), can leverage managed identity / workload identity to perform a token exchange instead of requiring pre-shared credentials.
Proposed Solution
Support for obtaining a token from Entra ID using signed assertions.
When invoking the
/tokenendpoint to exchange an authorization code for an access token, it should be possible to use a signed assertion instead of a client secret. The assertion can come from a certificate, or can come from a token issued by Managed Identity / Workload Identity.Alternatives Considered
No response
Additional Information
This feature request would greatly improve the security of environments that use Dex, as they would be able to run without any pre-shared credentials, which are susceptible to being leaked.
The text was updated successfully, but these errors were encountered: