How to add Authorization header to every request with JWT that's stored client-side?
Answered
Magnificent Hummingbird posted this in #help-forum
Magnificent HummingbirdOP
I want to transition to the app router, but I'm stuck with a python backend. When you authenticate, it gives you a http-only cookie with a refresh token and a short-lived JWT access token in the body.
Currently, the access token is stored in memory on the client-side. When the access token expires, you call the /refresh endpoint, it checks the cookie for a refresh token, and gives you a new access token.
This doesn't play so well with the auth router. I need a way to add the access token (which is stored client-side) to every request I make to the next server. That way, when I call my python API from server components, I could then include the authorization header.
My first idea was to use next.js middleware, but its run entirely on the server, so it doesn't have access to any client-side data.
I could use the refresh token to fetch a new access token for each request on the server before calling my python APIs, but that would be very wasteful imo and defeat the purpose of JWTs.
Anyone have any ideas as to what I should do? Thanks a lot in advance
Currently, the access token is stored in memory on the client-side. When the access token expires, you call the /refresh endpoint, it checks the cookie for a refresh token, and gives you a new access token.
This doesn't play so well with the auth router. I need a way to add the access token (which is stored client-side) to every request I make to the next server. That way, when I call my python API from server components, I could then include the authorization header.
My first idea was to use next.js middleware, but its run entirely on the server, so it doesn't have access to any client-side data.
I could use the refresh token to fetch a new access token for each request on the server before calling my python APIs, but that would be very wasteful imo and defeat the purpose of JWTs.
Anyone have any ideas as to what I should do? Thanks a lot in advance
25 Replies
then it's supposed to read the cookie
not expecting an Authorization header
otherwise the backend is inconsistent with itself
Magnificent HummingbirdOP
the http cookie is for the refresh token. the access token is always in the body of the response when you authenticate
Magnificent HummingbirdOP
but you're then supposed to include that access token as an Authorization header
you can put it in a JS cookie yourself then
Answer
instead of say localStorage etc.
the backend would make your life easier by storing both the JWT and the refresh token in a cookie
which btw the only way to secure the pages of your app if you ever want a private page (not just private API, whole page, eg to secure statically rendered content)
anyway I think in your case the simplest is to store in cookies directly yourself
Magnificent HummingbirdOP
indeed. I haven't thought of that, great idea. thanks for the reply and the link, i'll check it out!
are there any security ramifications i wonder? imo there is some benefit to having the access token only stored in the app's memory
was going to say that ^^
if you change the server to use HTTP only token, check CSRF
basically you need to be careful that attackers can't force your users to send their cookies to a malicious backend
Magnificent HummingbirdOP
even if the cookies are set to SameSite: Lax?
if you stick to a client cookie, you need to protect yourself against script injections
I haven't setup CSRF myself yet sorry I don't know more than that
Magnificent HummingbirdOP
yeah, afaik you're not vulnerably to CSRF attacks like images with src="/me/delete" if you use SameSite: Lax. anyway, thanks again for all the help!
If you mark the solution I gain Internet point ðŸ™
Magnificent HummingbirdOP
oh right, was about to, for sure. have a great evening!
New to app router and also working through this. Initial solution with authjs is a bit heavy handed for me, so if you have a good example to point to for your middleware etc... I would love to see it 😄
(our backend works exactly the same)