When an application receives a token, it needs to answer a basic question: Can I trust this? The app must know whether the token came from the expected issuer and whether anyone changed it after it was issued.

RSA keys help make that possible. Rivest-Shamir-Adleman (RSA) is a public-key cryptography algorithm that uses a pair of related keys: one private and one public. In token-based systems, the issuer can sign a token with a private key, and applications can verify that signature with a public key.

For developers and platform teams building customer-facing applications, token signature verification helps APIs trust identity data without sharing signing secrets across every service. This article explains what is an RSA key, how public and private keys work together, what a JSON Web Key Set endpoint does, and why token signatures matter for secure application architecture.

• What is an RSA key: A cryptographic key used in an asymmetric public/private key pair
• Private keys must stay protected because they can sign trusted data
• Public keys can be shared so applications can verify signatures
• JSON Web Key Set endpoints publish public keys that applications use to verify signed tokens
• Auth0 Token Signatures help applications verify that tokens were issued by a trusted identity provider
• Correct token signature verification helps protect customer trust across APIs and distributed services

An RSA key is a cryptographic key used with the RSA algorithm. RSA uses asymmetric cryptography, which means the system uses a pair of mathematically related keys instead of one shared secret.

The key pair includes:

• A private key that must remain secret
• A public key that can be shared

In identity systems, RSA keys are often used to sign and verify JSON Web Tokens (JWTs). The identity provider signs a token with the private key. The application verifies that token with the corresponding public key.

Public and private keys have different jobs.

The private key is controlled by the issuer. It should never be exposed to applications, users, or public repositories. If an attacker gets the private key, they may be able to sign data that appears trusted.

The public key is distributed to systems that need to verify signatures. It does not need to remain secret. Applications use it to confirm that signed data came from the holder of the private key.

This model helps avoid sharing one secret across every app and API. Instead, the issuer protects the private key, and other systems use public keys for verification.

Token signing helps applications detect tampering and verify trust.

A typical signing flow looks like this:

• An identity provider creates a token
• The provider signs the token with its private key
• The application receives the token
• The application retrieves the matching public key
• The application verifies the signature
• The application checks issuer, audience, expiration, and other claims
• The application accepts or rejects the token

If the token changes after it is signed, signature verification should fail. If the token was signed by an unknown key, verification should fail. This is why correct validation matters as much as the signing process itself.

A JSON Web Key Set (JWKS) endpoint publishes public keys in a standard format. Applications use the JWKS endpoint to retrieve the keys needed to verify signed JSON web tokens (JWTs).

A JWKS endpoint is especially useful because signing keys may rotate. Instead of hardcoding a key forever, applications can fetch current public keys and use the key ID in the token header to choose the right key.

This helps support:

• Token signature verification
• Key rotation
• Multiple active signing keys
• Standardized public key distribution
• Safer validation across applications and APIs

Developers should use reliable JWT libraries that can retrieve, cache, and refresh JWKS data safely.

RSA keys show up in several application security workflows, especially when systems need trust without sharing the same secret everywhere.

Use case	How RSA keys help	Why platform teams care
JWT verification	Applications verify that signed tokens came from the expected issuer	APIs can reject forged or tampered tokens
Signing key rotation	Public keys can be updated through a JWKS endpoint without sharing private keys	Teams can rotate keys with less application disruption
Distributed API validation	Multiple APIs can verify tokens using public keys	Microservices can validate identity context consistently
Tamper detection	Signature verification fails if signed data changes	Applications can avoid trusting modified token claims
Trust separation	The issuer protects the private key while applications use public keys	Teams avoid sharing signing secrets across every service

For developers, the practical takeaway is simple: don’t just decode tokens. Verify them with the right key and validation rules.

RSA key pairs are different from symmetric shared secrets. In symmetric cryptography, the same secret is used to sign and verify. In asymmetric cryptography, the private key signs and the public key verifies.

Comparison point	RSA key pair	Shared secret
Key model	Uses separate private and public keys	Uses the same secret for signing and verification
Verification	Public key can verify signatures	Verifier must know the shared secret
Distribution	Public key can be widely shared	Secret must be tightly protected everywhere it is used
Common token algorithm family	RS256 and related asymmetric algorithms	HS256 and related symmetric algorithms
Operational fit	Good for distributed verification	Useful for simpler trusted-server scenarios

For many API ecosystems, asymmetric signing is useful because multiple services can verify tokens without all sharing a signing secret.

RSA keys are security-critical. Treat them as part of your identity infrastructure.

Best practice	Why it matters
Protect private keys	Private keys can sign trusted data and must remain secret
Use trusted libraries	Custom cryptography code is easy to get wrong
Validate algorithms	Applications should reject unexpected or insecure algorithms
Check issuer and audience	A valid signature alone is not enough
Support key rotation	Signing keys should be replaceable without breaking validation
Cache JWKS safely	Balance performance with key freshness
Monitor verification failures	Failures may indicate misconfiguration or attack attempts

Developers should not treat token verification as a one-line decode step. A decoded token is not the same as a validated token.

Auth0 Token Signatures help applications verify that tokens were issued by Auth0 and were not forged or altered. Auth0 publishes public signing keys through a JWKS endpoint so applications and APIs can validate token signatures using trusted keys.

For enterprise and API-driven teams, that supports a more consistent trust model across distributed applications and customer-facing services.

If your team is building token validation into apps and APIs, contact Auth0 to discuss how Auth0 can support secure identity architecture.

What is an RSA key pair?

An RSA key pair includes a private key and a public key. The private key signs or decrypts data, while the public key verifies signatures or encrypts data, depending on the use case.

How do public and private keys work together to sign data?

The issuer signs data with the private key. Other systems use the public key to verify that the signature is valid and that the data has not changed.

How do I set up a JWKS endpoint to get public keys to verify tokens?

Use the JWKS endpoint provided by your identity provider. Configure your application or API to retrieve public keys, cache them safely, and select the correct key based on the token’s key ID.

Why does token signature verification matter?

Signature verification helps confirm that a token came from a trusted issuer and was not modified. Without verification, an application may trust forged or tampered data.

Using a service like Auth0 can simplify the implementation of both authentication and authorization, allowing developers to concentrate on their core application logic. Explore our Intro to IAM series for additional topics related to identity and access management.

Learn more

These materials are intended for general informational purposes only. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors and should not rely solely on the information provided herein.

• JSON Web Tokens
• Token-Based Authentication Made Easy
• Access Tokens