My team is using SuperTokens to implement authentication for a website which will be used by 2 sets of users, i.e., consumers and partners. For consumers, we want to use passwordless logins, and we want the session to only be valid for a short duration of inactivity. For partners, we want to use email/password logins and we want the session to be valid for a day of inactivity. We have managed to implement authentication for consumers. Now, we are wanting to implement it for partners, but we are unsure how we can achieve our intent. I know that an additional recipe can be included in the implementation so both passwordless recipe and email/password recipe will be available to both sets of users, but the UI for each will only present the method that is earmarked for their type of user. So far so good. How do we tweak the session duration and period of inactivity, etc. for each type of user?

hey @umarfkhawaja

Hi @rp_st

you can add a custom payload prop in the session's access token like

customExpiry

value when the session is created. The value of this will depend on the type of user. Then you can make your own verify session middleware which calls our getSession function first, and after successful verification, it will check the

customExpiry

and if it's past this time, send back a 401. Finally, you override the refresh API to call our refresh function, and then check the same

customExpiry

in the returned session object. If that's past the expiry, then you would also revoke the session before returning the response. This would work as long as the timeout set in the core is the larger value of the two types of session timeouts you want.

where is session created?

createNewSession function override

out of curiosity, is it possible for a service to use 2 instances of SuperTokens to authenticate a user?

> out of curiosity, is it possible for a service to use 2 instances of SuperTokens to authenticate a user? It's not cause the backend SDK is a singleton > can I combine emailpassword recipe and thirdpartyPasswordless recipe? In what way? From a UI point of view?

in SuperTokens

yes - correct. So you just need to add emailpassword and thirdpartypasswordles to the recipe list on the backend and frontedn

that makes sense

@rp_st @umarfkhawaja Are you initialising a separate frontend config for both kind of recipes. Or you managing both at the same time?

We are managing both at the same time