LEARN. PRACTICE. GROW.Concept and mechanism
A valid signature is only part of a JWT decision. The verifier needs to trust the issuer, validate the recipient, and apply contextual rules. If an IdP issues tokens for several applications, an API should not accept one intended for another merely because it recognizes the signature. Allowed algorithms belong to verifier policy rather than unrestricted received-header choice. URLs such as jku should not cause the server to fetch arbitrary destinations and trust sender-chosen keys. After token validation, authorization for object, tenant, and action remains necessary; an unpredictable identifier does not replace that control.
Guided application
In a fictional GitHub OIDC pipeline, limit audience and subject to the authorized repository and context. Confirm actual format: current documentation includes immutable IDs in subjects for new repositories or those configured accordingly. Do not copy an old template without checking. At release, relate component inventory and findings to the final artifact, including transitive dependencies. Signed provenance for another digest does not establish the deployed content’s origin. Resolve mismatch without editing evidence to make it fit. If a WAF blocks an unauthorized-access pattern, record it as a mitigation needing coverage validation while authorization remediation remains outstanding. Retests should include legitimate requests and cross-tenant denials.
A signed token for application B does not authorize API A or all its objects.
Common pitfalls
Signature as complete authorization; unrestricted jku; old subject format; WAF as universal fix; provenance for another digest.
Related topics: Architecture, responsibilities, and portability · Versions, retention, and holds · Data protection, location, and classification
Bind every decision to the correct identity, recipient, resource, and content.
Reference: JWT best current practices · CCSP examination outline effective 2026-08-01; January2026 V2 PDF