Security: OAuth 2.0, OIDC & Zero Trust

In Hands-on 3 we secured the store with a homemade scheme: auth-service checks the password, signs a JSON Web Token (JWT) with an HMAC secret and returns it in a cookie; on every request the gateway asks auth-service to resolve the token and forwards the caller's id in the id-account header. That works for one web app with one login form. Now the store wants "Sign in with Google", a mobile app, a nightly job that calls order-service with no user behind it, and — one day — a vulnerable library lets an attacker run code inside the product-service pod. The homemade scheme has no answer to any of these.

JWT is a transport format — it carries claims such as "this is account 42". It says nothing about how the user proved their identity, who may issue tokens, how a third-party app gets access without seeing the password, or why one service should trust a call from another. OAuth 2.0 and OpenID Connect are the standards that fill these gaps; Zero Trust is the architecture that stops trusting the network itself: distrust everything, verify always.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

Roadmap

1. Overview (this page) — authentication vs. authorization, what Hands-on 3 built, what JWT alone cannot do, and the map of security layers of the store.
2. OAuth 2.0 & OpenID Connect — roles, tokens and scopes, grant types (Authorization Code + PKCE, Client Credentials), OIDC and the ID Token, and how the gateway validates tokens (JWKS vs. introspection).
3. Zero Trust, mTLS & Secrets — perimeter vs. Zero Trust, mutual TLS and workload identity, Kubernetes NetworkPolicy, and secrets management.

Authentication vs. authorization

Two questions are asked on every request, and they are often confused:

A few terms used throughout the class:

• Principal — the authenticated entity: a user (ada@store.com) or a workload (order-service).
• Credential — what a principal presents to prove its identity (a password, a private key, a token).
• Token — a string issued after authentication that the principal presents instead of the credential. A bearer token grants access to whoever holds it, like cash: steal it and you can spend it.
• Claim — a statement inside a token, such as "sub": "42" or "scope": "orders:read".

What Hands-on 3 built

The flow below is the one you implemented: the token is a reference that only auth-service can read, and the gateway asks for it on every call.

sequenceDiagram
    autonumber
    actor B as Browser
    participant GW as gateway-service
    participant AU as auth-service
    participant AC as account-service
    B->>GW: POST /auth/login {email, password}
    GW->>AU: forward (open route)
    AU->>AU: check password, sign JWT (HMAC secret)
    AU-->>B: Set-Cookie: __store_jwt_token
    B->>GW: GET /accounts/me + cookie
    GW->>AU: POST /auth/solve {token}
    AU-->>GW: {idAccount}
    GW->>AC: GET /accounts/me + id-account header
    AC-->>B: 200 OK

It is a sound design for a single application, and it has three properties worth naming:

• Symmetric signature (HMAC, e.g. HS256) — the same secret signs and verifies. Only auth-service holds JWT_SECRET_KEY, so only it can validate tokens; that is why the gateway must call it.
• Remote validation — one extra network hop per request, but auth-service could refuse a token immediately (for example, after logout).
• Trust in the network — account-service believes any id-account header, because only the gateway can reach it inside the Docker network.

What JWT alone cannot do

The security layers of the store

No single control protects a system. Defense in depth stacks independent layers, so that an attacker who defeats one still faces the next. The diagram follows a request from the Internet down to the data:

flowchart LR
    U(["Client"]) -->|"HTTPS (TLS)"| GW["Gateway<br>validates token"]
    IdP["Identity Provider<br>(auth-service / Keycloak)"] -->|"issues tokens"| U
    GW -->|"identity header<br>(mTLS inside)"| SVC["order-service<br>checks ownership"]
    SVC -->|"allowed by<br>NetworkPolicy"| PS["product-service"]
    SVC -->|"short-lived<br>DB credential"| DB[("Postgres")]

Key takeaways

• Authentication answers who, authorization answers what; the gateway authenticates, but each service must still authorize access to its own objects.
• A JWT is only a format. OAuth 2.0 defines how tokens are obtained and delegated; OIDC adds a standard identity (ID Token).
• Hands-on 3 uses a symmetric key and remote validation; standard deployments use asymmetric keys and a JWKS so any service can validate locally.
• Zero Trust removes the assumption that the internal network is safe: every call carries a verifiable identity and is checked against a policy.
• Security is layered: TLS at the edge, tokens for users, mTLS and NetworkPolicy between services, a secrets manager for credentials.