Configurable JWT authentication to ateapi by EItanya · Pull Request #757 · agent-substrate/substrate

Eitan Yarmush (EItanya) · 2026-08-05T14:59:14Z

Summary

Fixes #733 by adding configurable JWT authentication to ateapi.

Supports multiple OIDC/JWT providers through a YAML configuration file.
Validates issuer, audience, signature, and token lifetime.
Supports custom CAs and authenticated OIDC discovery for Kubernetes
ServiceAccount JWTs.
Restricts MintJWT to the configured actor-identity provider.
Replaces the existing --client-jwt-* flags.

RBAC remains follow-up work.

Testing

go test ./...
Kubernetes ServiceAccount JWT E2E
Real Google-issued JWT E2E
golangci-lint and repository verification checks

Shruti Nair (SHRUTI6991) · 2026-08-05T18:49:22Z

I overall really like the idea of your PR and it honestly supersedes mine: #759 which is a much simpler version and focusses only on Human based authentication + K8 (only OIDC).

Some comments:

In terms of developer experience, it is much easier for developers to run kubectl-ate --token $(gcloud auth print-identity-token) instead of taking a config file. Can you refactor this?
Before routing to the correct provider, may be validate the JWT claims.
Not related to the current PR. What's your thought on making a chain of authenticators? For standard OIDC JWTs, matching directly on the iss claim works great. If Substrate expands to support non-OIDC tokens (like static API keys or tokens without an iss claim), wrapping authenticators in an Authenticator chain interface might be a nice extensibility pattern down the road.

cc: Taahir Ahmed (@ahmedtd)

Eitan Yarmush (EItanya) · 2026-08-05T20:06:48Z

I overall really like the idea of your PR and it honestly supersedes mine: #759 which is a much simpler version and focusses only on Human based authentication + K8 (only OIDC).

Okie dokie, I'll post this a ready for review.

In terms of developer experience, it is much easier for developers to run kubectl-ate --token $(gcloud auth print-identity-token) instead of taking a config file. Can you refactor this?

This can leak tokens into the shell so isn't a great idea, what about stdin or something like that?

Before routing to the correct provider, may be validate the JWT claims.

👍

Not related to the current PR. What's your thought on making a chain of authenticators? For standard OIDC JWTs, matching directly on the iss claim works great. If Substrate expands to support non-OIDC tokens (like static API keys or tokens without an iss claim), wrapping authenticators in an Authenticator chain interface might be a nice extensibility pattern down the road.

Absolutely. Do you think we should do that in a follow-up?

Shruti Nair (SHRUTI6991) · 2026-08-05T21:33:26Z

Eitan Yarmush (@EItanya) yes, STDIN sounds good to me.

Absolutely. Do you think we should do that in a follow-up?

I would consider this a P2 since we aren't currently working towards having any other authentication mechanisms except the JWT for now. Let me know Taahir Ahmed (@ahmedtd) if you think otherwise.

Max Thompson (thompsonmax) · 2026-08-05T22:31:22Z

 	ServiceAccountName string
 	ServiceAccountUID  string
 	PodName            string
 	PodUID             string
 	SecretName         string
 	SecretUID          string
 	NodeName           string
 	NodeUID            string


[nit] Is it worthwhile to logically separate out the k8s-specific claims by placing them in a separate, inner struct, or just indicating their group with a comment?

Max Thompson (thompsonmax) · 2026-08-05T22:41:46Z

+	if key == nil && len(v.keys) > 0 {
+		v.lastUnknownKeyRefresh = now
+	}
+	keys, err := discoverKeysForIssuer(ctx, v.httpClient, v.issuer)


Once jwksRefreshInterval elapses, a token whose key may already be in the cache only verifies if this refresh succeeds. So a transient issuer outage 5+ minutes after the last refresh fails all JWT auth, even for keys we already hold.

I believe k8s' OIDC authenticator serves stale keys when refresh fails, should we do the same here?

Max Thompson (thompsonmax) · 2026-08-05T22:53:44Z

