nope, same warning

oops. it should be cookieSameSite

and also, it shouldn't be cookie_domain, it should be cookieDomain

See https://supertokens.io/docs/nodejs/api-reference/init

great it works

Thank you for the quick help

ur welcome

@User Would Lumen work with the Laravel version?

I don't think so. That SDK was made specifically for Laravel and we haven't tried it with Lumen. You can try it out and if it works, then great!

Hi @vdvn75

I have a very simple question, couldn't be more sillier maybe. What is the appropriate way for the UI to handle expiry of tokens. Should it be like the API is hit with an expired token, backend throws auth error and then UI hits another API to get refreshed tokens?

that is one way.

Another way is if the frontend knows that the token has expired already, and directly calls the refresh API

how did you find out about us? Through our site or blog?

How does the frontend know the token has expired? By maintaining the expired_at or expired_in sort of a thing? Also a similar thing should be in place for refresh tokens?

And I knew about you guys recently just through searching for good articles on google for user authentication and came across the blog 😄

And ofcourse which one is preferred ?

Yea.. store some value in localstorage or non-httpOnly cookie using which you can know when it expires. We can do that for the refresh token as well.. but that doesn't matter too much cause usage of refresh tokens is relatively rare anyway.

I see. Are you looking to use supertokens? Or just curious?

We are building a new auth service right now while we have opaque tokens in place currently and searching for the best methods to use

So we will be having few discussions today and will be evaluating to use super tokens or build something in-house

I see. Please do let me know how I can help you evaluate SuperTokens. Are you looking to implement rotating refresh tokens? Or just regular refresh tokens?

Rotating refresh tokens seems better in terms of security and theft detection, anyway we will be evaluating that as well

Ofcourse we need a very custom authorization flows as well although super tokens does the auth flow perfectly.

Hence, the discussion and the evaluation

Yup. Rotating refresh tokens is also being recommended by the latest OAuth RFC as a MUST have for browser based apps: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05#section-8

Thank you 😄

Also, can you suggest how to implement single device login with the AT and R-RT in place?

Cause if you have just regular refresh tokens, from a secruity point of view, it's almost as good as having no refresh token at all.. (this is only true for frontend clients)

when u say single device login, do you mean allowing the user to be logged into only one device at any given time? Or allowing one session per device and allowing a user to log into as many devices as they want?