https://supertokens.com/ logo
Join Discord
Powered by
Hi! Been doing some research on auth services and ...
# support-questions-legacy
h
Hi! Been doing some research on auth services and I'm growing close to deciding between a few, one of which is Supertokens. Though I wanted to know why it matters what DB the Auth Service is using. Would it be difficult to migrate to a new auth provider if we're using a different DB than what the auth service is (i.e. us = mongodb, auth service = postgresql/mysql)?
r
hey @heneftees
we do not sully support mongodb yet.
h
Hey! Hope you recognize me from my last email with you :)
Yeah I understand but based from our last call, it would be feasible to migrate with you if we upgraded to a managed service?
r
that is correct.
with our managed serivce, you don't need to use psql / mysql since we manage that part for you.
and if you want to replicate the user info in mongo, you can do that via the post sign up override
> Hope you recognize me from my last email with you 🙂 Im sorry, but i don't recoginise the username you are using 😦
h
No worries! > and if you want to replicate the user info in mongo, you can do that via the post sign up override Could you help shed some more insight?
I understand that we have to call an endpoint to transfer our current users to your database
r
> Could you help shed some more insight? Have a look this doc: https://supertokens.com/docs/thirdpartyemailpassword/common-customizations/handling-signinup-success Essentially, post sign up, we give you the user ID of the user, and you also have access to the user's email + any other form data based on your sign up form. So you can store that in mongo if you like.
> I understand that we have to call an endpoint to transfer our current users to your database Yes. See https://supertokens.com/docs/thirdpartyemailpassword/migration/account-creation/user-creation
h
Just to help line up the flow: 1) User calls the same endpoint for logging in 2) We change the logic in that API where we call your endpoint to authenticate the user instead of checking it ourselves 3) Proceed with other business flows in our current API
r
Same endpoint as in the one that they call right now (i.e. the one you have in your backend right now?)
h
Yep. Lets say /users/v1/login
r
that is certainly possible. However, we recommend that the user call the endpoint that we have exposed via our backend SDK, and then you can override that to add custom logic post sign in / up. This is cause if you need features like automatic account linking, or MFA, then our API has a lot of security checks built in.
But yea, in the simplest case, you can just call our backend SDK's signUp or signIn function in your existing /users/v1/login endpoint if you like.
h
I see. Would migration be heavy on client-side as well? As much as possible, we don't want to have too many changes across our different platforms and just focus on backend changes to migrate with you :)
r
it doesn't need to be heavy. You would have to change the frontend to call our APIs instead of yours for login / sign out etc. The UI can remain the same. However, if you want no changes to the frontend, you can just change your backend APIs to use our backend sdk functions. Really depends on what you need
We are quite flexible in terms of how "deeply" you want to integrate with supertokens 🙂
h
Thanks so much for the clarification! > However, we recommend that the user call the endpoint that we have exposed via our backend SDK, and then you can override that to add custom logic post sign in / up. Does this mean changing the frontend to call your APIs instead?
r
yup
h
Gotcha! Hmmmm if we were to spin up supertokens in an aws lambda, how would the flow look like generally? https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html https://supertokens.com/docs/thirdpartyemailpassword/serverless/with-aws-lambda/backend-config This is what we're taking a look at :) Would really appreciate if you could help me get a high-level understanding of possible changes on our side
r
yup sure
so, the aws lambda would integrate with our backend sdk as shown in the docs
our backend sdk provides a middleware which exposes the auth apis (sign in, sign out etc) to the frontend
the frontend would call these apis and get back a session (access and refresh tokens) post successful sign in
you can then use the acccess token to send to your app's apis to identify the user.
any customisation to the auth endpoints, like post sign up operations, would need to be added to the aws lambda code via our backend sdk's override feature.
so on your end, if you want t o go down this path, you would have to change: - your frontend to use the new auth APIs exposed by the aws lambda - Integrate our frontend sdks on your frontend clients for session management (like auto session refreshing) - change your app's APIs to do jwt auth via the jwks endpoint exposed by the aws lambda
this would essentially be the deepest integration.
Another option is that you keep your existing APIs, existing session solution, and just do credentials verification by calling the supertokens core (either via API calls or via our backend sdk functions) in your existing app's apis. In this flow, you don't need to use the aws lambda approach.
h
Huge thanks for the explanation. Would there possibly be an available time now to discuss further via call? Structuring the possible implementation as we speak, and think I could help save your time off-chat!
r
yea, sure!
h
general voice channel?
r
h
thanks for the help! :)
Just in case, no need to send that recording over! Have it saved on my end, thanks again~
r
great!
h
@rp_st Frontend is quite resistent to change currently, adding the SDK would be quite a refactor. but seems it's still possible to have the backend SDK spun up in an AWS Lambda and not integrate the frontend SDK in the client-side -- as long as we handle these sessions properly, then should be okay?
r
Yup! Absolutely
h
Cool, thanks so much!!
@rp_st In the context we're speaking of, the primary purpose of having the backend SDK in an AWS Lambda is for the auth APIs exposed by the middleware right? Im a bit confused as to why this section would exist (see screenshot). If im not mistaken, its more of if your existing API sits on an AWS Lambda and you happen to integrate backend SDK there right?
r
Yup. That’s correct
h
gotcha! thank u
6 Views
PreviousNext
Powered by