After #499 - we no longer have generic IDToken to session extraction for bearer auth -- but we use the provider now.

This makes sense for the first JWTBearerVerifier in the OIDC provider case, the first Verifier in that list is made from the configured provider details.

But for subsequent JWTBearerVerifiers, it seems inappropriate. They are potentially a completely different Issuer/Audience -- where using the configured provider's CreateSessionStateFromBearerToken is mismatched. ie the Provider's findClaimsFromIDToken potentially doing profileURL operations are out of place.

Expected Behavior

Creating Sessions from a bearer IDToken should be more generic in mapping claims to the session rather than relying on the main provider's method.

More complex implementation path: The first JWTBearerVerifier based on the standard OIDC provider details can build a session from the OIDC provider method -- but any subsequent ExtraJwtIssuers should not use the provider session creator.

Possible Solution

For ExtraJwtIssuers -- beyond the first Verifier that might be appropriate to match with the configured provider, do more generic and simple Claims -> Session mapping

MAYBE without even the email = user if email == "" logic that used to exist that forced an email to be on the session if an email claim was missing (and just set to "" like preferredUsername). For security reasons, still validate via the email-domains validator, but assume if a user is aware they will get claims without email they set the email-domains to *

Context

We are trying to intermix OneLogin OIDC for human -> service auth with kubernetes projected service account tokens for service -> service machine auth with Oauth2-proxy as the single gateway.

Human OIDC tokens will have the rich, normal claims. K8s tokens are barebones & have a sub (the k8s service account).

We can get this to work with --user-id-claim=sub + --email-domains=* -- but then we lose a lot of context for our human OIDC IDTokens where we want the IDToken's email claim passed as a X-Forwarded-Email header.

Your Environment

Kubernetes with projected service account tokens enabled. Hacked service account public keys into a valid jwks.json and made a pseudo openid-configuration available for the k8s serrvice account IDTokens.

• Version used:

Currently works in 5.1 -- I have concerns latest PRs merged into master for 6.0 will break this.