[Design Discussion] Centralized Authentication with Distributed Enforcement

[RushanNanayakkara]

Related Feature Issue

#2257

Problem Summary

Thunder is self-contained — the same instance authenticates users and serves APIs. This prevents centralized identity across multiple instances (multi-tenant SaaS, CP/DP architectures). Resource servers also need to restrict access based on token claims (e.g., ouId).

High-Level Approach

Resource server validates JWTs from an external auth server via its JWKS endpoint. No shared secrets or databases.

• Phase 1 — JWKS signature verification + issuer/audience validation
• Phase 2 — Configurable required claims (e.g., ouId must match a value)

Frontend separates auth server config from resource server config. SDK authenticates against auth server, API calls go to resource server.

Architecture Overview

Console → Auth Server: OAuth authorize (resource=RS)
Console ← Auth Server: JWT (iss=AS, aud=RS)
Console → Resource Server: API + Bearer token
Resource Server → Auth Server: JWKS fetch (cached 5min)
Resource Server: verify signature + claims + required_claims

Two backend validation entry points:

• jwtAuthenticator.verifyFederatedToken — HTTP middleware for all API requests
• tokenValidator.ValidateSubjectToken — OAuth token exchange (RFC 8693)

Both fall back to JWKS verification when local key verification fails, then enforce required claims.

Security Considerations

• Audience binding via RFC 8707 resource parameter
• TLS enforced on JWKS fetch
• Kill switch: enabled: false revokes trust immediately

Impacted Areas

• Backend: config, JWT authenticator, JWT service (JWKS cache), token validator
• Frontend: config types/context/provider, console withConfig HOC
• Helm: conditional trusted_issuer in backend + frontend templates

No existing APIs or schemas modified. Additive and config-gated.

Alternatives Considered

Federated login via resource server — user authenticates at the resource server, which federates to the auth server and exchanges the token locally. Rejected because the goal is to directly trust auth server tokens on the resource server, not to exchange them for locally-issued tokens. JWKS validation is simpler and avoids the token exchange overhead.

Questions for Community Input

1. Should we support multiple trusted issuers (e.g., trust several auth servers simultaneously)?
2. Is required claims validation (static claim/value matching) sufficient, or do we need pattern-based matching (regex, list-of-values)?
3. Any interest in app-native authentication (embedded login form on the resource server, proxied to the auth server) to avoid exposing the auth server URL?

[senthalan]

Do we need to have the client_id enforcement?

My idea is we don't need it. Because we will have cased where the different clients are allowed to access the Thunder. So having only the Issuer + JWKS signature + audience verification should be enough.

Regarding your questions

1. Should we support multiple trusted issuers (e.g., trust several auth servers simultaneously)? - I think we don't need it
2. Is required claims validation (static claim/value matching) sufficient, or do we need pattern-based matching (regex, list-of-values)? - static claim/value matching should be sufficient
3. Any interest in app-native authentication - If we go ahead with the app-native authentication, then we can't use the oauth protocol. It's better to keep the console to IDP authentication logic in standard protocol

[RushanNanayakkara]

My idea is we don't need it. Because we will have cased where the different clients are allowed to access the Thunder. So having only the Issuer + JWKS signature + audience verification should be enough.

Agree. Updated and removed client ID.

Additionally if there is a use case to validate client Id this can be done via the custom claim validation as well.

[thiva-k]

Hi @RushanNanayakkara,

If we are going to bring the external issuer support for management APIs with this effort, I believe that we can also align this to fully support this for OAuth token exchange as well, which is also one of our pending requirements for agent ID use cases.

From the OAuth token exchange perspective:

1. client_id validation will be redundant since the OAuth client authentication will be done anyways.
2. Hope this required claims validations(ou) is optional, since these I don't think this will be needed for token exchange.
3. We may need support for multiple trusted issuers for certain use cases(e.g. a user/subject token obtained via federated IdP like Google, GitHub may be need to exchanged by an app/agent/resource server for an OBO access token)

Also note that the resource parameter support is not implemented yet end to end in Thunder and we do not have restrictions/ceiling on what permissions an app is allowed in a resource server, which may be need for scope downscoping, audience restriction etc. while issuing tokens via token exchange(#2198)

[RushanNanayakkara]

Hi @thiva-k ,

As discussed with @darshanasbg offline, this use case is intended to be covered via trusted tokens, not token exchange. The resource server does not issue a token of its own instead it validates the external IdP's token directly via JWKS on every request.

The idea is for a second Thunder instance to act purely as a resource server, delegating all IAM actions (login, token issuance, user management) to the upstream IdP.

Your points on client_id validation redundancy, optional claim validation, multiple issuers, and resource parameter support are all valid — but they apply to token exchange, which is a separate effort. Agent ID / OBO use cases requiring a newly-issued token would still need token exchange and aren't addressed by this feature.

[thiva-k]

tokenValidator.ValidateSubjectToken — OAuth token exchange (RFC 8693)

Subject tokens validations from external issuers for token exchange will not be part of this effort (#2270).