We're still at an investigatory / proof of concept stage at the moment, but if the above feature requests are something you'd be interested in doing, the company I work for may be willing to contribute towards development costs

> Possible Feature Requests Interesting... we will think about this soon enough. Multi tenancy is something we do plan on supporting 🙂 If you could, please create a github issue about this.

Will do!

I'd be happy to get on a call to discuss this further. You can book a slot with me here: https://supertokens.io/call-user

@User , it might actually be possible to have multi tenancy support with one core and one db (one table for all tenants) and simulate the properties of multi tenancy. For example, for email password: The constraint our tables have is that the userId must be unique and the emails must be unique. So you could use the

override

recipe functions feature on the backend to modify emails by adding the tenantId to them, so that if a user uses the same email across tenants, it will still be unique from the core's point of view. So an email like

user@example.com

would be modified to

user+tenantId@example.com

interesting! Just trying to work out if any other functions would need to be overridden to strip these out, e.g. before emailing out

Yes. You would need to override all the functions (there r just a few of them).. should be quite easy.

I'll need to have a play and see if I can implement it as this. Thanks for the brainwave!

So all the functions are here: https://supertokens.io/docs/nodejs/thirdpartyemailpassword/override/functions

Actually, you should override APIs and not functions (cause there is an API input change - you are adding a tenantId to the request): https://supertokens.io/docs/nodejs/thirdpartyemailpassword/override/apis You would override the following:

emailExistsGET:
- Change the input email to add the tenantId to it before calling the original implementation of this API

generatePasswordResetTokenPOST:
- Change the input formFields' (where id == "email") to add the tenantId to the email

signInUpPOST (type == "emailpassword"):
- Change the input email to have the tenantId before signing in / up.

signInUpPOST (type == "thirdparty"):
- You can copy/paste the whole API's body from our repo, and after getting the user's info from the OAuth provider, you would change the email and thirdPartyId to have the tenantId.

The above would in turn imply that if you fetch user info from Supertokens, you would get their email with the tenantId attached to it. Also, if you want to fetch a user based on their email, you would need to provide the email with their tenantId with it. If you want SuperTokens to output the emails without the tenantIds, you can overide the recipe functions (the other link I sent), and override all the functions that return a

User

object to strip away the tenantId part. However, if you do that, then you would have to somehow figure out which tenant an email belongs to before using that email to query some info from supertokens. So perhaps it's best to not modify the recipe functions at all.

@User ^

amazing, thank you again @User

One annoying part about using us with AWS lambda is that each lambda function would need to be an express app (as shown in the docs).. not sure if you would be OK with that. But we are working on making the node SDK independent of express and would be able to support AWS lambda's context object natively. But that will take a few days to 2 weeks maybe to launch.

yeah, I was just looking at the

supertokens-node

repo, wondering how much effort it would be to make a

supertokens-serverless

fork, without express, and including a Cloudformation with APIGateway or similar to replace the express aspect of it. Alternatively, I think actually the entire supertokens backend might even be able to sit in a Lambda Layer, so that each Lambda execution should already be initialised beforehand, based on environment variables. This would drastically reduce the cold-start time, if each API endpoint on the backend was an independent lambda

doing so might allow you to put ST on the AWS Marketplace, giving an extra source of revenue, perhaps

So have a look at this: https://github.com/supertokens/supertokens-node/blob/req-res-wrapper/lib/ts/framework/awsLambda/framework.ts It's the release we will be doing very soon. In this, the actual core logic uses an abstract request / response class, and we implement this class for AWS lambda / express etc.. The above link is for AWS lambda.

oh nice!

> Alternatively, I think actually the entire supertokens backend might even be able to sit in a Lambda Layer You mean the core and the backend SDK stuff? Or just the backend SDK stuff?

I think the backend SDK would sit on that. Not sure of the best way to get the core serverless, though. Most of the devs at my workplace are Java devs too, and we're migrating to a serverless architecture. Lambda etc supports Java, but the cold start times on many applications can be debilitating. We have a Proof of Concept lined up to try https://quarkus.io/guides/amazon-lambda for some Java, to see if that helps, but we haven't got any results on that yet

I see. So you can give us a shot for now with the express style lambda function (I know, it's not ideal..), and if you like it, when we release the new SDK version, you can move to that 🙂

> including a Cloudformation with APIGateway Would this help setup the API Gateway config automatically for each new API? Cause right now, in our docs, we expect users to set the proper CORS setting per lambda function manually.. and AWS doesn't make that easy haha..

We're happy to wait for now. To give you an idea where we're coming from, and why we're looking at ST: We currently have a java monolith with Spring Security, but are building a new product to eventually move all our clients to our scalable serverless infrastructure. We're heavily invested in the AWS infrastructure, and so AWS Cognito was the obvious choice. However, as we're multi-tenanted, there are some serious pitfalls there, such as only being able to have 4 custom domains for the front-end auth pages per AWS account. If you want more, you effectively need to rebuild the whole OAuth Flow to have your own pages. Yikes. Came across ST from some older reddit posts, and it looks like it may meet all of our requirements from a feature perspective. We'd probably opt in to being hosted by you if multi-tenanted out of the box (currently ~650k MAU), except we have around 50% of our users in Australia, which is a region you don't currently support. Regardless, we're still at an investigation / PoC stage, so it's likely to be several months until we have any real production users on the system. We just see Auth as a pretty foundational element of the app, since we'll also be doing custom authorizers on our other business lambdas to check token validity etc. It's one of the things I wanted to make sure we get right early

Makes sense!! About the region support, we can add a new region in 2-3 days time.. not a big issue 🙂

Yeah, so internally we have several APIs which we define in swagger, and used by Cloudformation. This deploys the Lambdas, the API Gateways and sets the CORs as required

there's also the serverless application model (AWS SAM) which is an abstraction of Cloudformation, and is a bit less verbose / tailored towards serverless apps. We're beginning to use that too

I see. That's cool. Will check that out and provide one.. if you end up using us, and make one for us, you can contribute that back to OS somehow.

sure thing. I'll keep an eye on the repo. Once you have the req / res stuff all in master, I'm pretty sure I'll be able to knock up an example for you

ok great! If you do try us out before the release and have more questions, feel free to ask them here.

@User , one correction from what I had said previously: For the backend, you would not need to call the

init

function just once per lambda function load (which will solve the cold start problem for 15 mins since the lambda function would be alive for 15 mins). You would instead have to provide some callbacks in the init function which determine the tenant's website domain (for email verification + password reset links). Like here: https://github.com/supertokens/supertokens-auth-react/blob/master/examples/with-one-login-per-subdomain/api-server.js