+	if key != nil && now.Sub(lastRefresh) < jwksRefreshInterval {
+		return key.PublicKey, nil
+	}
+	if key == nil && hasKeys && !lastUnknownKeyRefresh.IsZero() && now.Sub(lastUnknownKeyRefresh) < unknownKeyRefreshInterval {


Since we check hasKeys here, I believe this check does not guard against the case where the initial set of keys has not yet been fetched (possibly delayed due to an issuer outage), so each token validation would trigger a request to fetch keys unthrottled until the first set of keys is successfully fetched.

Should we implement a similar throttling mechanism to prevent unthrottled fetches before the initial set of keys is fetched?

Failed initial fetches are now rate-limited as well.

Max Thompson (thompsonmax) · 2026-08-05T23:01:46Z

+		if provider.Issuer != issuer {
+			continue
+		}


[nit] Is it worth providing a log if no issuers match to make it easier to debug that case?

Added a debug-level unmatched-issuer log to avoid unauthenticated warning spam.

Max Thompson (thompsonmax) · 2026-08-05T23:10:10Z

+func Verify(ctx context.Context, httpClient *http.Client, jwt string, expectedIssuer, expectedAudience string, now time.Time) (*Claims, error) {
+	return NewVerifier(expectedIssuer, []string{expectedAudience}, httpClient).Verify(ctx, jwt, now)
+}


IIUC this is dead code now, since we call verifier.Verify in cmd/ateapi/main.go. Should we remove?

Removed the unused package-level helper and updated tests to use the cached verifier.

Max Thompson (thompsonmax) · 2026-08-05T23:14:08Z

+		return fmt.Errorf("at least one JWT provider is required")
+	}
+	for i, provider := range cfg.JWTProviders {
+		if provider.Name == "" || provider.Issuer == "" || provider.Verify == nil {


Should we also validate uniqueness of Issuer in the list of JWTProviders?

Shruti Nair (SHRUTI6991) · 2026-08-07T16:55:58Z

Hi Eitan Yarmush (@EItanya), are you working on this PR?

Eitan Yarmush (EItanya) · 2026-08-07T17:56:56Z

Hi Eitan Yarmush (Eitan Yarmush (@EItanya)), are you working on this PR?

Yup! I was focused on #708, but that’s in so I’ll go full steam on this now.

The GitHub CI situation yesterday really messed me up

…-auth # Conflicts: # cmd/ateapi/internal/actoridentity/actoridentity.go # cmd/ateapi/internal/actoridentity/actoridentity_test.go # cmd/ateapi/main.go

Eitan Yarmush (EItanya) · 2026-08-07T18:31:35Z

Addressed in the latest push: --token-file=- now reads one token from stdin. The unverified issuer only selects a configured verifier and grants no authority; signature, issuer, audience, subject, and time validation happen immediately afterward, since cryptographic validation requires first selecting the issuer keys. Agreed that authenticator chaining should remain a P2 follow-up when we add a non-JWT mechanism.

Eitan Yarmush (EItanya) added 2 commits August 5, 2026 13:19

Add configurable external JWT authentication

e956a1d

Refactor JWT discovery into oidcjwt package

d8c0664

Eitan Yarmush (EItanya) mentioned this pull request Aug 5, 2026

Human JWT Auth: Human user of substrate can authenticate to ate-api-server with a JWT issued by an external IDP #733

Open

Eitan Yarmush (EItanya) changed the title ~~Issue 733 human jwt auth~~ Configurable JWT authentication to ateapi Aug 5, 2026

Eitan Yarmush (EItanya) requested review from Lior Lieberman (LiorLieberman) and Taahir Ahmed (ahmedtd) August 5, 2026 17:08

Eitan Yarmush (EItanya) marked this pull request as ready for review August 5, 2026 20:06

Max Thompson (thompsonmax) reviewed Aug 5, 2026

View reviewed changes

Eitan Yarmush (EItanya) added 2 commits August 7, 2026 18:19

Address JWT authentication review feedback

d151fe8

Merge remote-tracking branch 'upstream/main' into issue-733-human-jwt…

0079b39

…-auth # Conflicts: # cmd/ateapi/internal/actoridentity/actoridentity.go # cmd/ateapi/internal/actoridentity/actoridentity_test.go # cmd/ateapi/main.go

Uh oh!

Conversation

Eitan Yarmush (EItanya) commented Aug 5, 2026

Summary

Testing

Uh oh!

Shruti Nair (SHRUTI6991) commented Aug 5, 2026

Uh oh!

Eitan Yarmush (EItanya) commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Shruti Nair (SHRUTI6991) commented Aug 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Shruti Nair (SHRUTI6991) commented Aug 7, 2026

Uh oh!

Eitan Yarmush (EItanya) commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Eitan Yarmush (EItanya) commented Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Eitan Yarmush (EItanya) commented Aug 5, 2026 •

edited

Loading

Eitan Yarmush (EItanya) commented Aug 7, 2026 •

edited

Loading