chore: implement unjwt
internally
#400
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
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 therefresh_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 therefresh_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.