How can I have a distinct login & registration experience without custom UIs?
This support post is in relation to https://discord.com/channels/1070212618549219328/1308179325752705145 as to not confuse or deviate from what the OP of that thread was after.
Currently for registrations I am using Kinde's out of the box registration experience with a twist. I basically ask a few questions, store the answers, and then kick off Kinde's out of the box registration workflow. Once registration is completed I resume the process with follow-up questions before completing my applications setup which includes storing details (including correlating the Kinde data with my data) and setting up the organisation using Kinde's Management API. (I don't want to just auto create orgs)
This is great because by using Kinde's out of the box workflow I don't need to write code to log in or register. But I can still have custom activities before and after the Kinde part of the process.
However, if a user were to click log in, and then register on the Kinde UI they would have been registered in Kinde but not through my onboarding process resulting in an incomplete setup. Now, I could potentially detect this when signing in and get them to have a slightly different onboarding experience but then I'd need to maintain two different onboarding workflows both in terms of code, but also customer support.
As per the advice Yoshify gave in the original thread, you can disable self sign up, but then Kinde's registration functionality will return a 404 (not found / supported) error.
Is it possible in the brand design screens to somehow remove the register button from the login experience?
11 Replies
It sounds like what you're asking for isn't supported by Kinde out of the box, but it is possible (and it's actually what I do for my app!)
I keep signups enabled, but store a custom boolean user property attached to the user called
onboarding_completed that defaults to false. The following really depends on the framework and language you're using - I'm using a NextJS app. In my applications root layout I check to see if onboarding_completed is true - if not, they're redirected to the onboarding flow where they answer the questions we need for our application - at the end of the onboarding flow, I set onboarding_completed to true then redirect the user back to the application.
This way is kind of the best of both worlds approach - I originally tried to approach it like you did and tried designing custom registration flows but social signups become a PITA, and you end up with a lot of duplicated data (I prefer to keep auth related data in the auth provider, your opinion may differ here).
What this results in is no-one can use the application until they've answered the questions we need to give them the appropriate experience. It sounds like this may work for your case as well, but may require some restructuring of code (asking the questions after sign-up instead of before). Does this help?Thanks Yoshify I expected that was going to be the answer. Like you, I prefer to keep auth / identity data with the identity provider being the source of truth / separate and I might need to do something similar. At the same time I might ping Kinde to see if they can support just disabling the register button as a configuration option in their Brand experience as it seems that would be a pretty simple way to solve the problem without needing to do what you needed to do. In my case I don't care if someone directly calls
/api/register as my app would know they haven't completed the official onboarding experience and block them anyway. I'm just trying to prevent geniune user error.Good idea, might be valuable stashing that in #💡┃suggestions - there's also a Kinde roadmap item for Custom Forms which may make onboarding flows even easier that should come in the near future given its position - https://updates.kinde.com/board/custom-forms
Custom forms
Custom forms
I'm going to steal your solution it's awesome !
Works really well for me, let me know if you have any questions about the details @IkiTg07 🙂
When you say you let the auth data within the provider what do you mean ? I’m working on a SaaS and I’m wondering if using kinde to manage everything user related + billing tier (free, pro, premium) would be viable and how to set it up
It depends on how complex the data you have related to a user/org is, but to seperate concerns I prefer keeping Kinde as my source of truth for user/org related data - everything I need to store about that user or org is a property (stripe customer ID, various onboarding details, etc)
Some people may prefer to go the webhook route and keep a copy of their Kinde data in their database and work off that instead - I did this for another project I was working on and it works great, but it does feel a bit redundant keeping two sets of auth related data when you could just keep it all in Kinde 🙂
My issue with duplicating the data also is about performance because i feel like if I can get everything i need from just the id token then it's better than doing a full round trip ?
Absolutely - but storing the data may let you do more complicated queries within your database, and some people prefer "owning" their data in the case that they want to transition to different auth providers
Yeah I can see that. But thanks I'll look at your way of doing things especially using properties. I feel like without the billing feature it might be tricky to make a subscription structure work using only kinde's user data and features
The way I do it is the primary key of my subscriptions table in my DB is the stripe customer ID and that contains everything related to a customers subscription like tier, renewal date, etc.
I store just the stripe customer ID in Kinde. Works great for me.
I'm quite excited for Kinde's billing, but my products in Stripe are quite complicated, so I don't think V1 of Kinde's billing will support the things I need like overages on metered events. But from early looks it'll probably work great for basic subscription/seat based SaaS products!
Feel free to reach out to me in a DM if you want to chat about this stuff further.