Production ready?

[koufopoulosf]

Hello,

I am making this issue to ask a few questions related to PasetoV4:

1. Is PasetoV4 is production ready? Has anyone had issues with it in a production environment?

and a bit more technical questions,

2. What is the best (most preferred) way to generate assymetric key pairs in hex for PasetoV4 tokens (for production use) ?

and last,

3. If I understood correctly, using the above way to generate our keys one time, we add to our environment file these hex key pairs:

   PublicAccessToken
   SecretAccessToken

   as well as:

   PublicRefreshToken
   SecretRefreshToken

   and use them for generating every other access and refresh tokens, right?

Thank you once again for your valuable time and I would really appreciate your reply.

Best Regards,

Filippos

[koufopoulosf]

@aidantwoods I would really appreciate your feedback on this one🙏

[aidantwoods]

Hey! 👋

1. Yes, it's production ready. I haven't had any reports of library issues manifesting in production, nor experienced any myself.
2. There are some constructor methods you could use if you want to generate keypairs with the library (create a new secret key, and the public one can be exported from it). Alternatively, you can generate a seed using 32 bytes from a CSPRNG and use that to construct the secret key. Or you can generate a Ed25519 keypair using a method of your choosing, obtain the byte or hex representations of the secret and public keys to be imported. Note that depending on your use case, you may want to use domain separation between keys which will be used for different purposes (or by different subsets of users), so you might want more than one keypair depending on what you're doing.
3. The keys themselves would not be tokens, but having a different set of keys for minting access tokens and refresh tokens does look sensible to me. The secret key would be all you need when creating new PASETOs, and the public key would be all you need to verify new PASETOs. If both those operations are done by the same service, that service would need both values. If the create and verify operations will be done by different services, each service would only need the key corresponding to creating/verifying PASETOs (secret/public value). Note that if you're creating and verifying tokens using the same service (with no need to verify the tokens outside that service) you could opt to use the local mode (which uses a symmetric key to both create and verify).