getClaims and token refresh
I was wondering if getClaims refresh the access token if it is about to expire?
I've read that in the doc but was not so sure, should I use getUser in the backend to make sure the user does exist in my database at the place of getClaims?
The middleware for next js does getUser, which is not that great since it makes thing slow, i should just verify getSession, but how will the refresh token but updated, etc?
13 Replies
Extracts the JWT claims present in the access token by first verifying the JWT against the server's JSON Web Key Set endpoint /.well-known/jwks.json which is often cached, resulting in significantly faster responses. Prefer this method over #getUser which always sends a request to the Auth server for each JWT.
If the project is not using an asymmetric JWT signing key (like ECC or RSA) it always sends a request to the Auth server (similar to #getUser) to verify the JWT.
Parses the user's access token as a JSON Web Token (JWT) and returns its components if valid and not expired.
If your project is using asymmetric JWT signing keys, then the verification is done locally usually without a network request using the WebCrypto API.
A network request is sent to your project's JWT signing key discovery endpoint https://project-id.supabase.co/auth/v1/.well-known/jwks.json, which is cached locally. If your environment is ephemeral, such as a Lambda function that is destroyed after every request, a network request will be sent for each new invocation. Supabase provides a network-edge cache providing fast responses for these situations.
If the user's access token is about to expire when calling this function, the user's session will first be refreshed before validating the JWT.
If your project is using a symmetric secret to sign the JWT, it always sends a request similar to getUser() to validate the JWT at the server before returning the decoded token. This is also used if the WebCrypto API is not available in the environment. Make sure you polyfill it in such situations.
The returned claims can be customized per project using the Custom Access Token Hook.
This is indeed right if we use it on the server for next js and client side too?
I use asymetric key
Yes. It calls getSession() if you don't provide the jwt as a parameter. getSession will refresh the session if needed.
meanwhile verifying if the token is issued from supabase too compare to just getSession which could be a fake token?
What would you recommend?
Using getClaims in middleware for protected route and in the api handler - server action getUser to make sure user does indeed exist?
The getClaims will verify where issued, if expired or about to expires it calls getSession which than refresh the access token but if the user no longer exist it still refresh the access token what happens?
I need a solution to make sure my backend is secure and reliable
getClaims will only call the server if the session is expiring. getUser calls it everytime. getClaims only checks the JWT is valid if the session is good in memory.
So for instance if you care if the user is banned, deleted or signed out elsewhere getClaims won't know that unless the session was expiring until the session does reach expire point.
meaning until the access token is expired, it will try to refresh with the refresh token and wont work basically?
I don't understand.
Also getClaims will only call if session is EXPIRING or also EXPIRED?
Normally getClaims just uses the current session info to get the JWT and confirms it and gives you the claims.
sorry, what I mean is that if the user is delete we do getClaims it will work if the access token is not expired, once expired, it will try to refresh the access token, it won't work, it will try to refresh and supabase will say this refresh token no longer valid?
Yes
but when expired or about to, it does refresh it?
Yes.
@garyaustin Thank you so much for your time!
I really appreciate it, hope you have a good night
This issue is now solved.