Saltar al contenido
uencoder

Usar JWT con RSA signatures (RS256)

RS256 signs JWTs con RSA-SHA256, providing asymmetric verification donde solo el privado clave holder puede sign pero anyone con el público clave puede verificar.

  1. 1

    JWT supports multiple signature algorithms. RS256 (RSA-SHA256) is asymmetric: the authorization server signs with a private key, and any service can verify with the public key. This is preferable to HS256 (HMAC) in distributed systems where sharing a symmetric key is impractical.

  2. 2
    Codificador de JWT →

    Create a JWT with RS256. Set the header alg to "RS256", include claims (sub, exp, iat, iss, aud), and sign with the RSA private key. The public key is distributed via JWKS (JSON Web Key Set).

  3. 3
    Decodificador de JWT →

    Decodificar and verify the JWT. Verify the RS256 signature using the public key from the JWKS endpoint. Check claims: exp (not expired), aud (correct audience), iss (trusted issuer). Never skip signature verification.

  4. 4

    Use the JWT inspection workflow to decode the header and payload, verify the signature, and check all claims in one step.

  5. 5

    Key management: publish the public key at a well-known JWKS URL (e.g., /.well-known/jwks.json). Rotate the signing key periodically — include a kid (key ID) in the JWT header so verifiers know which key to use. Support a grace period with both old and new keys during rotation.

Preguntas frecuentes

RS256 vs HS256 — which to use?
Use RS256 when multiple services need to verify tokens without sharing a secret. Use HS256 only in a single-server or tightly coupled system where sharing a symmetric key is feasible. RS256 is the default for OAuth2/OIDC.
How do I handle key rotation?
Use the kid (key ID) header parameter. During rotation, publish both old and new keys in JWKS. Tokens signed with the old key remain valid until they expire. After all old tokens expire, remove the old key from JWKS.

Flujos que resuelven esta tarea

Herramientas relacionadas