Exactly!

If you find it ,let me know

Exactly my question. If not storing something to identify the user by, how does the server know it's the same user to use the refresh token for?

Ah, http-only cookies are actually stored locally with a set Cookie. The only thing is that they are not accessible through scripts but on subsequent http requests

I handle it this way. You see, if you're using jwt, you encode user data (e.g: email, roles) to it by passing it as a jwt payload when generating a new token. Same thing with refresh token. The only thing is you store refresh token in database in your user entity before setting it in request cookies. Then when handling the refresh route, you extract refresh token from the cookies and first find a user in the database who has the same refresh token, then you decode it, which will allow you to extract encrypted data(as I said before: email, roles). If the user from the database (one you found via refresh token) shares the same email and roles then it is the same person sending a request for a new access token so you generate new one for him and send it, otherwise you throw an error with 403 status code

I think this is what’s missing in the video. I'm not a backend developer, and I noticed there was no code to save the HTTP-only cookie, so I was left wondering, "What magic is happening here?" I did some further research and I think I understand it now. However, a detailed backend explanation would be very useful so we know exactly what's going on. In the process described, two tokens are created: a refresh token and an access token. The refresh token is sent in an HTTP-only cookie as a header, while the access token is included in the response of the request. The browser automatically saves the cookie when the backend sends it as an HTTP-only cookie, provided that CORS (Cross-Origin Resource Sharing) is properly configured on both the frontend and backend (with credentials allowed). This ensures the cookie is saved and shared with every request. Therefore, if we don't have an access token when a refresh is needed, the refresh token, which exists as a cookie in the browser, will be sent to obtain a new access token. Maybe it was just me who didn’t fully grasp the concept initially and it was obvious from the start, but asking the question and getting answers helped point me in the right direction. Initially I though the HTTP-only cookie existed only in the server which lead me to misunderstandings.

@@HeinerAngarita Hi, if you need a detailed backend code for handling user authentication and authorization, I can provide you with a link to my github repo. I used express js with typescript, prisma, and postgres for the db. And, if you need one for non-relational db such as MongoDb, I have a second repo for that as well. They're nealy identical in terms of handling the business logic, only difference is the way I query the database

Hey, for this case i think you would have to bypass the authorization for those particular API's , typically they will be get only api to give you the info to render it on the UI, and all other backend routes will be going through the authorization so they will be protected.

hi did you find any thing yet ?

@shubhamchandel-gs4so Same question

No, and if you want to presist login even when dom tree wont exists (closing browser etc) you must use cookies or local storage. I suggest using cookies.

Why not local storage? - if someone can login to your local machine to extract the JWT then you have bigger problems. Because the JWT is encoded, if its manipulated then the server will reject it.

@@markbarton There's a security concern where, if you use any external scripts, someone could compromise one of those and load malicious code onto your website that first just sends all local storage to an external source before loading the actual script. I think this could also be done with something like a browser extension, but I'm not sure about that. Since I don't think JWTs can be revoked, that's a big problem.

@@ptolemyhenson6838 Ok thats good to know - not using external scripts is good practice anyway but its good to understand the attack vectors and would make sense why you would use http cookies - thanks

@@ptolemyhenson6838 the reason why refresh token is supposed to be stored in database is for revocation use. JWT token is supposed to be stateless, stateless means you don't have to store userinfo or something in the backend to verify it later with those stored infos. When you store jwt tokens in the backend it is not stateless anymore.

I have the same question! Everywhere I look I see the same explanation but not a direct answer! If it’s in memory it should mean that refreshing the page will lead to losing the access token lol how are we supposed to keep the user logged in??? 😢

@@MarlonEnglemam Honestly, I was noticing the same thing. Of course memory will be 'safer' but I don't believe he designed this video with user-experience in mind. From my experience, saving a token to an HTTP-only cookie is safe as well. If you are worried about a token being 'leaked' then I would consider using another method of authentication/authorization simply because in order to save the token to memory, the token would have to be readable and therefore sent from the server which makes it just as prone to being leaked as if you save it in an HTTP-only cookie.

