Problem
lakeFS supports several authentication integrations (OIDC via the deprecated
web flow, AWS IAM via ExternalPrincipalLogin, STS via a remote authenticator)
but has no vendor-agnostic way to accept a JWT that a client already holds
from its own identity provider. The AWS IAM integration in particular is
heavy to adopt outside AWS-native workloads, and leaves non-AWS IdPs without
a first-class path.
Proposal
Add a token-exchange endpoint that accepts a JWT issued by any external IdP
and returns a lakeFS AuthenticationToken. lakeFS verifies the JWT's
signature against a configured JWKS (asymmetric algorithms only), validates
iss / aud / exp / iat / nbf, and maps its claims onto a lakeFS
user, auto-provisioning on first login.
Prior art:
This pattern is vendor-agnostic: it works with AWS Outbound Identity
Federation, Okta, Keycloak, Microsoft Entra ID, or anything else that
publishes a JWKS endpoint.
Problem
lakeFS supports several authentication integrations (OIDC via the deprecated
web flow, AWS IAM via ExternalPrincipalLogin, STS via a remote authenticator)
but has no vendor-agnostic way to accept a JWT that a client already holds
from its own identity provider. The AWS IAM integration in particular is
heavy to adopt outside AWS-native workloads, and leaves non-AWS IdPs without
a first-class path.
Proposal
Add a token-exchange endpoint that accepts a JWT issued by any external IdP
and returns a lakeFS
AuthenticationToken. lakeFS verifies the JWT'ssignature against a configured JWKS (asymmetric algorithms only), validates
iss/aud/exp/iat/nbf, and maps its claims onto a lakeFSuser, auto-provisioning on first login.
Prior art:
This pattern is vendor-agnostic: it works with AWS Outbound Identity
Federation, Okta, Keycloak, Microsoft Entra ID, or anything else that
publishes a JWKS endpoint.