RS256 (RSA-SHA256)

How It Works

RS256 follows the same JWT compact serialization as HS256—a Base64URL header and payload joined by a dot—but the third segment is an RSA signature rather than an HMAC digest. The signer loads an RSA private key (typically PKCS#8 PEM), computes RSASSA-PKCS1-v1_5 over the SHA-256 hash of the signing input, and Base64URL-encodes the result. Verifiers parse the header, confirm alg is RS256, retrieve the matching public key (from disk, JWKS, or cached kid lookup), and perform RSA signature validation over the same hash. RFC 7518 registers RS256; RFC 7517 defines JWK and JWKS formats for publishing rsa modulus and exponent fields plus optional kid for rotation. Include a kid header when operating multiple active keys so verifiers select the correct public key during rollover. Private keys must never ship to edge services, browsers, or mobile apps; only the issuer signs. Middleware should fetch JWKS periodically with cache TTL, honor key expiration policies, and still validate exp, iss, aud, and other claims after cryptographic verification succeeds. Generate initial 2048-bit pairs with OpenSSL or /tools/rsa-key-generator, store the private key in HSM or vault-backed storage, and expose the public side through your discovery endpoint.

When to Use

Adopt RS256 when microservices, partner APIs, or SaaS tenants verify tokens without access to signing material. It fits OAuth2 authorization servers, federated identity products, and architectures where a central auth cluster signs while dozens of stateless services only validate. Choose RS256 when security policy requires private keys to remain on a hardened issuer and public distribution through JWKS is acceptable.

When Not to Use

Skip RS256 for simple single-process apps where symmetric HS256 already meets threat models and operational overhead of key pairs feels unjustified. Avoid it on extremely constrained devices if RSA verify latency dominates unless you profile and accept the cost. Do not choose RS256 if your stack lacks mature JWT RSA support or if you cannot operate JWKS rotation—half-implemented asymmetric auth is worse than a well-managed shared secret.

Key Length Requirements

Use RSA moduli of at least 2048 bits for new deployments; this aligns with NIST SP 800-57 recommendations through 2030 for general-purpose signatures. High-value or long-lived identity providers often prefer 3072 or 4096 bits for additional margin, accepting larger signatures and slower operations. The JWT signature itself is roughly 256 bytes for 2048-bit RSA regardless of payload size. Export private keys as PKCS#8 PEM, public keys as SPKI PEM or JWK with kty RSA, n, and e fields. Publish verifiers via JWKS with kid and use values matching your rotation schedule. The rsa-key-generator tool 2048-bit preset produces starter key pairs; replace automated demo keys before production and protect private PEM with filesystem permissions or cloud KMS wrap.

Security Pitfalls

• Embedding RSA private keys in application repositories, Docker images, or client-side bundles where anyone with repo access can mint valid tokens.
• Verifying RS256 tokens with a private key file or accepting whatever algorithm appears in the header without pinning algorithms: ['RS256'].
• Publishing JWKS without kid headers while keeping multiple private keys active, causing verifiers to pick the wrong key and reject legitimate tokens—or accept forgeries after sloppy fallback logic.
• Skipping JWKS cache invalidation during emergency rotation, leaving services validating against stale public keys for hours after a compromise.
• Validating the RSA signature but ignoring issuer and audience claims, allowing tokens minted by a compromised staging issuer to access production APIs.

Code Examples

const fs = require('fs');
const jwt = require('jsonwebtoken');

const privateKey = fs.readFileSync('private.pem');
const publicKey = fs.readFileSync('public.pem');

const token = jwt.sign(
  { sub: 'user_123', scope: 'read:orders' },
  privateKey,
  {
    algorithm: 'RS256',
    keyid: '2026-01',
    expiresIn: '15m',
    issuer: 'https://auth.example.com',
  }
);

const payload = jwt.verify(token, publicKey, {
  algorithms: ['RS256'],
  issuer: 'https://auth.example.com',
});

console.log(payload.sub);

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.security.Keys;
import java.nio.file.Files;
import java.nio.file.Path;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import java.util.Base64;

PrivateKey privateKey = loadPrivateKey(Path.of("private.pem"));
PublicKey publicKey = loadPublicKey(Path.of("public.pem"));

String token = Jwts.builder()
    .subject("user_123")
    .issuer("https://auth.example.com")
    .signWith(privateKey, Jwts.SIG.RS256)
    .compact();

var claims = Jwts.parser()
    .verifyWith(publicKey)
    .requireIssuer("https://auth.example.com")
    .build()
    .parseSignedClaims(token)
    .getPayload();

Related Comparisons

Related Terms

Related Guides

Frequently Asked Questions