JWT Claim Validation at the Edge: Scope Inflation, Audience Misrouting, and the RBAC Boundary Problem Most Go microservice deployments that use JWTs get signature verification right and get everything else wrong. The cryptographic check passes; the authorization semantics collapse. This article is about the gap between those two things—specifically scope inflation, audience misrouting, and why pushing RBAC enforcement into individual services without a coherent boundary contract produces privilege escalation paths that are invisible in logs and nearly impossible to audit. The Structural Problem A JWT is a bearer credential with embedded claims. The issuer signs it; every downstream service that trusts the issuer key must decide independently what the claims mean. In a monolith, that decision lives in one place. In a microservice mesh, it lives in every service, and the coordination mechanism is usually informal: a shared library, a Confluence page, or implicit convention. The gap creates two distinct failure modes. Scope inflation occurs when a service interprets a broad scope claim as authorization for a specific resource action that was never intended. A token issued with scope: write for a billing API gets accepted by an inventory service that checks only for the presence of write in the claim, not whether the audience is billing. The service is technically validating the token correctly—signature valid, not expired—but is making an incorrect authorization decision. Audience misrouting occurs when a token issued for service A is accepted by service B because aud validation is skipped, lenient, or misconfigured. RFC 7519 requires that if the aud claim is present, the recipient must identify itself as the intended audience and reject the token if it does not. In practice, Go libraries that wrap golang-jwt/jwt often make aud validation opt-in, and engineers under deadline pressure leave it out. Why Go Library Defaults Compound the Problem The golang-jwt/jwt library parses and validates tokens but makes audience validation explicit via RegisteredClaims and a ValidFor method that most callers do not call. The zero-value ParserOption does not enforce aud. A minimal but dangerously incomplete validation path looks like: token, err := jwt.ParseWithClaims(raw, &jwt.RegisteredClaims{}, keyFunc) if err != nil || !token.Valid { return ErrUnauthorized } claims := token.Claims.(*jwt.RegisteredClaims) // scope check added; aud check absent if !containsScope(claims.Subject, requiredScope) { return ErrForbidden } This passes CI. It passes code review if reviewers aren't looking for audience enforcement. It fails in production when a token issued for the payments service is replayed against the reporting service. A production-correct validator enforces both fields: func ValidateToken(raw, expectedAudience, requiredScope string, keyFunc jwt.Keyfunc) (*jwt.RegisteredClaims, error) { claims := &jwt.RegisteredClaims{} token, err := jwt.ParseWithClaims(raw, claims, keyFunc, jwt.WithExpirationRequired(), jwt.WithIssuedAt(), ) if err != nil || !token.Valid { return nil, ErrUnauthorized } if !claims.VerifyAudience(expectedAudience, true) { return nil, ErrAudienceMismatch } if !hasScope(claims, requiredScope) { return nil, ErrInsufficientScope } return claims, nil } func hasScope(claims *jwt.RegisteredClaims, required string) bool { // Scope is typically a space-delimited string in a custom claim. // Adapt to your token schema. raw, ok := claims.Subject, false _ = raw // Real implementation reads from a typed custom claim struct. _ = ok return false // placeholder—see custom claims section below } The required: true boolean in VerifyAudience is the load-bearing detail. With false, an absent aud claim passes. With true, it fails, enforcing that every token must declare its intended recipient. Scope as a First-Class RBAC Dimension Scope claims are not roles. Roles describe what a principal is (admin, reader). Scopes describe what a token is permitted to do in a specific context (payments:write, inventory:read). Conflating them is the root cause of scope inflation. A stricter claim schema separates the two: type ServiceClaims struct { jwt.RegisteredClaims Roles []string `json:"roles"` Scopes []string `json:"scopes"` TenantID string `json:"tid"` } RBAC enforcement then requires both dimensions: the principal must carry a role that permits the action, and the token's scope must match the resource context. Neither alone is sufficient. func Authorize(claims *ServiceClaims, action, resource string) error { if !rolePermits(claims.Roles, action) { return ErrRoleDenied } required := resource + ":" + action for _, s := range claims.Scopes { if s == required { return nil } } return ErrScopeDenied } This structure means a token with roles:["billing-admin"] but scopes:["payments:write"] cannot write to inventory, even if the role nominally has broad privileges. The scope claim acts as a capability fence that the issuer controls, not the service. The Edge Enforcement Architecture Pushing this logic into every microservice is the distributed equivalent of duplicating business logic across handlers. The correct architecture introduces an authorization boundary at the ingress layer combined with claim forwarding to downstream services. Client │ ▼ API Gateway / Edge Proxy ←── JWKS endpoint (cached, rotated) │ • Signature verification │ • aud enforcement │ • Token expiry │ • Rate limiting by sub/tid │ ▼ Internal Auth Sidecar (per service) │ • Scope + role check for this service's resource │ • Tenant isolation (tid claim) │ • Emit structured auth decision log │ ▼ Service Handler │ • Trusts forwarded identity headers │ • Does not re-parse JWT The edge proxy handles cryptographic validation once. The sidecar or middleware handles semantic authorization scoped to the service. Downstream handlers receive a validated identity context—not a raw token—which eliminates the class of bugs where a handler re-parses the token with different validation parameters. In Go, the sidecar pattern maps to an HTTP middleware chain that runs before the handler and attaches an AuthContext to the request context: type AuthContext struct { Sub string TenantID string Roles []string Scopes []string } func AuthMiddleware(expectedAud, requiredScope string, keyFunc jwt.Keyfunc) func(http.Handler) http.Handler { return func(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { raw := extractBearer(r) claims, err := ValidateToken(raw, expectedAud, requiredScope, keyFunc) if err != nil { http.Error(w, err.Error(), http.StatusUnauthorized) return } ctx := context.WithValue(r.Context(), authContextKey{}, toAuthContext(claims)) next.ServeHTTP(w, r.WithContext(ctx)) }) } } The requiredScope is injected at registration time per route, not per handler, which keeps authorization policy colocated with routing rather than scattered across handler logic. JWKS Caching and Key Rotation Failure Modes JWT validation in a high-throughput Go service cannot fetch the JWKS endpoint per request. A local cache with background refresh is standard, but the failure modes are non-obvious. Stale key on rotation: If the cache TTL is 60 minutes and the issuer rotates keys, the window between rotation and cache expiry produces invalid signature errors for tokens issued with the new key. The mitigation is a soft rotation protocol: the issuer publishes the new key alongside the old key for at least one cache TTL before retiring the old key. Services that check kid (key ID) in the JWKS response can also trigger a cache refresh on unknown kid without waiting for TTL expiry—with a circuit breaker to prevent stampede on forged kid values. JWKS endpoint unavailability: If the cache expires and the JWKS endpoint is down, the service must decide between fail-open (accepting tokens without re-validation) and fail-closed (rejecting all tokens). Fail-closed is correct for most authorization decisions. The operational consequence is that JWKS endpoint SLA must be higher than or equal to the services that depend on it—a dependency that is often invisible in runbooks. Claim Forwarding and Internal Trust Boundaries Service-to-service calls that originate from a validated external request must carry identity forward. A common mistake is re-issuing a new JWT for each hop using a service account token, losing the original principal's identity. This makes audit logs irreconcilable: the downstream service sees the service account, not the end user. The correct pattern forwards the original sub and tid claims as structured headers (X-Auth-Sub, X-Auth-Tenant) after validation at the edge, relying on the internal network boundary—mTLS or a service mesh—to prevent spoofing. The internal trust model is: the edge validates the external token; internal services trust the forwarded headers on the internal network because the network itself is authenticated via mTLS. Mixing these trust levels (accepting forwarded headers on a public endpoint, or requiring full JWT re-validation on every internal hop) is where most authorization architectures go wrong. Decision Framework Before deploying JWT-based RBAC across a microservice mesh, verify the following: Audience enforcement: Every service specifies its own aud value and passes required: true to the verification call. No exceptions. Scope granularity: Scopes are resource-scoped (resource:action), not generic (write). Token issuance limits scopes to what the requesting client legitimately needs. Role-scope conjunction: Authorization requires both a permitted role and a matching scope. Role-only checks allow scope inflation; scope-only checks cannot express principal hierarchy. JWKS cache contract: Cache TTL, key overlap window during rotation, and unknown-kid refresh behavior are explicitly defined and tested under simulated rotation. Claim forwarding protocol: Internal service-to-service calls forward original principal identity via headers on an mTLS-authenticated internal network. Service accounts are not used as proxies for external user identity. Audit log structure: Auth decisions—both allow and deny—are logged with sub, tid, aud, scopes, and the specific action/resource pair. Signature verification errors are logged at error level and monitored for spikes that indicate key rotation issues or replay attempts. The cryptographic correctness of JWT is a floor, not a ceiling. The authorization architecture that sits on top of it is where privilege boundaries actually hold or collapse.