Hello,
I’m building a SPA app with SolidJs, I would like to use Stytch, but I have a question about the flow to enable on my app / api.
I see on the doc, that I can use the Javascript SDK to execute an Oauth flow, and I also see that I can directly authenticate my user on the frontend.
I also see that the node sdk provide an authenticate method to authenticate the session after a succeful Oauth flow on the backend.
Should I authenticate only on front-end or backend ?
I’ll admit, that I would like to keep my api out of “redirect logic” if possible 
Hey Kevin,
Thanks so much for posting!
Should I authenticate only on front-end or should I provide a callback url on my api ?
I’ll admit, that I would like to keep my api out of “redirect logic” if possible !
There are definitely several ways to integrate here, and I can definitely understand wanting to keep redirect logic out of your backend! 
The exact integration pattern can depend on your requirements and current stack, but the general guidance we’d give here is that you can handle authentication on the frontend, and additionally protect any backend routes that you’d like to require an active session for by authenticating on the backend as well.
What this might look like in practice here is:
- Utilize the frontend SDK to manage OAuth flows (and any other authentication flows you’d like to use)
- Once your frontend recognizes an active Stytch session, allow the user access to logged-in content (you can leverage the
useStytchSession hook for this)
- For any actions that require a call to your backend where you’d like to enforce authentication, embed Stytch session authentication into that backend route.
On that last point, our frontend SDKs automatically include the Stytch session_token and session_jwt cookies in calls to your backend (as long as they share a domain). You can read more about this paradigm and see some example code snippets for backend session authentication in our documentation here: Cookies & session management | Stytch JavaScript SDK.
Our NextJS example app also demonstrates this for session tokens as well as for session JWTs for some additional reference material (you can read a bit more about the differences between session tokens and JWTs in this blog post as well).
I hope this helps - definitely let us know if you’d like to talk through any specific circumstances you’re thinking through and we’ll be happy to help!
@matt-stytch Thx for your quick answer
So my auth strategy is as follow:
- At the beginning, I want to be the only user of my app, so I used to (with my previous auth lib, lucia) restrict access only to a specific email (mine).
- Then when I’ll be ready to open up my app, I want to invite only specific users.
So for my first point, should I use a simple email / password auth flow instead of Oauth one ? (even so I love sign-in with social provider, since I don’t have to handle reset / forgot password, and the ease of use).
And does Stytch propose a solution like “whitelist” in order to prevent access to only specific email ? Or should I implement it myself by filtering out user after stytch redirect to my api, thus, do my MAU count will increase if a user succeed a Oauth flow but I don’t authenticate the session ?
Last question, you said that cookies are passed if my app and api shares same domain, do you mean the same root domain ? Is it still working if my app and my api are on a different sub-domain (eg. x.example.com, y.example.com) ?
Finally, for my second point, I see that I can use the invite magic-link option from Stytch to achieve this, so I’ll look at this option when I’ll be ready to open up my app to users.
Best regards,
Hey Kevin,
We ended up discussing this in our community Slack as well, but I’ll respond here for posterity and in case anyone else has similar questions!
So for my first point, should I use a simple email / password auth flow instead of Oauth one ? (even so I love sign-in with social provider, since I don’t have to handle reset / forgot password, and the ease of use).
…
And does Stytch propose a solution like “whitelist” in order to prevent access to only specific email ? Or should I implement it myself by authenticating the session on my api after Oauth flow and then redirect to my app ?
We definitely see a strong user preference for OAuth flows over password based flows as well. As discussed in Slack, there are a couple of ways to go about this - your current solution of checking the email address against your own list of allowlisted/invited email addresses, and revoking the session and deleting the Stytch User if it doesn’t match the list, is a valid approach here.
Another approach is to prevent sign ups via redirect URL behavior. I’ll post our response in Slack for posterity!
We generally recommend splitting behavior for logins vs sign ups is via the redirect URLs you’ll pass into the /oauth/start endpoint.For instance:
- Set
login_redirect_url to myapp.com/auth/type=login
- Set
signup_redirect_url to myapp.com/auth/type=signup
And on the route handler (like in the code snippet above), parse our the type query param and split the application behavior depending on the type.In this case, you might want to do the same thing as when checking against your own email, e.g.
if (type == “signup”) { await stytchClient.sessions.revoke({ session_token: res.session_token }) await stytchClient.users.delete({ user_id: res.user_id }) return forbidden }
or something similar.
Last question, you said that cookies are passed if my app and api shares same domain, do you mean the same root domain ? Is it still working if my app and my api are on a different sub-domain (eg. x.example.com, y.example.com) ?
Cookie sharing with subdomains is configurable via the SDK Client options: Client options | Stytch JavaScript SDK, specifically the availableToSubdomains parameter. Note that if you want cookies to be available at both x.example.com and y.example.com , you’ll need to initialize the SDK client on example.com - cookies can be shared among subdomains of the root domain, but not sister domains.
Perfect I have everything I need, thx for your availability and your quick answers.
Have a nice day,
PS: If someone encounter the same problem or have any questions, I can share the workaround I found here for posterity 
Awesome, thanks Kevin – we’ll be happy to help if anything else comes up in the future!