Avoid storing tokens in cookies Hi there! I'm cur...
# general
p
Avoid storing tokens in cookies Hi there! I'm currently exploring an auth strategy for my monorepo, where I have an API in a nextjs app (it's currently working with next-auth but I'm a bit unhappy with that set up). My issue is that I not only make requests from the nextjs frontend but also from different domains (a chrome extension and outlook add-in in my case). https://stackoverflow.com/a/64664632/5608461 Is it possible to adapt supertokens so that it doesn't use cookies?
r
hey! So is the api domain that is being queried the same?
p
Yes
There's only 1 api
r
So then you can use cookies
Since the cookies are attached to the API domain
p
I don't think I can use cookies on the chrome extension?
My api won't be able to set cookies for it
r
im not entirely sure. But i think you can
we have had users use us with extensions
and they never complained that it's not possible
so i assume that you can
p
Not without some major dev drawbacks (requires https for latest browser versions, which is a pain on localhost from my experience).
r
yea fair
p
I'd be curious to see how the other projects solved this. I'm actually inclined to roll an own JWT approach.
r
So you can use us without cookies. SuperTokens is split into multiple "recipes" and we have a session recipe that handles session management via cookies. Each recipe has a set of functions that govern how it works. For example, the session recipe has createNewSession, verifySession, revokeSession etc... The default implementation of those set response cookies and read from request cookies. You can override these functions (think inheritance override) to instead set the response body and read from the request header. Furthermore, the session recipe also has functions to create a JWT with any payload which you can use to make your own tokens inside these functions. ------------ The above is one possible approach. Alternatively, you can use another method which requires you to add interceptors on the frontend and backend which will map the cookies to headers in the response / request. This will be slightly more complex, but in this case, you don't have to manually issue your own tokens and can take advantage of session features like rotating refresh tokens, update to access token payload, revoking of multiple sessions per user etc.. We even have a demo app for this: https://github.com/supertokens/supertokens-auth-react/tree/master/examples/with-localstorage
@p6l.richard
p
Thanks, that comes very close to what I had in mind. Great @rp
Do you guys support remix? It's not stated as one of the `framework`s https://supertokens.com/docs/nodejs/init#framework-optional
r
we don't yet 😦
p
I could've checked the github issues as well, it's listed there: https://github.com/supertokens/supertokens-core/issues/406#issuecomment-1102899784 tl;dr: soonish possible, but not documented/maintained yet
r
The SDK that comment refers will still take a few weeks at least
p
Okay, thanks a lot for the answers.
Really helpful. I think we will probably fall back to implementing our own auth, but your answers here will make me rethink in the future.
I always disliked auth0 when I had to work with it and since I'm a beginner dev your responsiveness makes a difference for me. Highly appreciated 🙏
r
sounds good! Since you want to make your own auth with JWTs, you can just use supertokens for issuing the JWT - so you don't have to figure that stuff out.. 🙂
(and prioviding the jwks URL of course)
3 Views