Finally a properly explained solution to this problem. Every other tutorial I have seen that mentions this is like: "Well JWT localStorage is unsafe" but proceeds to show a login method and saving the token in localStorage, or JWT Is Unsafe and the tutorial is all about why it's unsafe and doesn't explain how to prevent it properly. Thank You!
Good stuff and well explained. However, you mention at the end that you need to have frontend and backend on same domain to use cookies which is not necessarily correct in 2022 but requires additional steps. You can have backend on a separate domain and setup CORS (allowing headers like Access-Control-Allow-Origin and others) and ensure that the cookie is set as HttpOnly, Secure and the front end API calls are including withCredentials:true in the ajax calls. More steps but separate domains with cookies are possible
This is not related to CORS, the reason he said that is because browsers block third party cookies in incognito mode if they don’t belong to the same domain.
Thank you very much. I've stayed away from jwt for this exact reason where I could not find any proper solution of how to use my token safly. Desserves alot more views, because every tutorial on these uses local or session storage to do it. Thank you again!
This may help you with implementing this on a multi domain set up: stackoverflow.com/questions/47497296/node-js-authentication-in-cross-domain Personally, if you need to set up multi-domain auth, I'd look for an authentication provider instead.
confused. if you can still see the jwt token when you go through application. how does it make it any more secure than just storing it in a regular cookie? understood that when you use script; it would be not be.
It is secured in a way that you won't be vulnerable to xss attacks (httponly cookie) because it can't be access by the frontend. But this setup is still vulnerable to xsrf/csrf attacks.
@@markhermano1 No CSRF attacks happen when the browser does the authentication for you. In this setup, the cookie does nothing other than allow the back-end to validate the connection.
Sessions are better, if you can use sessions do that. Simulating sessions with JWT is a compromise you may have to take when using 3rd parties (Headless CMSs such as Strapi being the core of what I teach)
Hello, Thanks for the video. So if i am understanding correctly, we should store the jwt in header cookies and send requests everytime to backend and fetch the required data correct. Do we need store the token in front end too or we can just decript the jwt to read the data? I have not yet gone over how to decrypt the jwt in web api thanks
I don't know how strapi middlewares looked at the time, but currently strapi allows you to implement this with a simple middleware and a custom login route
I do use exactly same approach, and it is fact "FOR SECURITY WE SHOULD NEVER HAVE FRONTEND CLIENTS FOR APIS, INSTEAD WE SHOULD HAVE APPLICATIONS AS CLIENTS."
Bro, if you don't have an access to HttpOnly cookie, how you'll be able to check if token stored in cookie and show pages which are secured (In other words how to implement router guards for that)
Hey, thank you for this video, you have helped shed light on this burning question I have had this week. If I understood correctly, your frontend app needs to have a backend (which acts as a proxy) which calls the real backend.
@@AlextheEntreprenerd Thank you so much for putting out this video and sharing what you know. Last weekend I spent so much time trying to decide which approach to pick (Local/Session storage vs Cookie).
@@AlextheEntreprenerd I have one more question... in the subsequent api calls (for your landing page, profile, etc.)would you make the express server (proxy) calls open or would you add some sort of authorization to them? the proxy would get the authorization info (jwt token and user id) from the cookies in the request, correct?
you don't explain what your middleware does, and why not just use the middleware at first server fetch catch instead of fetch an other one request to himself to finally send back JSON data embeded (who can be also catch and read on the road if sniffing) ? I missed the point of this complexity. Maybe it should be useful to use a kind of UML plan to show that near the code, and each point of the code (include the middleware). Actually, you also didn't show how to send the JWT with httpOnly mode.
@@AlextheEntreprenerd Thank you Alex for your attention, I found your channel recently, and your videos are really awesome, I'm in the process of learning full-stack web development. and I've been looking for mentorship in my journey, could you please help me in my journey? I appreciate it. wish you all the best possible.
The problem I'm facing right now is How can i ping the server when using react-router-dom. I don't want to load any pages if the jwt token is expired or invaid.
this is great and thank you so much for opening our eyes, but if you have multiple apis to make request, the server is gonna be huge, what if you have only one request to express server that contains the metadata of the actual request from frontend so that the express server can forwad the request to the resource server that contains the actual response. forexample you may have body of the express server route that contains the (method of the request, url, headers,body and other options) and the express server will call the resource based on these information, using this you will only have one route that will forward your every request to respective service. thank you so much
great explanation Alex, But I have a question like, this approach would definitely work for frontend and backend would be in one place but how we can do when we are going for microservices like create a separate server for Authentication & Authorization, I mean we have one Auth-Server and others are different-different servers so in that case, we can't manage session so what would be the alternate secure solution, Again Thanks a lot.
The session/cookie is managed by the frontend's backend, that's where you read the cookie, retrieve the jwt and send a new request to the actual backend (auth server in your case).
I think you should do as you said, to build an auth server that provides valid JWT and all private microservice should validate the JWT and when they find a JWT not valid or expired just send to browser "token or session expired" like banks websites
httpOnly cookies can't be accessed by javascript, but they sure can be mutated from the browser's dev tool and sent along with a request to the server.
Thank you so much for this video....let say if i save token in cookie at client shall i need to manually send it along with header OR it will be auto sent if i stored in cookie..?
So if I understand correctly, even though the jwt token is in http only cookie, it is viewable from the users web browser. It doesnt matter that the authenticated user can see the jwt token in browser. However, it would be a security risk if the attacker actually had access to the users web browser. In this case, the malicious user could copy the jwt token and use it to potentially get a refresh token from the server api? Am I understanding this all correctly? Thanks for the great video Sir.
First, thanks for this, second: This method is pretty much what I currently have going for a project that has a web and an app(mobile), however for my case I have control over both backends (api's and frontend's) which are under the same express app. What's your opinion on having the middleware that authorises (checks token and sets user) be hybrid and also check for a regular userid session? My app(mobile) would use the token while my web's frontend's backend would call login on the api's backend and instead of storing the token, it would simply store the userid in the session.
Thank you for your appreciation. My 2 cents are that you are almost always better off avoiding using JWT for "authentication reliant applications". Also, for mobile apps, you can use: github.com/oblador/react-native-keychain or docs.expo.io/versions/latest/sdk/securestore/?redirected To safely store the JWT token. So your only need for a "complex architecture" is for your web application. If your express app is also serving your react app and issuing sessions, then you are already doing it "the proper way". My biggest advice is for you to spend a few hours trying to hack your own system, and possibly get a security audit done
@@AlextheEntreprenerd Thanks a lot for your reply, sadly youtube didn't notify me but luckily here I am. I'll check the links and follow your advice. Keep it up.
@@AlextheEntreprenerd Because the browser automatically sends cookies with each request, and therefor it automatically sends the jwt cookie and the user will automatically be authenticated. Please see this stackoverflow answer it explains it very well: stackoverflow.com/a/35329700/13343174
@@axedyson Makes sense, but you can counter that by using csrf cookies All in all my go to solution is to never store the JWT and just use ephemeral methods such as React Context. For most applications users won't mind having to log in again on every visit
Hey Mark, not sure about netlify. For sure you can get this to work on aws (not s3) by having two servers (one for Strapi, one for the Backend that will serve the frontend)
@@AlextheEntreprenerd I have just read an article that it is possible to deploy an express app to netlify via serverless-http. www.netlify.com/blog/2018/09/13/how-to-run-express.js-apps-with-netlify-functions/ ...
I have used password token for authentication using cookies with http only ,but lower level user become higher level user once he copied token from higher level cookie and paste in place of his token.how can I fix it?
So how is this any better than using regular session cookies for auth? Cookies can't store much, so most jwt won't fit in them, or is there something im missing? would love a perspective on this.
If you are using regular session cookies and you don't have any CSRF vulnerabilities and you are just serving your services to browser then you are good to go. I think the problem starts when you are trying to serve your API to browsers, mobile users and 3rd party applications. (think about Instagram) If you are trying to handle all three of them, you need the use some Token based Authentication. Mobile users and 3rd party applications are good on using tokens, but your web clients can be vulnerable to XSS or CSRF (again) on how and where you store the token.
Hey Luther, check into next-auth.js.org/ github.com/vercel/next.js/tree/canary/examples Notable examples are the "withPassport" one Also the withAuth0, you can either use Auth0 or learn how to attach it to any auth provider (Strapi included)
Thanks for the vids ! Im wondering while using api with PHP (codeigniter 4) who has httponly set to true and cannot be modify, would you make an server node to save an JWT token and sending call to the API ? (the front is next js)
I'm new to a lot of this, but isn't using refresh tokens a form of sessions anyways? I mean a refresh token is essentially maintaining a session right?
AuthCookie can be stored in app memory, updated by RefreshCookie if needed, and we only gonna ask to login when none of those avalible. See more hasura.io/blog/best-practices-of-using-jwt-with-graphql/#jwt_persist
I don't quite understand the http only cookie approach let me check if I'm correct: I have my frontend website which communicates with a backend server then which accesses the JWT authenticator? If I'm I understand it properly that seems like a lot of spaghetti
Hey Tomasz, if you store the cookie in the frontend without httpOnly and your website is vulnerable to XSS your users will have their credentials stolen. Happy to see an alternative to my proposal!
Let's Code out of curiosity is the auth server passing back a session token to the client? What if someone gets that? Wouldn’t that put you back in the same bad situation? Sorry trying to wrap my head around adding another server to access my server lol
Hey @@JohnnysaidWhat , I'm using session cookies but you can implement this with just cookies on the express side. If a malicious attacker where to gain access to the JWT they would be able to impersonate you. If somebody where to sniff your packets between the server and the client, the JWT token could potentially be stolen. However, if the connection between the client and the server is HTTPS (i.e. if your app is served with HTTPS), then the JWT token would be sent back and forth as an encrypted packet which should make it safe. Hope this clarifies!
I think this can scale. But the amount of work is doubled. If you were to use a Login Provider or Sessions, you wouldn't have to do this. Also, if you store the JWT ephemerally (in a variable inside of react), you don't have to do any of it. But your users will have to re-log in every time
after searching for like 2-3 days , I finally found my solution with this simple yet very beginner friendly video which is actually 3 years old
Finally a properly explained solution to this problem. Every other tutorial I have seen that mentions this is like: "Well JWT localStorage is unsafe" but proceeds to show a login method and saving the token in localStorage, or JWT Is Unsafe and the tutorial is all about why it's unsafe and doesn't explain how to prevent it properly. Thank You!
this comment speaks to my soul LOL
@@stefanplusplus917 My soul too
Good stuff and well explained. However, you mention at the end that you need to have frontend and backend on same domain to use cookies which is not necessarily correct in 2022 but requires additional steps. You can have backend on a separate domain and setup CORS (allowing headers like Access-Control-Allow-Origin and others) and ensure that the cookie is set as HttpOnly, Secure and the front end API calls are including withCredentials:true in the ajax calls. More steps but separate domains with cookies are possible
Hey, I've been having an issue with this. Could you add a video on your channel implementing this please?
@@henock5364 did you get any solution
Please, show us some reference to this approach.
This is not related to CORS, the reason he said that is because browsers block third party cookies in incognito mode if they don’t belong to the same domain.
Thank you very much. I've stayed away from jwt for this exact reason where I could not find any proper solution of how to use my token safly. Desserves alot more views, because every tutorial on these uses local or session storage to do it. Thank you again!
Excellent
Bottom line we need to store jwt in cookies
Thanks
Subscribed! I don't understand the secure implemantation yet, but at least you opened my eyes for new horizons. Thanks bud!
Wouldn't this be prone to CSRF attacks? What if you wanted to revoke the jwt-token?
This was a real concern to me! Thx for this 👍
Via httpOnly cookie, so we don’t need refresh token anymore?
WOW! You nailed it!
can you make a similar tut, with Drf(simple-jwt) & React.js please
Thank you for the information on this video, I would really like to check that demo hopefully you can release it, thanks!
This is what Sapper/Svelte does and is the most efficient way. Nice video!
Awesome!
Awesome, Best explanation that make me very understod the theory
Really glad found your channel
Thankyou verymuch anyway, best explanation
Thank you!
Question: So if I want to use this method, would it work across multiple domains? I'm guessing no, this will only work for a single page app?
This may help you with implementing this on a multi domain set up:
stackoverflow.com/questions/47497296/node-js-authentication-in-cross-domain
Personally, if you need to set up multi-domain auth, I'd look for an authentication provider instead.
confused. if you can still see the jwt token when you go through application. how does it make it any more secure than just storing it in a regular cookie? understood that when you use script; it would be not be.
You can see it, a machine cannot.
An attacker can still copy paste it and stole the token and can be shared
It is secured in a way that you won't be vulnerable to xss attacks (httponly cookie) because it can't be access by the frontend. But this setup is still vulnerable to xsrf/csrf attacks.
@@markhermano1 No CSRF attacks happen when the browser does the authentication for you. In this setup, the cookie does nothing other than allow the back-end to validate the connection.
Can you explain the benefit of jwt over regular backend sessions? If we have to store login credentials on the server why not just use sessions
Sessions are better, if you can use sessions do that.
Simulating sessions with JWT is a compromise you may have to take when using 3rd parties (Headless CMSs such as Strapi being the core of what I teach)
Hello,
Thanks for the video.
So if i am understanding correctly, we should store the jwt in header cookies and send requests everytime to backend and fetch the required data correct.
Do we need store the token in front end too or we can just decript the jwt to read the data? I have not yet gone over how to decrypt the jwt in web api
thanks
This is what i looking for. Nice explanation. Thanks a lot.
I don't know how strapi middlewares looked at the time, but currently strapi allows you to implement this with a simple middleware and a custom login route
I do use exactly same approach, and it is fact "FOR SECURITY WE SHOULD NEVER HAVE FRONTEND CLIENTS FOR APIS, INSTEAD WE SHOULD HAVE APPLICATIONS AS CLIENTS."
Bro, if you don't have an access to HttpOnly cookie, how you'll be able to check if token stored in cookie and show pages which are secured (In other words how to implement router guards for that)
A cookie can't be very long, so your JWT payload would be limited. So why use a JWT at all for session management?
HTTP cookies can not be read from the application you do not want to put the payload there is unless you use a proxy
Hey, thank you for this video, you have helped shed light on this burning question I have had this week. If I understood correctly, your frontend app needs to have a backend (which acts as a proxy) which calls the real backend.
Yes, this is the best solution I came up with.
@@AlextheEntreprenerd Thank you so much for putting out this video and sharing what you know. Last weekend I spent so much time trying to decide which approach to pick (Local/Session storage vs Cookie).
@@MysticAngel3224 Glad you enjoyed it!
@@AlextheEntreprenerd I have one more question... in the subsequent api calls (for your landing page, profile, etc.)would you make the express server (proxy) calls open or would you add some sort of authorization to them? the proxy would get the authorization info (jwt token and user id) from the cookies in the request, correct?
you don't explain what your middleware does, and why not just use the middleware at first server fetch catch instead of fetch an other one request to himself to finally send back JSON data embeded (who can be also catch and read on the road if sniffing) ? I missed the point of this complexity. Maybe it should be useful to use a kind of UML plan to show that near the code, and each point of the code (include the middleware). Actually, you also didn't show how to send the JWT with httpOnly mode.
so as a backend developer should i always store my access token in httpOnly header ?
Yes, secure only, http only
@@AlextheEntreprenerd Thank you Alex for your attention, I found your channel recently, and your videos are really awesome, I'm in the process of learning full-stack web development. and I've been looking for mentorship in my journey, could you please help me in my journey? I appreciate it. wish you all the best possible.
Love it..best explaination so far
Thanks!
can you give us this demo please
Amazing content! Really glad I found your channel
Thanks!
The problem I'm facing right now is
How can i ping the server when using react-router-dom.
I don't want to load any pages if the jwt token is expired or invaid.
this is great and thank you so much for opening our eyes, but if you have multiple apis to make request, the server is gonna be huge, what if you have only one request to express server that contains the metadata of the actual request from frontend so that the express server can forwad the request to the resource server that contains the actual response. forexample you may have body of the express server route that contains the (method of the request, url, headers,body and other options) and the express server will call the resource based on these information, using this you will only have one route that will forward your every request to respective service.
thank you so much
Way easier and scalable to use an Authentication Provider, that's why I recommend using Magic (see my Ecommerce video)
@@AlextheEntreprenerd thank you man
great explanation Alex,
But I have a question like, this approach would definitely work for frontend and backend would be in one place but how we can do when we are going for microservices like create a separate server for Authentication & Authorization, I mean we have one Auth-Server and others are different-different servers so in that case, we can't manage session so what would be the alternate secure solution, Again Thanks a lot.
The session/cookie is managed by the frontend's backend, that's where you read the cookie, retrieve the jwt and send a new request to the actual backend (auth server in your case).
I think you should do as you said, to build an auth server that provides valid JWT and all private microservice should validate the JWT and when they find a JWT not valid or expired just send to browser "token or session expired" like banks websites
you start video with false cookie-making syntax?
httpOnly cookies can't be accessed by javascript, but they sure can be mutated from the browser's dev tool and sent along with a request to the server.
What if I use chrome extension.. And I want to send API request to backend to another server? Which method to use for jwt?
Thank you so much for this video....let say if i save token in cookie at client shall i need to manually send it along with header OR it will be auto sent if i stored in cookie..?
It will automatically send, you dont need to worry about that anymore.
if some one stolen this and paste in another browser it will work ??
You need to also the site SameSite policy on the cookie to strict otherwise you are still vulnerable to XSRF, right?
If your backend and frontend runs on different domains, that can't be achieved (without nginx reverse proxy)
Great Tutorial, can you share the httpOnly example ?
So if I understand correctly, even though the jwt token is in http only cookie, it is viewable from the users web browser. It doesnt matter that the authenticated user can see the jwt token in browser. However, it would be a security risk if the attacker actually had access to the users web browser. In this case, the malicious user could copy the jwt token and use it to potentially get a refresh token from the server api? Am I understanding this all correctly? Thanks for the great video Sir.
If attacker has access to users web browser then it's game over. There is nothing you can do there. User's system is already compromised.
First, thanks for this, second: This method is pretty much what I currently have going for a project that has a web and an app(mobile), however for my case I have control over both backends (api's and frontend's) which are under the same express app. What's your opinion on having the middleware that authorises (checks token and sets user) be hybrid and also check for a regular userid session? My app(mobile) would use the token while my web's frontend's backend would call login on the api's backend and instead of storing the token, it would simply store the userid in the session.
Thank you for your appreciation.
My 2 cents are that you are almost always better off avoiding using JWT for "authentication reliant applications".
Also, for mobile apps, you can use:
github.com/oblador/react-native-keychain
or
docs.expo.io/versions/latest/sdk/securestore/?redirected
To safely store the JWT token.
So your only need for a "complex architecture" is for your web application.
If your express app is also serving your react app and issuing sessions, then you are already doing it "the proper way".
My biggest advice is for you to spend a few hours trying to hack your own system, and possibly get a security audit done
@@AlextheEntreprenerd Thanks a lot for your reply, sadly youtube didn't notify me but luckily here I am. I'll check the links and follow your advice. Keep it up.
But If we are storing the jwt in an httpOnly cookie isn't that a CSRF vulnerability??
How is that so?
@@AlextheEntreprenerd Because the browser automatically sends cookies with each request, and therefor it automatically sends the jwt cookie and the user will automatically be authenticated. Please see this stackoverflow answer it explains it very well: stackoverflow.com/a/35329700/13343174
@@axedyson Makes sense, but you can counter that by using csrf cookies
All in all my go to solution is to never store the JWT and just use ephemeral methods such as React Context.
For most applications users won't mind having to log in again on every visit
@@AlextheEntreprenerd Thanks. Yes, I'm going to store the JWT inside a httpOnly cookie and then use some kind of csrf protection
@@AlextheEntreprenerd How do big apps like youtube and google keep up logged in then ... what approach do they use and not be vulnerable?
Hi Alex, if we save token in server and we have load balancer that send request on different server so how can we make it stateful ?
Great explanation!
How do we serve this kind of setup in netlify or aws s3? Is this possible or you need to deploy this in a vps?
Hey Mark, not sure about netlify.
For sure you can get this to work on aws (not s3) by having two servers (one for Strapi, one for the Backend that will serve the frontend)
I think a VPS will work, probably 2 VPS (2 servers just like I said above)
@@AlextheEntreprenerd I have just read an article that it is possible to deploy an express app to netlify via serverless-http. www.netlify.com/blog/2018/09/13/how-to-run-express.js-apps-with-netlify-functions/ ...
I have used password token for authentication using cookies with http only ,but lower level user become higher level user once he copied token from higher level cookie and paste in place of his token.how can I fix it?
Strapi not implement jwt cookie http only by default, can you explain?
Hi Alex, may i know how to auto login if i use htty only cookies?
So how is this any better than using regular session cookies for auth? Cookies can't store much, so most jwt won't fit in them, or is there something im missing? would love a perspective on this.
If you are using regular session cookies and you don't have any CSRF vulnerabilities and you are just serving your services to browser then you are good to go.
I think the problem starts when you are trying to serve your API to browsers, mobile users and 3rd party applications. (think about Instagram)
If you are trying to handle all three of them, you need the use some Token based Authentication.
Mobile users and 3rd party applications are good on using tokens, but your web clients can be vulnerable to XSS or CSRF (again) on how and where you store the token.
how to manage refresh_tokens for multiple devices of same user ?
Hi, Alex! I´m new on NextJs so excuse my question, but: What if i´m using Next.js? Do i need to use Express backend also?
Hey Luther, check into
next-auth.js.org/
github.com/vercel/next.js/tree/canary/examples
Notable examples are the "withPassport" one
Also the withAuth0, you can either use Auth0 or learn how to attach it to any auth provider (Strapi included)
Thanks for the vids ! Im wondering while using api with PHP (codeigniter 4) who has httponly set to true and cannot be modify, would you make an server node to save an JWT token and sending call to the API ? (the front is next js)
But one can also go to the network tab by inspecting and get the response of the api request where we fetched the token. How to prevent that ?
That is not the case here. The actual API call to get the access token is taking place from Express, which won't show in frontend's network tab.
Its a good tutoral for this topic
Thank you!
Very concise!! Keep up ur great work!!
Thank you!
Where you demo httpOnly cookie, You are proposing, make another request and maintain session.
I'm new to a lot of this, but isn't using refresh tokens a form of sessions anyways? I mean a refresh token is essentially maintaining a session right?
thank u so much for the information
Happy to help!
AuthCookie can be stored in app memory, updated by RefreshCookie if needed, and we only gonna ask to login when none of those avalible. See more hasura.io/blog/best-practices-of-using-jwt-with-graphql/#jwt_persist
really a great article, thanks a lot for sharing it
But isn't it vulnerable to csrf attack?
Yes, you need to add csrf mitigation
@@AlextheEntreprenerd how to prevent it would you reply i was looking for it last 2 days??
@@mdjahidulislam9205 check csurf: github.com/expressjs/csurf
and look at owasp guides: owasp.org/www-community/attacks/csrf
how can this method of using httpOnly cookies prevent Cross site Request Forgery (XSRF) attack?
You can add a CRSF token to mitigate
@@AlextheEntreprenerd ok let me try to do some research how to do that in angular
so basically you are combining express and strapi? I thought strapi is supposed to work alone without express
No, I'm serving my React app through express
But why do you send a authorization header when u send a cookie?
I don't understand your question
@@nims5537 why send headers when u only need to deal with cookies.
@@chakhmanmohamed9436 We need the authorization header to be sent to the server to gain access because the token is sent through this header
But cookies are not enabled in incognito mode of browsers. That would break the whole app. How to go around that?
The browser starts with a fresh set of cookie and localstorage bucket, so either way it would break authentication regardless of method followed.
if the token is not sent to the front end, how do we exactly know the user is that specific user?
You could write a /me method that will retrieve the data for the currently logged in user.
This way you can retrieve the data without leaking the JWT
I don't quite understand the http only cookie approach let me check if I'm correct: I have my frontend website which communicates with a backend server then which accesses the JWT authenticator? If I'm I understand it properly that seems like a lot of spaghetti
Hey Tomasz, if you store the cookie in the frontend without httpOnly and your website is vulnerable to XSS your users will have their credentials stolen.
Happy to see an alternative to my proposal!
Let's Code out of curiosity is the auth server passing back a session token to the client? What if someone gets that? Wouldn’t that put you back in the same bad situation? Sorry trying to wrap my head around adding another server to access my server lol
Hey @@JohnnysaidWhat , I'm using session cookies but you can implement this with just cookies on the express side.
If a malicious attacker where to gain access to the JWT they would be able to impersonate you.
If somebody where to sniff your packets between the server and the client, the JWT token could potentially be stolen.
However, if the connection between the client and the server is HTTPS (i.e. if your app is served with HTTPS), then the JWT token would be sent back and forth as an encrypted packet which should make it safe.
Hope this clarifies!
Thanks Alex that makes a lot of sense now!
Doesn’t scale well. Like i cannot scale only the frontend now, can I?
I think this can scale. But the amount of work is doubled.
If you were to use a Login Provider or Sessions, you wouldn't have to do this.
Also, if you store the JWT ephemerally (in a variable inside of react), you don't have to do any of it. But your users will have to re-log in every time
I mean at this point i would just use a server side rendered framework like nextjs. Or build a custom serverless solution like firebase auth does
Sorry, but a lot of questions. Like if you serve your react app from expresss, what is the impact on ttfp, tti?
Very interesting
Thank you!
Thanks good information
cool vid
fantastic🙏🏻🌷❤️👍
Thanks, I open Udemy link and invite you to accept my request, With my respect
what about httpOnly