~/cred-visualizer

cat README.md

one assertion, two consumers

An OIDC JWT is just a signed assertion — the variable is who validates it and what they do with it. Two tracks follow the same class of token to two very different validators: a cloud token service exchanging it for credentials, and an API server deciding whether to trust it at all.

workload-federation # forgejo ci → gcp api

A machine. A CI job federates into GCP and impersonates a service account — every failure mode is token-side.

1 mint-oidc oidc-jwt
2 exchange-sts federated
3 impersonate-sa sa-token
4 call-api api-resp

4 steps · 3 identity contexts · validator: GCP STS + IAM

mint-oidc

workforce-federation # kubectl via okta sso → kube-apiserver

A human. kubectl presents an Okta id_token to the kube-apiserver — including the failure the other track cannot show: a flawless token rejected because no validator was configured.

1 mint-okta id_token
2 validate-apiserver 401 ⇄ identity
3 resolve-rbac authorization

3 steps · 1 interactive failure toggle · validator: the apiserver itself

mint-okta