OAuth, JWT and gateways: separate security controls

Choose a role before a tool

An OAuth access token can be opaque or use JWT. Decoding a JWT does not verify authenticity; a signed JWT does not automatically encrypt its contents. A gateway does not replace business authorization inside services.

Validate the protocol and every access

• Choose a flow appropriate for the client. For user journeys, follow current authorization-code and PKCE recommendations, using a maintained library and strictly controlled redirects.
• For an accepted JWT, verify signature, allowed algorithms, issuer, audience and the profile’s time constraints. Reject tokens intended for a different use.
• Check access to every object, action and organization. Test cross-account access with fictional data; a broad role or scope is not always sufficient.

Plan expiration, revocation and incidents too

Document renewal, key rotation, secret loss and the revocation strategy. Local token verification does not automatically learn of remote revocation. Minimize token data and logs; neither JWT nor quotas alone guarantee security or compliance.

Primary references

• IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
• IETF RFC 8725 — JWT Best Current Practices [EN]
• OpenID Foundation — OpenID Connect Core 1.0 [EN]
• OWASP — Authorization Cheat Sheet [EN]

{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}