why will we refresh the page ? simply when token is expired that will be notify to react app from server than instantly we hit refresh token api sending our expired token as payload , then in refresh token api : we will check that token received from payload is expired (firstly) than we will also check the data in it (email, id) in database or match with refresh token (it will be same ) if it matches then we will simply generate the new token for the user whom we got the payload (email, id etc..) and then send to react app , in react app it will again set state.

@@baasirashraf8291 When you even switch tabs away from a React app and then come back later, it will still refresh itself so the 'refreshes' will happen a lot more often than one would think. What you are explaining is the typical auth workflow where the token is stored in a persisted way (cookies, localstorage etc.). What the author is explaining is to store the token in memory (which is not persisted through any form of refresh whatsoever - think of useState and trying to toggle it to a different state and then refresh to see it go back to its default state). When a token is stored in memory, it is deleted as soon as the app refreshes and with the token being deleted you have no way of 'sending' any credentials whatsoever to even 'refresh' your session. Yes this is more secure as it is harder to locate the token but it is also a bad user experience. Its not a knock on the author but it really should be clarified that sessions in this design will not persist. Memory is very secure but there is a reason a LOT of apps opt for HTTP-only cookies over memory.

Yes

@@Priva_C so it isn't feasible to store and retrieve token in memory as refreshing the page will reset the state/variable

No, it is just gonna load and get the access token and start using it normally, user won't notice anything

@@hazemkhaled9416 As much its "secure" don't we have any other more convenient way?

@@hazemkhaled9416 what I thought.

I did that in my application

I handle it this way. You see, if you're using jwt, you encode user data (e.g: email, roles) to it by passing it as a jwt payload when generating a new token. Same thing with refresh token. The only thing is you store refresh token in database in your user entity before setting it in request cookies. Then when handling the refresh route, you extract refresh token from the cookies and first find a user in the database who has the same refresh token, then you decode it, which will allow you to extract encrypted data(as I said before: email, roles). If the user from the database (one you found via refresh token) shares the same email and roles then it is the same person sending a request for a new access token so you generate new one for him and send it, otherwise you throw an error with 403 status code

We don't create access token using refresh token, we generate new access token if refresh token is still not expired that's why refresh token is there.

agree

I was about to comment the same concern. When user refreshes the Application, the token state becomes undefined. In that case how will the server know if its a valid user without the token or credentials ?

@@SaifullahZubair I found the answer. Refresh token should be stored as "http only". This is the common approach afaik and you can access the token on the server securely without losing it on refresh.

@@SaifullahZubair I found the solution. The refresh token should be stored as 'http only'. With this common way, the server can access the token securely.

+

Yes in that example it’s redundant. I guess you would only need it when you pass any user information on the client in that token. For example current UserId

you need to know if the user is logged in without having to fetch it constantly. For like displaying a manage account button, sign out, etc. or even for sending it with the request on button click

@@cosdensolutions ok, this sounds valid, but still I need to fetch every 15 minutes to check token, it will equally work with refresh token

​@@PiotrMarkiewicz i believe this method is called an asynchronous token. the key point is to make accesstoken maxage as little as possible and refreshtoken maxage long enough for the user to login to our app. the only reason i guess is security purpose.

that's what comes to my mind too, on page refresh the states or variable will be gone

Unless you keep sending refresh token request to backend before state is destroyed

@@deekandau4596 what dom EVENT to use to do that?

same question here

Don't ask. He's trying to charge for that source code snippet now

That's project React 😁

@@cosdensolutions yes, real world React projects with jwt access and refresh tokens please thank you

Heyy! Try zustand tho 🎉 it's easier and have less boilerplate

it gets sent but the browser doesn't allow javascript to access it, only the server

Exactly. Therefore what you say in the video about that is confusing.

only redux, not the persist part

Redux persist uses local storage under the hood if I’m not mistaken (so does zustand btw)