JWT-Based Access Tokens in Salesforce: A Complete Guide
Summary
Salesforce has introduced JWT-Based Access Tokens that replace traditional opaque OAuth tokens with self-contained, signed JWTs compliant with RFC 9068. These tokens include useful claims like expiration, audience, and scopes, making validation easier and eliminating server-side lookups in many cases. Developers can improve integrations by proactively refreshing tokens, validating signatures via standard OpenID discovery, and leveraging simplified routing through a global endpoint. While REST APIs fully support JWT tokens, some SOAP API quirks remain. Understanding these changes helps build more secure and modern Salesforce integrations.
Takeaways
- Enable JWT-based access tokens in External Client App OAuth settings for improved security.
- Use Salesforce's OpenID Connect Discovery endpoint to validate JWT signatures with JWKS.
- Expect fixed expiration in JWT tokens, requiring proactive refresh without sliding window.
- Update error handling for JWT-specific REST API responses like INVALID_JWT_FORMAT.
- Leverage JWT tokens to bridge API sessions into browser UI sessions via Frontdoor URLs.
Learn how Salesforce’s new JWT-Based Access Tokens differ from traditional opaque OAuth tokens, how they align with RFC 7519 and RFC 9068, what claims they contain, and what the changes mean for developers building secure integrations. Anyone who has worked with the Salesforce Hosted MCP Servers or the Agentforce API will have set up an External Client App. During the setup process there is a small but significant step that tells you to enable the “ Issue JSON Web Token (JWT)-based access tokens for named users ” setting. In this article we’re going to deep dive into what this actually means. The basics of OAuth 2.0 are simple: There is a client-server type setup where the client runs an authorisation / authentication flow to request access to a resource server.