i know, it's not optimal, but it would simplify verification for systems, that already support jwt verification

The JWT signing keys are managed by supertokens itself: - A public / private key is generated and stored in the db. The public key is used to verify - The keys are changed on a regular basis for improved security. So at the moment, you can't set on global key unfortunately.

mh ok

But if we were to add this feature, how would that work?

i'd expect you'd be able to pass the token as an env var

or docker secret

*key

A public private key you mean?

hopefully a private private key 😄

what do you mean by private private key?

So the signing algo is RSA256

yeah so then you'd pass the private rsa key

which means a private key is used to sign the token, and a public key is used to verify the token

yeah

So you would have to pass a private and a public key

you can derive the pub key from the private key

Actually, there is a way to do this now

One min

there is?

that'd be great

So it is a little cumbersome, but you can do the following: - Switch off JWT signing key rotation: https://supertokens.io/docs/session/common-customizations/sessions/jwt-signing-key-rotation (set

ACCESS_TOKEN_SIGNING_KEY_DYNAMIC

to

false

) - Go to the database >

key_value

table > change the value of

"access_token_signing_key"

to ;. For example, if the public key is "pubkey" and private key is "prikey", then the value in the db should be "pubkey;prikey". The way we generate public and private keys can be seen here: https://github.com/supertokens/supertokens-core/blob/master/src/main/java/io/supertokens/utils/Utils.java#L189

Note that this will enable you to set a global public key to verify the access token from the user. However, the access token's (not the same as an ID token) payload is not that of a standard JWT, so it also depends on what you want to do with the access token once it's signature is verified

ah it's not?

what does the payload look like?

would be great if it would contain the userId

what format is

<public key>;<private key>

pem? JWK?

The payload we have has the following: - `sessionHandle`: A constant ID per session. -

userId

- `refreshTokenHash1`: a reference to this token's refresh token - `parentRefreshTokenHash1`: a reference to the refresh token that was used to create this access token. - `userData`: Any JSON object that you wish to provide - `antiCsrfToken`: used to check if the incoming anti-csrf token is valid or not - `expiryTime`: in Milliseconds - `timeCreated`: in Milliseconds - `lmrt`: Used to check when the user had last manually authenticated

well that's totally fine

userData could contain roles or what not. Should be enough to do authorization based on the payload