identity
OIDC, Keycloak, roles and the difference between authentication and authorization.
-
Self-Hosted Identity with Keycloak: Central Offboarding and Forward Auth
Every internal service wants its own user database, and each one becomes a password nobody audits and an account that outlives the employment. Running a central identity provider turns offboarding into one action instead of a checklist, and this walks through why, with a runnable Keycloak setup that proves a single disable call locks a user out at the token endpoint, plus a forward-auth proxy protecting an application with no login of its own.
-
Forward Auth: Putting Real Authentication in Front of Software That Has None
Legacy admin panels, monitoring dashboards and device UIs frequently have no login of their own, yet they are exactly the systems you least want exposed. Forward auth lets a reverse proxy ask an external service, on every request, whether the caller may proceed, without changing a line of the backend. Here is the subrequest protocol, the header-spoofing mistake that undermines it, and a complete Traefik plus Keycloak stack that enforces it.
-
Enforcing Client Identity Alongside Realm Roles
A Keycloak realm role lives on the user, not on the client, so a token minted for a low-trust public application can carry the same role claim as one minted for a trusted backend. This shows how to close that gap in a FastAPI dependency by checking the azp claim against an allow-list alongside the usual signature, issuer and role checks, with a self-contained pytest suite.
-
OIDC Client Shapes: A Token-Validating API Is Not a Login Client
Configuring every OIDC client the same way conflates "users log in here" with "this service validates a token", and the wrong shape accepts flows nobody intended. This article covers the three client shapes and gives working Keycloak configuration plus a Python JWT validator that checks issuer, audience and signature.
-
Realm-as-Code: Reconciling Clients and Roles But Never Users or Signing Keys
Reconciling a Keycloak realm from a file is safe for clients, roles and role mappings, but the same "make live state match this JSON" instinct applied to users or signing keys deletes real accounts and invalidates every outstanding token. This article draws that boundary precisely, and works through a Python script against the Admin REST API that reconciles clients and realm roles idempotently against a local Keycloak container, while proving a second run changes nothing and a user created out-of-band survives every run.
-
Group-Based Default-Deny Instead of Hand-Maintained Peer Lists
Per-peer VPN rules accumulate one exception at a time until nobody can say who is allowed to reach a given service. This article builds a NetBird policy set around groups instead of peer addresses, replaces the default allow-all policy with default-deny, and shows a script that checks the resulting access matrix against what the policy set claims to allow.
-
A Multi-Service docker-compose That a New Contributor Can Actually Start
A backend that needs an identity provider, a database, a cache and a time-series store fails unpredictably under a naive docker-compose file because none of it waits for the others to actually be ready. This shows the healthcheck, seeding and end-to-end test that make `docker compose up` a reliable one-command environment.
-
A 500 That Was a Misconfigured Client, Not an Auth Failure
Code that assumes an OAuth2 introspection response always carries an active field works right up until the resource server's own client credentials are wrong, at which point every request that reaches it throws instead of returning a clean 401. This article separates the response shapes introspection can actually return and gives a tested client that handles all of them.
-
A Confidential OIDC Client That Exists Only to Introspect Tokens
An API that validates access tokens by calling the OAuth2 introspection endpoint has to authenticate to that endpoint itself, and a public client such as a single-page application has no secret to do it with. This article sets up a second, confidential client whose only job is introspection, and gives the full provider configuration and the calls that use it.
-
An OpenAI-Compatible Proxy in Front of a Local Model Server
Local model servers speak a shape close enough to the OpenAI API that existing SDKs and tools can point at them unmodified, but close enough is not the same as safe to expose. This builds a small FastAPI proxy that adds authentication and a health check that cannot itself trigger a model load.