On a six-person team I owned the identity and access layer of the API — the part a health portal lives or dies by — built test-first (the functional test goes in red, then the feature makes it green).
Session lifecycle
Login through the API (password grant, server to server), logout that ends both our session and Keycloak's, 15-minute idle expiry; a session also ends as soon as Keycloak refuses to renew its token (account disabled, signed out). Every refusal is the API's own JSON error, never a redirect.
Ownership guard
A user can read only their own record; staff can read any. Everyone else gets a 403 — the same answer whether the id exists or not.
Append-only audit trail
Every refused access is written to an append-only table (DB triggers), with the caller, the IP and a redacted path — personal data in the URL never reaches the log.
Access-matrix build gate
One test file holds a role × route matrix: every /api route × 4 callers (anonymous, patient, practitioner, staff). The route list is read from Spring itself, so a new endpoint without an access rule fails the build. An allowed cell must also not answer a server error or a redirect.
Architecture & threat model
Wrote the architecture and threat-model docs and the decision record for the password-grant BFF — trust boundaries and controls mapped to code and tests.
Privilege escalation found & fixed
While writing the threat model I found the staff role carried Keycloak admin rights — with only their own password a staff member could create accounts and read every user straight from Keycloak's admin API, bypassing the API's rules and audit trail. Proved it with a test (201 → 403 after the fix), removed the rights; only the API's service account keeps them.
Metrics off the public port (in review)
In production, Spring Boot Actuator (metrics, health) moves to a private management port that is never published; Prometheus scrapes it over the Docker network, and the public port keeps only /livez and /readyz ({"status":"UP"} only).