Declare connectors as "hidden" or "backend-only"

[jeengbe]

Preflight Checklist

• [x] I agree to follow the Code of Conduct that this project adheres to.
• [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

In Dex, all configured connectors are currently shown on the login "select connector" screen, regardless of their intended usage. This becomes problematic when some connectors are only used for backend purposes, such as token exchange, and should not be visible to end users. Additionally, these backend-only connectors often do not require redirect URIs, yet Dex expects a full redirect flow for all connectors.

For example, the following additional Google connector is needed to exchange Google's identity/access tokens:

id: google-te
name: Google (Token Exchange)
type: oidc
config:
  issuer: https://accounts.google.com
  clientID: $GOOGLE_OAUTH_CLIENT_ID
  clientSecret: $GOOGLE_OAUTH_CLIENT_SECRET
  redirectURI: nil

Proposed Solution

Introduce a backendOnly: true flag (or similar) in the connector configuration. Connectors marked as backend-only would:

• Be hidden from the "select connector" login screen.
• Not require a specified redirect URI.
• Only be used in programmatic authentication flow.

This would allow administrators to cleanly separate internal token flow connectors from user-facing ones, improving UX and reducing confusion.

Alternatives Considered

• Specifying a connector_id in each client to skip the connector selection screen. While this avoids the UI screen, it doesn’t prevent backend-only connectors from appearing if no connector_id is specified.
• Maintaining separate Dex instances for backend vs. frontend use cases, which increases infrastructure complexity.

Additional Information

This feature would be especially useful in environments where Dex acts as a federation point between multiple identity systems.
I would be interested in implementing this.

[danxmoran]

This would be a big help for us as well!

@jeengbe are you still planning to work on this implementation?

[cardoe]

This is implemented in #3818 which I've pulled into my proposed v2.44.90 at ghcr.io/cardoe/dex:v2.44.90