Explanation and walkthrough for the mobile-banking authn/authz PoC.
The story in one paragraph
A client logs in via Keycloak (IdP) and gets a JWT. It calls the banking API through Kong (gateway / PEP). Kong introspects the token with Keycloak, then asks OPA (PDP) whether this caller may take this action. If allowed, Kong forwards the request to banking-api-service (resource server), which independently re-validates the JWT before returning data. alice can read only her own accounts; ops-admin can read any account.
Reading map
Part I — Foundations
- 01 — Concepts — authn/authz, IdP, PEP, PDP, JWT (start here)
- 02 — This Project Architecture — how the concepts map to components
- 03 — Request Flows — the end-to-end stories
- 04 — Local Demo Guide — run it and watch it work
Part II — Component Deep Dives
- 05 — Component Tour — one-paragraph map of all five components
- 06 — Keycloak / IdP — the IdP that issues tokens
- 07 — Kong — the gateway / PEP and its OPA plugin
- 08 — OPA — the PDP and its Rego policy
- 09 — banking-api-service — the resource server that re-validates
- 10 — identity-bootstrap-service — demo user setup
Part III — Token Mechanics
- 11 — JWT Signature, Validation & Introspection — signature, validation, introspection
- 12 — JWKS Deep Dive — JWK/JWKS and key selection by kid
- 13 — Access & Refresh Token Lifecycle — access/refresh tokens and renewal
Part IV — Reference
- 14 — Request & Response Details — wire-level headers, bodies, claims
Where to start
- New to the topic → 01 — Concepts
- Want the system fast → 02 — Architecture + 03 — Request Flows + 04 — Demo Guide
- Need wire-level payloads → 14 — Request & Response Details
Design and planning docs
- Docs reorganization — design
- Docs reorganization — plan
- Mobile-banking auth — design
- Mobile-banking auth — plan
