That depends a bit on the scope of your App and what you need to protect against.
In a recent project of mine, for example, all authentication related code (including JWT retrieval/refresh) is within an iframe on a different origin. The client application requests an access token from the "auth" iframe via postMessage (conlink <https://github.com/GoogleChromeLabs/comlink> makes this really easy) and never has access to the refresh token. In this case, both the refresh token and access are only stores in standard js variables, and no third party code runs within the "auth" iframe, so the refresh token can't be obtained by some third party script. Some applications store tokens in localStorage, though in that case you need to be confident that there isn't any way for third party code to run within the users session and "steal" the refresh token. Perhaps you need to take a little bit of a step back and ask yourself if you actually need to use JWT - it's a great fit for situations where you need to deal with CORS and pass tokens around different services that interact with each other on your behalf... but if you don't need that then you may be better off with regular django session authentication, signed cookies, etc.. Kind Regards, Michael Thomas On Sat, May 8, 2021 at 11:02 AM narendra thapa <narendrathapa...@gmail.com> wrote: > Thank You @Michal Thomas, i was able to refresh a token now, But i got > another confusion from your answer :D. Which is the best place to store a > refresh token to make it secure? > > On Sat, May 8, 2021 at 12:20 PM Michael Thomas < > michael.thomas.s...@gmail.com> wrote: > >> Generally speaking, storing a JWT token (especially a refresh token) as a >> cookie isn't the best thing to do, as it means you're potentially "leaking" >> the token in every request where that cookie is valid, rather than >> intentionally sending it as a header only when you intend to (among other >> issues). >> >> Also, you've basically reinvented something >> like django.contrib.sessions.backends.signed_cookies, but with extra >> complexity :) >> >> But, if you really intend to do this, you could solve this as follows: >> >> 1) Replace your authentication class with a subclass of >> rest_framework_simplejwt.authentication.JWTAuthentication (or >> JWTTokenUserAuthentication) >> 2) Replace authenticate() with your own version, which generates a new >> access token if the old one has expired, using the refresh token >> >> Or, in your client code: >> >> 1) Catch a 401 (or 403? can't remember which is generated for an expired >> token) >> 2) Call your "refresh" view to update the access token >> 3) Retry the original request that generated the 401/403 >> >> But really, it's much simpler (IMO) to keep the JWT tokens in javascript. >> Your client code can then simply check the expiry of the access token >> before each request, and call the refresh view to get a replacement before >> making the request. >> >> I hope that helps! >> >> Kind Regards, >> Michael Thomas >> >> On Sat, May 8, 2021 at 6:49 AM narendra...@gmail.com < >> narendrathapa...@gmail.com> wrote: >> >>> i'm using django as my backend and react as frontend. i'm using >>> simplejwt for authentication. i can get access and refresh token and has >>> stored in httponly cookies. now i'm not able to refresh a token. can >>> somebody help me out? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/978ecb8d-10c7-4152-b538-49edb911c3acn%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/978ecb8d-10c7-4152-b538-49edb911c3acn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAEdx1fp7akj4euL0Z%2Bn%3DmAiBkQQTM5pKEkhriWEyXsZ6uk0O1Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAEdx1fp7akj4euL0Z%2Bn%3DmAiBkQQTM5pKEkhriWEyXsZ6uk0O1Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAEtntjV_Q13e0xpv68Y%3DTGqarbytbc5j-pGStJhPS8gcrCTbAQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAEtntjV_Q13e0xpv68Y%3DTGqarbytbc5j-pGStJhPS8gcrCTbAQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEdx1frY4WNUQzgM_b-TowSNM-v6Vx3xGTiHkWuuUsdq850Phw%40mail.gmail.com.
