README
¶
02: Resource Token with HS256 (Federated Auth)
Non-UI · No infrastructure needed · Builds on Example 01
A registered app mints JWTs for individual users, not for itself. The resource server validates with the same KeyStore the app's secret is registered into. This is OneAuth's federated-auth pattern.
Two-process architecture
main.go boots an auth server (AppRegistrar) and a resource server
sharing an in-process KeyStore. With --serve, both bind on real
ports — any client can register an app and mint tokens. The walkthrough
is one such client; it spins up the same servers in-process via
httptest.
Quick start
make demo # interactive walkthrough (TUI)
make serve # auth :8081, resource :8082
See WALKTHROUGH.md for the full step-by-step with sequence diagram and copy-paste reproductions.
Targets
make … |
What |
|---|---|
demo (default) |
Interactive walkthrough with the TUI renderer |
demo-plain |
Plain stdout renderer |
demo-ci |
Non-interactive |
serve |
Bind AS + RS on real ports and block |
walkthrough |
Regenerate WALKTHROUGH.md |
What's next
03 — RS256 + JWKS — asymmetric signing. The app registers a public key, serves it via JWKS, and the RS discovers it automatically. No shared secrets.
Documentation
¶
Overview ¶
Example 02: Resource Token with HS256 (Federated Auth).
Building on Example 01: a registered app mints resource-scoped tokens for individual users — not just for itself. The resource server validates with the same KeyStore the app's secret was registered into.
Two-process architecture (mirrors Example 01):
make serve # auth server :8081, resource server :8082 make demo # demokit walkthrough (--tui for the styled TUI)
In --serve mode the auth server and resource server share an in-process KeyStore (registration on the AS makes the secret visible to the RS for validation). A real deployment would back this with a persisted KeyStore (FS / GORM / GAE).
See: https://www.rfc-editor.org/rfc/rfc7519 (JWT)
Source Files