A Logical Hurdle Relating to JWT Signing

I’ve worked with JWT but suddenly I’m stuck in this logical wall

Since https://YOUR_DOMAIN/.well-known/jwks.json is public, anyone that can guess your domain could theoretically get to it (e.g. through the Auth0 sign in page that doesn’t have custom domain).

Wouldn’t that person have access to the signing key, then can proceed to create a fake JWT?

@dan.woda

Hi @bryan.li,

I imagine others have had this same question. Thanks for moving this to a public topic. :grinning_face_with_smiling_eyes:

The keys available from the /.well-known/jwks.json endpoint are the public keys for your tenant. This endpoint is standardized as part of the OAuth 2.0 framework.

If you are using an asymmetric signing algo like RS256, JWT tokens are signed with a private key (secret to the auth server) and applications consuming the tokens can verify the signature with a public key (available via the endpoint).

Applications consuming the tokens can use the /.well-known/jwks.json endpoint to dynamically request the public key that corresponds to the private key currently in use. This allows your application to always have access to an up-to-date public key, among other things.

If you want to dig in deeper, this blog post helps to demystify RS256 and JWKS:

Hope that clears things up!

1 Like

Thanks, problem solved… it’s the asymmetric signing that threw me off because I kept thinking I need to have a secret key in the env to properly decode the JWT.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.