Practice: Security basics in designs
Generated by Claude through GigAI (karthik446/gigai-learning-center 4c0cb514) on 2026-10-13.
Main tool: Keycloak · Keycloak runs in one container on a laptop and puts OpenID Connect login, token validation, role and policy based authorization, key rotation and TLS configuration in one place, so every control in the lesson can be placed and tested on a real trust boundary. · Alternatives: Auth0 and Okta are hosted identity services with no server to run but paid tiers and less control; Dex is a lightweight OpenID Connect broker without user management or fine-grained authorization; Ory Hydra with Kratos splits the token server and identity store into separate services you compose yourself; Open Policy Agent handles only the policy decision and needs a separate identity provider; HashiCorp Vault and AWS KMS cover secrets and key management rather than login.
Every step links into the tool's own documentation; links were checked on 2026-10-13 · version 1
Setup (one time)
1. Install a container runtime such as Docker or Podman and confirm the prerequisites listed for the Keycloak container guide.
The whole path runs Keycloak as a local container, so nothing else has to be installed and no paid cloud or GPU is needed.
Explained in: Docker - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The container runtime reports its version and can pull an image.
2. Start the Keycloak container in development mode with a bootstrap admin username and password.
Development mode gives a working server in seconds with relaxed defaults, which is the baseline you will later harden.
Explained in: Docker - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The container log shows that Keycloak started and is listening on the local port.
3. Log in to the Admin Console with the bootstrap admin account.
The Admin Console is where realms, clients, roles and keys are managed, and seeing it confirms the admin credentials work.
Explained in: Docker - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The Admin Console opens and shows the master realm.
Steps
1. Create a new realm and a test user in it, leaving the master realm for administration only.
A realm is the first trust boundary in Keycloak: users, clients and keys in one realm are isolated from another. Keeping application users out of the master realm is a least privilege decision made on day one.
Explained in: Docker - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The realm selector lists your new realm and the test user can sign in to that realm's Account Console.
2. Write a one-page STRIDE threat model of your realm that lists every OpenID Connect endpoint as a trust boundary, who calls it, and what an attacker could spoof, tamper with or disclose there.
Each endpoint is a place where a browser, an application or an API crosses into Keycloak, so the endpoint list is a ready-made map of boundaries. Naming the threats first tells you which controls the later steps must put in place.
Explained in: Securing applications and services with OpenID Connect - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: You have a table with one row per endpoint, each with a caller, at least one named threat and the control you plan to apply.
3. Register an OpenID Connect client in your realm and run the authorization code flow end to end with the test user.
The authorization code flow is the standard way a design answers who the caller is, and it keeps user credentials away from the application. Seeing the code and token exchange makes the roles of browser, client and identity provider concrete.
Explained in: Securing applications and services with OpenID Connect - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: After logging in you hold an ID token and an access token, and the decoded ID token names your test user and your realm as issuer.
4. Query the realm certificate endpoint and validate the signature, issuer, audience and expiry of the access token from the previous step.
An API must verify a JSON Web Token itself and never trust it because it parses. This is the control for spoofing and tampering at the boundary between the application and the API.
Explained in: Securing applications and services with OpenID Connect - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: A valid token passes your check, and a token with one altered character or an expired token is rejected.
5. Configure the client with exact redirect URIs and no wildcards, then run a login request that uses an unregistered redirect address.
The redirect URI is attacker-controlled input to the login flow, and a loose pattern lets authorization codes leak to another site. Strict input validation at this boundary is one of the cheapest controls in the design.
Explained in: Securing applications and services with OpenID Connect - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: Login with the registered address succeeds and the request with the unregistered address is refused with an invalid redirect error.
6. Enable authorization services on a confidential client so that it acts as a resource server.
Authentication says who the caller is; a resource server with its own policies decides what that caller may do. Centralising that decision keeps permission logic out of scattered application code.
Explained in: Authorization Services Guide (www.keycloak.org), checked 2026-10-13
Done when: The client shows an Authorization tab with default resource, policy and permission entries.
7. Create a resource with scopes, two realm roles and a role-based policy that grants only one role access, then evaluate it for a user in each role.
Least privilege means each role gets only the scopes it needs and everything else is denied by default. Evaluating both users proves the policy denies as well as permits.
Explained in: Authorization Services Guide (www.keycloak.org), checked 2026-10-13
Done when: The evaluation result shows permit for the user with the required role and deny for the user without it.
8. Configure a rotation of the realm signing key by adding a generated key pair with higher priority and making the old key passive, then compare the key id in tokens issued before and after.
Signing keys are the secret that every token's trust rests on, so a design needs a way to replace them without logging everyone out. Passive keys keep old tokens verifiable while new tokens use the new key.
Explained in: Server Administration Guide (www.keycloak.org), checked 2026-10-13
Done when: A new token carries the new key id, a token issued before the rotation still validates, and the certificate endpoint lists both keys.
9. Run an export of the resource server's authorization configuration to a file, change a policy in the console, and compare the new export with the saved one.
Authorization rules that live only in a console cannot be reviewed or reproduced. An exported file can be kept under version control and diffed like any other design artefact.
Explained in: Authorization Services Guide (www.keycloak.org), checked 2026-10-13
Done when: You have two exported files and the difference between them shows exactly the policy change you made.
10. Create a dedicated client with a service account that has only the admin roles it needs, and run an Admin REST API call with its token to list the clients of your realm.
Automation and pipelines should never use a human admin password. A narrowly scoped service account makes scripted changes repeatable and limits the damage if its secret leaks.
Explained in: Server Developer Guide (www.keycloak.org), checked 2026-10-13
Done when: The call returns the realm's client list using a client credentials token, and a call outside the granted roles is rejected as forbidden.
11. Start Keycloak in production mode on your laptop with a hostname and a locally generated TLS certificate instead of development mode.
Production mode refuses to start without TLS and a hostname, which shows the secure defaults a real deployment enforces. Tokens and passwords must never cross a boundary in clear text.
Explained in: Configuring Keycloak - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The server answers only over HTTPS with your certificate and plain HTTP access to the login page no longer works.
12. Create an optimized Keycloak build, then start the server from it using the optimized flag while supplying the database and keystore passwords from a Java KeyStore file rather than the command line.
A pinned, pre-built server with secrets kept out of process arguments and shell history is the shape a production deployment takes. It makes startup reproducible and removes the easiest way to leak credentials.
Explained in: Configuring Keycloak - Keycloak (www.keycloak.org), checked 2026-10-13
Done when: The server starts from the optimized build without a rebuild step, no password appears in the start command, and login to your realm still works over HTTPS.