# Why the resource server validates the token again

Canonical: https://stevenmoriasi.com/blog/enterprise-identity-gateway
By [Steven Moriasi](https://www.linkedin.com/in/steven-moriasi/).
Source: https://github.com/steven-moriasi/enterprise-identity-gateway
Date: 2025-09-09

## Context

LLM agents and automation workers are principals. If identity is “the gateway said so,” a compromised edge becomes every system.

The [Enterprise Identity Gateway](https://github.com/steven-moriasi/enterprise-identity-gateway) is the stricter path.

## Decision

user or workload → Keycloak → OIDC access token → FastAPI gateway → independently validating protected service

Only RS256 bearer tokens from the configured issuer and audience are accepted. JWKS keys refresh on expiry and at a bounded rate for an unknown `kid`. Users and workloads are distinct. Authorization combines principal kind, client, role, scope, and tenant. The gateway forwards the original access token; the protected service validates it again. Back-channel logout revokes matching `sid` or `sub` values.

## What I rejected

A gateway that strips the token and sends an internal header the resource server trusts. That is convenient until the edge is the incident.

## Failure scenario

An unknown `kid` arrives. JWKS refresh is rate-limited. The request fails closed. Logout on the IdP revokes the session; a replayed access token with that `sid` does not pass the protected service.

## Evidence

Keycloak-backed local stack, JWKS validation tests, and a protected service that does not trust the gateway alone. This is an engineering lab, not a production IdP.

Inspect: [Repository](https://github.com/steven-moriasi/enterprise-identity-gateway) · [Run locally](https://github.com/steven-moriasi/enterprise-identity-gateway#readme)

_—by [Steven Moriasi](https://www.linkedin.com/in/steven-moriasi/)_