Authentication Through an OpenID Connect Provider

Overview

Dex is able to use another OpenID Connect provider as an authentication source. When logging in, dex will redirect to the upstream provider and perform the necessary OAuth2 flows to determine the end users email, username, etc. More details on the OpenID Connect protocol can be found in An overview of OpenID Connect .

Prominent examples of OpenID Connect providers include Google Accounts, Salesforce, and Azure AD v2 ( not v1).

Caveats

When using refresh tokens, changes to the upstream claims aren’t propagated to the id_token returned by dex. If a user’s email changes, the “email” claim returned by dex won’t change unless the user logs in again. Progress for this is tracked in issue #863.

Configuration

  1. connectors:
  2. - type: oidc
  3.   id: google
  4.   name: Google
  5.   config:
  6.     # Canonical URL of the provider, also used for configuration discovery.
  7.     # This value MUST match the value returned in the provider config discovery.
  8.     #
  9.     # See: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
  10.     issuer: https://accounts.google.com
  12.     # Connector config values starting with a "$" will read from the environment.
  13.     clientID: $GOOGLE_CLIENT_ID
  14.     clientSecret: $GOOGLE_CLIENT_SECRET
  16.     # Dex's issuer URL + "/callback"
  17.     redirectURI: http://127.0.0.1:5556/callback
  20.     # Some providers require passing client_secret via POST parameters instead
  21.     # of basic auth, despite the OAuth2 RFC discouraging it. Many of these
  22.     # cases are caught internally, but some may need to uncomment the
  23.     # following field.
  24.     #
  25.     # basicAuthUnsupported: true
  27.     # Google supports whitelisting allowed domains when using G Suite
  28.     # (Google Apps). The following field can be set to a list of domains
  29.     # that can log in:
  30.     #
  31.     # hostedDomains:
  32.     #  - example.com
  34.     # List of additional scopes to request in token response
  35.     # Default is profile and email
  36.     # Full list at https://dexidp.io/docs/custom-scopes-claims-clients/
  37.     # scopes:
  38.     #  - profile
  39.     #  - email
  40.     #  - groups
  42.     # Some providers return claims without "email_verified", when they had no usage of emails verification in enrollment process
  43.     # or if they are acting as a proxy for another IDP etc AWS Cognito with an upstream SAML IDP
  44.     # This can be overridden with the below option
  45.     # insecureSkipEmailVerified: true 
  47.     # Groups claims (like the rest of oidc claims through dex) only refresh when the id token is refreshed
  48.     # meaning the regular refresh flow doesn't update the groups claim. As such by default the oidc connector
  49.     # doesn't allow groups claims. If you are okay with having potentially stale group claims you can use
  50.     # this option to enable groups claims through the oidc connector on a per-connector basis.
  51.     # This can be overridden with the below option
  52.     # insecureEnableGroups: true
  54.     # When enabled, the OpenID Connector will query the UserInfo endpoint for additional claims. UserInfo claims
  55.     # take priority over claims returned by the IDToken. This option should be used when the IDToken doesn't contain
  56.     # all the claims requested.
  57.     # https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
  58.     # getUserInfo: true
  60.     # The set claim is used as user id.
  61.     # Claims list at https://openid.net/specs/openid-connect-core-1_0.html#Claims
  62.     # Default: sub
  63.     # userIDKey: nickname
  65.     # The set claim is used as user name.
  66.     # Default: name
  67.     # userNameKey: nickname
  69.     # For offline_access, the prompt parameter is set by default to "prompt=consent". 
  70.     # However this is not supported by all OIDC providers, some of them support different
  71.     # value for prompt, like "prompt=login" or "prompt=none"
  72.     # promptType: consent
  74.     # Some providers return non-standard claims (eg. mail).
  75.     # Use claimMapping to map those claims to standard claims:
  76.     # https://openid.net/specs/openid-connect-core-1_0.html#Claims
  77.     # claimMapping can only map a non-standard claim to a standard one if it's not returned in the id_token.
  78.     claimMapping:
  79.       # The set claim is used as preferred username.
  80.       # Default: preferred_username
  81.       # preferred_username: other_user_name
  83.       # The set claim is used as email.
  84.       # Default: email
  85.       # email: mail
  87.       # The set claim is used as groups.
  88.       # Default: groups
  89.       # groups: "cognito:groups"