Validate at the apiserver

Every failure the workload track can show is token-side — a bad aud, a missing claim. This step shows the failure class OIDC people under-learn: the token below is flawless, and whether it gets 401 or authenticates depends entirely on a config file it has never seen. Toggle the apiserver's state and watch the verdict — the token panel will not change.

what actually happens

kubectl presents the id_token as a Bearer header on every API request.
The apiserver decides — if --oidc-* flags are configured, it validates and resolves an identity; if not, there is no OIDC authenticator at all and the same token is rejected.

the token · constant does not change when you toggle below

eyJhbGciOiJSUzI1NiIsIm…ic-use decode in step 1 →

sig
iss
aud
exp
email
groups
mfa

apiserver config: no --oidc-* flags flags configured

The validator

cat /etc/rancher/k3s/config.yaml

cat: /etc/rancher/k3s/config.yaml: No such file or directory
# no --oidc-* flags — no OIDC authenticator registered
# the apiserver has never heard of this issuer

cat /etc/rancher/k3s/config.yaml

kube-apiserver-arg:
  - "oidc-issuer-url=https://dev-12345678.okta.com"  # ≡ token.iss (JWKS fetched here)
  - "oidc-client-id=0oa8q2lmv3RtYwHcK5d7"  # ≡ token.aud
  - "oidc-username-claim=email"  # token.email → username
  - "oidc-username-prefix=okta:"  # → okta:lab-admin@authlab.app
  - "oidc-groups-claim=groups"  # token.groups → groups
  - "oidc-groups-prefix=okta:"  # → okta:app-k8s-admins

What the apiserver checks

iss

token.iss ∅ not configured --oidc-issuer-url

aud

token.aud ∅ not configured --oidc-client-id

groups

token.groups[] ∅ not configured --oidc-groups-claim + okta: prefix

Nothing to check against — the authenticator that would read these claims was never registered. The token is not even parsed.

Every row now has a target. Signature verified against the issuer's JWKS, claims mapped to a cluster identity.

HTTP/1.1 401 Unauthorized same token · every claim valid · no validator configured

authenticated as okta:lab-admin@authlab.app · groups: okta:app-k8s-admins

a valid token is necessary but not sufficient — someone on the consumer side has to be configured to trust the issuer.