Skip to content

chore: implement unjwt internally #400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

sandros94
Copy link
Contributor

proposed privately on discord: the aim of this PR is to replace any dependency that would manage JWTs with a unified one unjwt.

Currently I wasn't able to test the Apple OAuth login because I don't have an active developer program subscription. Thus, I based my changes solely on offical API documentation and JWT Standards.

Naming

In the following description I'll use primarely two types of JWTs

  • JWS (JSON Web Signature, RFC7515): Information is readable and verifiable by anyone, but signed only by authorities (usually server side).
  • JWE: (JSON Web Encryption, RFC7516): Information is fully encrypted, leaving only authorities (usually server side) the ability to both read and write it.
  • JWK: (JSON Web Key, RFC7517): a JSON serialized cryptography key to perform various actions on the above JWTs

Notes

a few notes and concerns to keep in mind with the current implementation and examples for JWT within nuxt-auth-utils (which I haven't changed, since I only replaced the internal signing and verifing processes)

Session Size

This mainly focuses on the demo part in the playground.
Both access and refresh tokens are stored within h3's session token. Currently they are both based on a HS256 algorithm, which is a symmetric key and produces a decently small sign segment (the last string after the last . in a signed JWS). Depending on the algorithm used this could easily eat up the vast majority of cookie size.

A more traditional implementation would have them on separate cookies/headers, with dedicated JWKs each.

For example access_token would be a short-lived JWS (either in authorization header or dedicated cookie); while the refresh_token would be a long-lived JWE http-only cookie (similar to how h3 session works, but based on JWT standard).
For the related keys the access_token woudl typically use an asymmetric key (eg: RS256), making the public key publickly accessible; while the refresh_token could remain on a password-based key derivation (again, similar to the current h3 implementation, but based on JWT standard).

Security

Considering that any current implementation and use of JWTs are subject to the current h3 implementation.
This means that session decryption must always be performed first to access required information for JWTs to then perform JWS elaborations. The JWK used for these elaborations, during the Apple auth handler, are generated by Apple itself (the private key is manually copied by developers into the env vars). Any sort of alteration/corruption will result in a failure during their import. Currently Apple uses only RS256 keys which are the simplest RSA (asymmetric) form available, most JWT implementations (unjwt included) pass them directly to the WebCrypto API.

Copy link

pkg-pr-new bot commented May 11, 2025

Open in StackBlitz

npm i https://pkg.pr.new/atinux/nuxt-auth-utils@400

commit: efc3f48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant