Using opaque tokens (sessions) + JWT gives a good balance between speed and revocability

So if you read that post above, perhaps your questions will be answered :). It talks exactly about what your saying

Okay so after reading it I figured I may have implemented the new approach, however instead of storing the opaque token in the DB I have a token version in the user table, the refresh token in the cookie has a token version too and before issuing a new access token I check if the cookie version matches the one in the database so I can increment the database version in case an account gets stolen, I guess that is what you recommend

I think that only brings me to the point where you mentioned Oauth2 where you recommended to use the refresh / access token coming from the oauth call, I am dealing with those manually too, is that bad?

It’s going to be very difficult for me to advice on this without completely understanding your use case and your current implementation.

There are tons of nuances to think about when dealing with these tokens

So I would recommend not trying to build it yourself. Unless you are an IDp expert

I have it in the post, I have a single backend with a GraphQL API and a React Native app + web app to be used internally, it's to populate the data in the app, web app only needs Google auth and RN app needs Facebook, email, SMS and apple login, would like to serve these 2 clients with the single backend

I’m sorry @User but it’s going to be very difficult for me to give me opinion on such a broad subject over chat. If you have a really specific question in mind, I’d be happy to help if I can.

Okay thanks though

Sorry couldn’t help out much.

Hi @daniell I noticed you mention React-Native. KIndly assist me with setup . Thanks.

@User I would like to point out something about the default email sending behavior in the Node pkg: https://github.com/supertokens/supertokens-node/blob/cafec349c50cfee4c944a5020803bbe16fce6bfd/lib/ts/recipe/emailpassword/passwordResetFunctions.ts#L38-L49 This is sending a token that essentially acts as a password allowing someone to take over an account, and it's being sent to a third-party server. Granted, it's a server owned by the maintainers of the pkg, but it still feels like not a great way to do it (even if it is nice to see emailing work out of the box). Some possible solutions: - Use this behavior only if you detect that the core server is also on supertokens.io, or better yet, remove it entirely - Maybe instead of current behavior, the default sender function could detect a peer dep on nodemailer and look for SMTP credentials on

process.env

, which would be email server agnostic? Meteor's

email

package does something like this. https://docs.meteor.com/api/email.html - At least mention this in the

createAndSendCustomEmail

docs, with a clear warning about the security implications of the default behavior, if it isn't changed. Also explain which emailing service receives the data after that, and whether it is stored or logged anywhere. Perhaps a separate "Emails" section in docs rather than burying it in the init config docs.

@User your recommendations make sense! We will update the docs very shortly. Btw, you can override this behaviour and control sending the password reset email yourself (in node itself). This would then not send the reset token to any third party.

Also, I did not test this, but if that email sending API endpoint isn't secured, it seems like it would be very easy to spoof a password reset email and make it appear to come from any site using supertokens

Yes, I figured out how to override. I just wanted to point out that the default behavior is a bit scary

> it seems like it would be very easy to spoof a password reset email and make it appear to come from any site using supertokens True, we are planning on adding an API key to it which you would need to use to query our API. This API key would be tied to your website domain and app name which would prevent spoofing 🙂

But yes, we will mention these points in our docs as a clear warning, and recommend users to override the function to handle sending this email themselves (until we can fix the issues)

Thank you for your suggestions @User 🙂

@User , from a security point of view, what exactly are the risks in keeping the APIs we provide open? - If we added an API key to call our APIs, an attacker could fetch their own API key to call our API anyway. - If an attacker wants to phish passwords (via the enter new password form), they can create their own app, make their website look like the target website, and send "legit" password reset emails to targeted users anyway. They could even call their app the same name.. So adding an API key wouldn't solve this issue either. The proper way would of course be to send the email via an email ID that uses the @website domain. However, for that, you would need to override the function (we will mention this and the other points in the docs). ------------ So I don't see why we should add an API key as such to the endpoint we provide - am I missing some edge case here?

I don't think it's possible to 100% prevent it as you point out. The main concern would be if you are somehow allowing customization of the email design, but not requiring an API key to trigger it. If they all look the same by default then I would not worry much about that case. But if you provide ability to add a logo or something, then it would make sense to tie that to an API key. Yes, anyone could register one and upload the same logo or use the same title, but that doesn't mean it isn't worth doing. You would at least have some more info about who is doing the spoofing.

In any case I don't think it's a high level security issue; most people would probably implement their own sending by the time it is in production. More like something to think carefully about

(From a cost perspective, I would think you might want to move the API calls to core, and have node call core, which could then call the sender API with a key that only you know. That way you can continue to send emails out of the box for people using your hosted service but not for people who are self-hosting core.)

@User makes sense! Will give this a thought 🙂

In the blog about cookies vs localstorage and security would it not make more sense to have the refresh token in httponly cookie and just have the access token in memory? In a csrf attack only the refresh token would be sent so no malicious action could be taken. In a XSS attack there is nothing in localstorage to get and the cookie is inaccessabile

an xss attack would need to then get your token from memory, which would require something specific to your codebase/framework etc. Not as easy as just reading everything from local storage

It wouldn't really protect you from XSS attacks, it would just make them a bit harder, not something we'd want to rely on.

how does supertokens mitigate csrf?

Plus storing access token in memory would result in doing extra refresh calls every time the user reloads the page + you would have to prevent against CSRF attacks anyway to prevent the refresh endpoint from being called from a malicious site

We prevent against CSRF by using custom headers (as long as the user has correctly restricted the CORS’ Allowed origins). If however, that restriction is not possible, then we do provide an anti CSRF token which is added to the request header for each request