Feature Request: Programmatic Token Exchange for OAuth Providers

[MP-Tool]

Summary

Add a programmatic auth endpoint that exchanges a token already issued by one of Komodo's configured identity providers (OIDC, Google, GitHub) for a Komodo JWT, without requiring a browser-based login flow.

The request follows the spirit of RFC 8693 — OAuth 2.0 Token Exchange: the supplied provider token serves as the subject_token, the returned Komodo JWT as the issued token.

Problem

Komodo issues its own JWTs (signed with jwt_secret) and supports OIDC, Google, and GitHub as identity providers. Today, the only supported way to obtain a Komodo JWT through any of these providers is the browser-based login flow:

Browser → Provider login → Komodo callback → session cookie → ExchangeForJwt → Komodo JWT

For non-browser clients, the supported authentication methods are local-user login (LoginLocalUser) and user-bound API keys/secrets. Both are independent of any configuredOIDC provider — they cannot be derived from, refreshed by, or tied to the lifecycle of an OIDC ID Token.

This means there is no supported way to convert a token already issued to a client by one of Komodo's configured providers into a Komodo JWT outside of a browser context.

Proposal

Add an auth request that accepts a token already issued to the client by one of Komodo's configured providers and returns a Komodo JWT for the corresponding user. The provider is supplied as a discriminator so the server can apply the correct validation strategy.

POST /auth
{
  "type": "ExchangeProviderTokenForJwt",
  "params": {
    "provider": "oidc" | "google" | "github",
    "token": "<provider_token>"
  }
}

→ { "user_id": "...", "jwt": "<komodo_jwt>" }

The response shape matches the existing JwtResponse type used by ExchangeForJwt.

Token type per provider

The providers Komodo supports do not all expose the same artefact for identity verification. The endpoint accepts the artefact each provider actually issues for that purpose:

Provider	Token supplied in token	Validation method
oidc	OIDC ID Token (signed JWT)	JWT signature against the issuer's JWKS + standard claim checks
google	Google ID Token (signed JWT, OIDC-compliant)	JWT signature against Google's JWKS + standard claim checks
github	GitHub OAuth Access Token	Server-side call to GitHub's user API; identity is the user GitHub returns

GitHub does not issue ID Tokens for user login — the OAuth Access Token is the only artefact a GitHub-authenticated client holds that can identify the user. Validation is therefore delegated to GitHub: the server calls GitHub's user endpoint with the supplied token and uses the response as the trusted identity source, mirroring what the existing browser callback already does after the OAuth code exchange.

Required behavior

Common to all providers

• The user is resolved by the provider's stable user identifier (sub for OIDC/Google, numeric user ID for GitHub) using the same lookup logic as the existing browser callback for that provider.
• A Komodo JWT is signed and returned. TTL and signing key follow the existing jwt_ttl / jwt_secret configuration.
• If the requested provider is not configured on the server, the endpoint returns a clear error indicating that token exchange is unavailable for that provider.
• The endpoint is subject to the existing failure rate-limiting that protects other auth endpoints.

For oidc and google (ID Token validation)

• Signature verified against the configured issuer's JWKS (with the existing key cache and rotation handling).
• iss matches the configured issuer for the provider.
• aud contains Komodo's configured client_id for the provider. Tokens issued to a different audience are rejected (defense against confused-deputy / token-redirect attacks).
• exp, nbf, iat within an acceptable clock-skew window.
• Algorithm pinned to the JWKS-advertised key types; alg: none and unexpected algorithms are rejected.

For github (Access Token validation)

• The server calls GitHub's user API with the supplied token over TLS and uses the returned identity. Tokens that GitHub rejects (401/403, revoked, expired) are rejected by Komodo with a clear error.
• The server does not log the supplied access token and does not retain it beyond the duration of the user lookup.
• GitHub-side rate limits are surfaced as a transient error rather than misclassified as an auth failure.

Out of scope

• New configuration parameters. The endpoint reuses each provider's existing configuration.
• Changes to the JWT format or lifetime semantics.
• Acceptance of OAuth Refresh Tokens or Authorization Codes. These have different lifecycles and intended recipients and are not interchangeable with the artefacts listed above.
• For OIDC/Google: acceptance of OAuth Access Tokens. Their aud typically targets a resource API rather than Komodo, so they are not safe to consume here.
• Validation of an OIDC nonce claim. nonce is bound to the Authorization Code Flow on the client side and is not meaningful for a server-to-server token exchange.

Effect on the existing auth surface

Method	Browser required	Identity source	Token returned
LoginLocalUser	no	Komodo-local user	Komodo JWT
API key / secret	no	Komodo user (long-lived credential)	per-request key/secret
OIDC / Google / GitHub + ExchangeForJwt	yes	external provider	Komodo JWT
ExchangeProviderTokenForJwt (this request)	no	external provider	Komodo JWT

The new request adds a programmatic path whose identity source is one of the configured providers, which are currently only reachable via the browser callback.

[mbecker20]

Interesting proposal, thanks