Documentation about configuration of Dex connectors

When a user logs in through Dex, the user’s identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. The client only needs to understand OpenID Connect to query Dex, while Dex implements an array of protocols for querying other user-management systems.

A “connector” is a strategy used by Dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.

Depending on the connectors limitations in protocols can prevent Dex from issuing refresh tokens or returning group membership claims. For example, because SAML doesn’t provide a non-interactive way to refresh assertions, if a user logs in through the SAML connector Dex won’t issue a refresh token to its client. Refresh token support is required for clients that require offline access, such as kubectl.

Dex implements the following connectors:

Namesupports refresh tokenssupports groups claimsupports preferred_username claimstatusnotes
SAML 2.0noyesnostable
OpenID ConnectyesyesyesbetaIncludes Salesforce, Azure, etc.
OAuth 2.0noyesyesalpha
AuthProxynononoalphaAuthentication proxies such as Apache2 mod_auth, etc.
Bitbucket Cloudyesyesnoalpha
Atlassian Crowdyesyesyes *betapreferred_username claim must be configured through config
OpenStack Keystoneyesyesnoalpha

Stable, beta, and alpha are defined as:

  • Stable: well tested, in active use, and will not change in backward incompatible ways.
  • Beta: tested and unlikely to change in backward incompatible ways.
  • Alpha: may be untested by core maintainers and is subject to change in backward incompatible ways.

All changes or deprecations of connector features will be announced in the release notes.