• taijuten

    taijuten

    1 year ago
    My other question regarding above, IF the dynamic config is possible, would the database still be an issue? E.g. needing a DB for each tenant?
  • taijuten

    taijuten

    1 year ago
    Finally (sorry for the questions), I may be missing something in the documentation, but I'm not able to see a list of currently supported third party authenticators. Most of our tenants would use the "vanilla" authentication (email password), some would opt in to social, but some would also want authentication with their OAuth server. Is this something that's possible & documented?
  • taijuten

    taijuten

    1 year ago
    Much appreciated, and sorry if any of this is already documented
  • r

    rp

    1 year ago
    @User
    Does SuperTokens handle multi-tenancy in any way? In terms of the backend: You can run one supertokens core per tenant, and connect one backend node process to one core. You would hence need to have one backend node process per tenant as well.
    In terms of the frontend, it's pretty flexible in the sense that you can have one common login for all tenants or one per tenant. It seems like you would want to go with one login page per tenant, so that should not be a problem.
    I assume we may be able to simply adjust the config.js to pull in relevant config data, though only if this is read in per-request rather than on lambda init. You can call the supertokens.init function when a requests, but how will you know who is querying in the first place (since you can't do session verification without calling the init function)? Will you be calling the init function based on the origin header in the request?
    IF the dynamic config is possible, would the database still be an issue? E.g. needing a DB for each tenant? We don't have a tenant ID in the db schema. So you would need a separate db / scheme per tenant.
    but some would also want authentication with their OAuth server. Is this something that's possible & documented? Yes. We can integrate with an Open ID connect provider via the authorisation code grant flow. See
    https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/signup-form/custom-providers In built providers are google, fb, github and apple. But as said above, you can easily add any provider.
  • taijuten

    taijuten

    1 year ago
    Ah I see, so the front-end and back-end can be deployed to an AWS Lambda, but the core is still deployed traditionally, via docker or similar. And one backend & core would be required for each tenant (or user pool, in the normal sense). I was hoping I would be able to set up in the following way: 1) Many front-end via AWS Lambda, one for each tenant, each with their own CDN / Domain (set up independently of supertoken). Submitting a hidden form-field or similar for a 'tenantId' 2) I adjust the backend
    config.js
    for lambda to grab the appropriate appInfo etc for the tenant, from a dynamoDB table I set up 3) There was some way to either namespace the records in the DB by tenant, have a table per tenant, or specify a table name in the
    connectionURI
    within the
    config.js
    on a per-request basis I realise the use case isn't too common though!
  • r

    rp

    1 year ago
    1) This is possible 2) This is possible too, but how will you know what config to load before session verification? 3) Each core would need to connect to a db. You can connect them all to the same db, and rename the table per core (via the config) to be per tenant.
  • taijuten

    taijuten

    1 year ago
    re: #2, it's very possible I'm missing a key understanding of the process. I was thinking I could:* use the
    tenantId
    submitting from #1 to lookup the configuration in dynamoDB* use the above configuration to fill in the appropriate tenants appInfo etc in
    config.js:getBackendConfig
    (under the assumption I could get this to run on each invocation of the lambda function)* proceed with the rest of the backend behaviour, such as session verification
  • r

    rp

    1 year ago
    Yea! that would work.. you would just need to call the
    supertokens.init
    function inside the lambda function as opposed to outside it!
  • taijuten

    taijuten

    1 year ago
    Thank you very much, appreciate your help! So to summarise, for a serverless(ish) multi-tenant (user pool per tenant) solution:* Front-end template can be adjusted to submit another form-field for tenantId * Backend
    config.js
    can be extended to get
    appInfo
    etc based on the tenantId passed in* Core needs at least one instance per tenant, but can share a DB server (e.g. aurora serverless) in order to reduce surplus infrastructure, if each uses a DB table named after the tenantId Possible Feature Requests If I may be so bold, and if the "user pool per tenant" architecture is something you're interested in supporting going forward, the following additions to SuperTokens would really help: In an ideal world, it would be great to be able to get the Core into a Lambda too, and have it capable of having a single core deal with multiple tenants. E.g. dynamically switching the table based on an optional request header, or similar. From a similar perspective, the ability to have a dynamoDB integration rather than mySQL would be great from an AWS serverless perspective, due to not having to have a MySQL server running at all times
  • r

    rp

    1 year ago
    So to summarise, for a serverless(ish) multi-tenant (user pool per tenant) solution: That makes sense!! If you run into issues, lmk.