Hi, we are building an application where we are planning to use two different auth methods(email-password and passwordless) for two different use cases. Just want to confirm if it is possible to club these two?

hey @roushan_46400 when you say these are fro different use cases, but you also want to club them, what do you mean?

I mean two different auth methods like for admin tool we want to use email-password and for other users, we wanna use passwordless(magic link).

yup. That's certainly possible

Cool One more thing I would like to confirm that is that possible to create user before the magic link generation. We have a use case where we want to create a user as soon as the request comes, but he will be valid user once we approve them. So flow will be something like this: User requests access -> user should be created at SuperTokens Once admin approves that request at our end, we will trigger an magic lick to activate that user.

yup, this is possible as well.

How can we create the user? I am assuming, if I call this method: https://supertokens.com/docs/passwordless/common-customizations/disable-sign-up/passwordless-via-allow-list a user will be created. Is there any alternative to create a user in passwordless auth method?

We have passwordless.signInUp function exposed on the backend SDK using which you can create a user implicitly. See this: https://supertokens.com/docs/passwordless/common-customizations/disable-sign-up/passwordless-via-invite-link

Want to add one more thing, we want to use supertokens for main website & admin tool login. Can we use different session configurations for both?

do they both have different backends?

No, we are planning to use the same backend auth service for both of them.

ok, and the thing you want to configure differently is the session timeout I assume? Or something else?

Yes, for now timeout only. But will it cause any issue if want to configure anything else?

well, no issues as such.

Okay So, you are saying to add a custom claim for the token which has shorter timeout and since the global value is also set, the other token will expire at that.

Yup.

What if we want to configure session refresh and session storage data in the session configuration. Do they also have some global values that we need to set? Or just providing custom claim on them too will work?

Session refresh data?

yes

Ah right. So that can also be done via a custom claim. Basically if you send a 401 to a frontend, our SDK will attempt a session refresh.

And what if we want to store this data at different places?

So supertokens only stores the hash of the refresh token in our db. On the frontend, the access and refresh tokens are in httpOnly cookies by default

Currently, I don't want any. Yes, JWT tokens are stored in cookies itself. But just wanted to confirm I we in future want to change to have different storage type (its highly unlikely but just want to confirm)?

yea you can. We have header based auth as well which returns the tokens in the response headers (not in cookies), and that can be stored on the frontend whererver you like.

Cool. Thanks for your quick support.

@rp_st Is it a good idea to run separate Supertokens backends with distinct configurations (connected to the same database) for Admins and our users? Additionally, do you have any suggestions on how to efficiently route requests between them?

Whats your use case again?

@rp_st Wanted to have different access/refresh token expiry for different roles (users & internal admins).

that can be done by setting the config in the core to the higer value, and then injecting a custom claim in the access token roles which need a lower expiration value. Then post session verification, manually check the value of the custom claim and if it's expired, revoke the session and return a 401 from the API.