cause it's by default 0.0.0.0

Hey @User I thought of a token security concept. Will this work? It's called

next tokens

. And works like this: - User logs in - generates Access token (expires after time (1hr), unlimited use) - generates Next token (unlimited expiry, single use) - Both are stored in local/async storage OR in cookies - User uses app/site, via access token and access token then expires - To get new access token the user must send Access Token AND Next Token to specific endpoint eg

/next

- Endpoint checks criteria: - Does Access Token match the issued one time use Next Token? - Has access token fully expired? - Has Next Token been used before? - If it passes all 3 then a new Access Token and Next Token are generated - If it fails check number 3 (next used before) it will send a hacking alert How does this all sound?

1) Why does one need to pass the access token along with the next token to get a new access and next token? 2) If you do not required to pass an access token in the "Refresh" API, then it becomes the same as using short lived access and long lived, one time use, refresh tokens. 3) Storing tokens in localstorage is not a good idea

1) Because the access token is matched with the next token (they are connected) next token is only able to generate new access token based on whether both are the same as those issued. Eg on login, Access token can be the

key

and Next token can be the

value

in redis

And new next token can only be generated if access token expired

so it must check that as well

that would add security if the access and the next token are stored in different places. However, they are stored in the same place, so why would using both add security? I'd argue that just using the next token is enough. > And new next token can only be generated if access token expired Cool. However, why?

This means that if you provide both tokens to

/next

you generate new token pair. U only use

next token

once and if you generate new pair, and then someone else tries to generate new pair before the issued pair access token expires then you know that user is being hacked

Yes. That is sort of the idea behind rotating refresh tokens too. However, it has a few race condition / network failure related problems that lead to false positives. Solve for those, and you will end up with SuperTokens.

Awesome looool

haha

I see that there's probably race conditions

yup.

Hey im going to send a DM about integrating with connectycube, is that alright?

yup!

hey all, where is the "forgot password" flow and implementation?

for some reason can't find it, I want to check the security of it

Hey

It hasn't been released yet, but the algorithm is here: - For logic for the API for creating a new password reset token: https://github.com/supertokens/supertokens-core/issues/106 - For logic for the API for using the password reset token to change the password: https://github.com/supertokens/supertokens-core/issues/109 - The method used to generate the password reset token: https://github.com/supertokens/supertokens-core/issues/78#issuecomment-721951617

so the algorithm is there but I can't implent it using supertokens?

not yet, because it's not released yet. It's still under dev & testing. However, we expect to release it in ~ 1 week from now

wow! that fits just right :) good job guys

cheers! thanks

Hi @User I came here from one of your StackOverflow answers and was wondering if you'd maybe want to help me decide between sessions and JWT's

https://stackoverflow.com/questions/65436426/secure-a-graphql-api-with-passport-jwts-or-sessions-with-example I have this SO post where I explain about the backend and frontends I have to serve, it includes an example auth flow as well

Hey!

Have you read this post: https://supertokens.io/blog/are-you-using-jwts-for-user-sessions-in-the-correct-way

I think that would answer most of your questions. And if not, you can ask them here and I’ll help 🙂

I have not but after reading the titles quickly I saw that I worked around the cons by introducing a state, which makes me wonder if I am maybe not better off using sessions instead

The pro's are becoming cons too because I do have a specific database lookup