Token Decoder Tools — JWT, PASETO, SAML & OIDC

Opaque tokens are random strings validated via server-side lookup in a database or cache.

Use them when:

• Tokens must be revocable instantly
• You need minimal client-side information
• Regulatory requirements forbid embedding claims in tokens

JWTs are self-contained with embedded claims and stateless by design. Use them when you need offline verification, cross-service trust, or reduced backend latency.

Keep in mind that JWTs cannot be easily revoked without additional infrastructure like blocklists or short expiry times.

For HS256, you use your shared secret to compute HMAC-SHA256 of header.payload and compare it with the signature.

For RS256 or ES256, you fetch the public key from the JWK Set (jwks_uri) and verify the signature using the appropriate algorithm.

BetterPass's JWT tool supports HS256 verification. For RS256, use the OIDC ID Token tool and paste the public key (JWK) from the provider's JWKS endpoint.

A SAML assertion is an XML document that contains authentication and authorization statements. It's typically Base64-encoded and sometimes DEFLATE-compressed.

To decode one, you Base64-decode it, check if it's compressed and inflate it if so, then parse the XML.

BetterPass's SAML tool handles both encoding layers automatically and presents the structured XML for inspection.

An ID Token is a JWT that contains user identity claims like sub, name, and email. Your client application uses it to authenticate the user.

An Access Token (opaque or JWT) authorizes access to a resource server or API. Your client presents it to the API, while the ID Token is verified locally.

OIDC requires ID Token signature verification using RS256 and JWKS.

Token introspection (RFC 7662) is an OAuth 2.0 endpoint. It lets your resource server ask the authorization server whether an access token is still valid and what scopes or claims it carries.

Use it when your tokens are opaque (not self-contained like JWTs), when you need real-time revocation checks, or when your resource server cannot validate the token locally.

The tradeoff is that every request requires a network call to the auth server, adding latency. For stateless verification, prefer JWTs with local signature verification.

Currently the JWT tool supports HS256 (symmetric) signing only.

For RS256 or ES256, you need a private key — and that should never enter a browser context. Use a backend service or CLI tool like openssl or jwt-cli for asymmetric signing.

The BetterPass JWT tool is designed for decoding, inspection, and symmetric verification only.

In the OAuth 2.0 refresh token flow, you use a long-lived refresh token to obtain short-lived access tokens without re-authentication. Store the refresh token in an httpOnly cookie or server-side.

Follow these best practices:

• Rotate tokens on every use
• Set 7–30 day expiry for refresh tokens and 5–15 minutes for access tokens
• Detect token theft using allowlists with device fingerprints
• Revoke all tokens on password change or suspicious activity

For SPAs, use the Backend for Frontend (BFF) pattern to keep refresh tokens server-side.

JWTs are stateless, client-side tokens with embedded claims. They scale horizontally without server storage, but you can't easily revoke them and they're vulnerable to XSS in localStorage.

Session cookies store a random ID in an httpOnly, Secure, SameSite cookie with data on the server (Redis or database). They're trivially revocable but require server-side storage and add latency.

Use JWTs for microservices, mobile apps, and cross-service trust. Use session cookies for traditional web apps where revocation matters and your XSS surface is larger.

Try our JWT tool to decode and verify tokens.

Choose OpenID Connect (OIDC) for new projects. It's built on OAuth 2.0, uses JSON instead of XML for simpler parsing and smaller payloads, supports mobile and SPA authentication flows natively, and has broader library support.

SAML 2.0 is only needed for legacy enterprise federation — think ADFS, older Okta, or government systems that require XML signatures and encrypted assertions.

OIDC's JWKS verification, /userinfo endpoint, and openid-configuration metadata make it far simpler to implement.

Try our SAML decoder and OIDC tool to inspect tokens from either protocol.