Non-OIDC JWT Connector

[john-delivuk]

Preflight Checklist

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

Problem Description

OIDC is becoming the preferred SSO protocol for most open source tooling. Today, my organization connects dex to apps like k8s dashboard, vault, argo, kafka-ui and we're happy with the result. We've now added Gravitational Teleport to the stack, and we were looking to leverage their JWT signing capabilities.

In a perfect world, Teleport could be our OIDC IDP, but they don't have that function. However they present a JWT to the application, which doesn't quite make the end meet to allow their app proxy to handle authentication.

Proposed Solution

A Dex connector that could sign OIDC tokens based on valid JWT's. Ideally some mapping from the JWT attributes to the OIDC scopes would be configured, as JWT is very loose in terms of specification. I imagine other JWT signing IDP's could take advantage of this connector as well.

Alternatives Considered

I may be lacking details around OIDC or JWT that would make this solution unnecessary. Happy to hear any feedback.

Additional Information

Teleport JWT / App Proxy

[chr-b]

I think I have a very similar use case:

• Cloudflare Access is in place, where users have to authenticate against the IdP configured in Cloudflare.
• If authentication is successful, Cloudflare will issue a JWT token and forward the request to the origin (e.g. DEX)
• DEX would then have to validate this JWT token and obtain user data from it

The JWT validation requires the following config data:

• Public key URL
• Expected value for JWT Issuer
• Expected value for JWT Audience claim
• Optional: URL for retrieving user group information

The JWT is included in a request as a cookie and header. There is also an additional header Cf-Access-Authenticated-User-Email with the user id.
The group information can only be obtained by calling a pre-defined URL with the JWT in a specific header.

[nabokihms]

Speaking about generic JWT connector implementation, there should be precisely two layers:

1. Validating the token.
   Btw, @chr-b mentioned all validation steps. The only thing is that the public key URL may be a static file with a key, e.g., file://local.json.

2. Extracting claims from the token.
   For claims extraction, I would like to propose using something like json-path, jq, or even cel. Maybe implementing connector middleware feature will help us with common connector behaviors.

Custom logic, e.g., receiving groups from endpoints and a userid from a header, should be implemented as an external connector.

And it would be better to write design documentation first.

[LarssonOliver]

Has there been any progress related to this issue?

I have the same use case as @john-delivuk and may be able to help out if needed.

[patresso-sb]

Bumping the interest in this feature

[asychev]

+1, integration with Cloudflare Zero Trust (Access) is very nice to have

[nabokihms]

There is the Token Exchange feature that can be used to exchange one JWT token for another. It only requires the OIDC discovery endpoint (with the valid JWKS uri).
https://dexidp.io/docs/token-exchange/

[ripta]

There is the Token Exchange feature that can be used to exchange one JWT token for another. It only requires the OIDC discovery endpoint (with the valid JWKS uri). https://dexidp.io/docs/token-exchange/

@nabokihms — Token Exchange seems like an interesting feature—and one I'm unfamiliar with. I don't think it fully solves the JWT case though; or at least not by itself, but please correct me if I'm wrong.

The Token Exchange docs describe performing an exchange—hitting dex's /token endpoint with a specific grant type—that the apps (Argo, Kafka-UI, etc.) wouldn't already know how to do. It seems to leverage token exchange, we'd need to write and/or run an additional component (maybe one already exists that you can recommend?)

Thanks!