Lion Cipher Lab

Put SSO in front of an app that has no login — oauth2-proxy and Keycloak

• Identity & Access Management
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Every organization has that one internal app -- an old dashboard, a metrics page, a wiki, an admin panel -- that has no real login of its own and was only ever 'protected' by being on the internal network. The moment anyone can reach it, anyone is in. Rewriting the app to speak OpenID Connect is often impossible: no source, no maintainer, no budget. oauth2-proxy is the standard, free answer to exactly this problem. It is an authenticating reverse proxy: you place it in front of the app, point it at an identity provider (here, the Keycloak realm you built in the prerequisite lab), and now…

What you'll learn

• explaining what an authenticating reverse proxy is, and how oauth2-proxy sits BETWEEN a browser and an app to force a login before any request reaches the app
• registering an OIDC client for a proxy in Keycloak: client id, client secret, confidential client authentication, and the exact redirect URI /oauth2/callback
• generating a proper random cookie secret (16, 24, or 32 bytes) with openssl or python, and understanding why a weak or short one breaks the encrypted session cookie
• configuring oauth2-proxy against an OIDC provider: --provider=oidc, --oidc-issuer-url, --client-id/--client-secret, --cookie-secret, --email-domain, --upstream, --redirect-url, --http-address
• MEASURING the before/after: curl the app directly (200, no auth) versus through the proxy unauthenticated (302 redirect to Keycloak), then seeing the app reached only after login
• reading the injected identity headers X-Forwarded-User, X-Forwarded-Email, and X-Auth-Request-* in the whoami output -- the measurable proof the proxy authenticated the user and told the app who they are
• tightening authorization at the proxy: --email-domain=* to allow any logged-in user versus an allowlist by email domain or Keycloak group
• the judgment: oauth2-proxy is authN at the EDGE, not authZ inside the app -- so the upstream must be reachable ONLY via the proxy (or an attacker forges X-Forwarded-User and walks in) and must still enforce its own per-user authorization
• when to reach for this pattern (a legacy app that cannot do OIDC) versus building OIDC directly into a modern app

Steps in this lab

1. The problem, and what oauth2-proxy is
2. The words you need: upstream, issuer URL, redirect URI, client secret, cookie secret
3. BEFORE: run a no-auth app and prove anyone can reach it
4. Register an OIDC client for the proxy in Keycloak
5. Generate a proper random cookie secret
6. Start oauth2-proxy in front of the app
7. AFTER: measure the redirect, then log in and read the injected identity
8. Tighten who is allowed in: from any-logged-in-user to an allowlist
9. The honest negative: authN at the edge is not authZ inside the app

Open the full interactive lab →