Show HN: Kinde – auth, feature flags and billing (Q3) in one integration
kinde.com
kinde.com
I started building web apps before Auth0, Okta and friends arrived on the scene so I never considered until recently having someone else manage my authentication concerns. Identity is very important in most web applications so I was wondering what value a CTO gets from allowing someone else to manage it.
For example, I would be concerned about prices suddenly being increased or what happens if the business we relied on failed, lost accreditations, or suffered a serious security incident. Presumably there isn't a migration workflow away from these products, save for asking your customers to perform a manual action.
While clearly these services are very useful and popular, I just can't shake the feeling that it could be a very good way to get started, but a long term strategic mistake.
I was wondering if anyone from Kinde or with experience using these services long-term has any thoughts on this?
I have no experience with this sort of thing, but would like to understand.
Kinde has a self-serve export tool baked in as we believe it is important for people to be able to change provider freely and not have vendor lock-in. We also have a self-serve import tool for organizations and users including hashed passwords so there is no disruption to the end customer
I'm guessing the password hash format is something like bcrypt2? Is there an API for that? The feature quite nicely mitigates a situation where prices are unreasonably raised, but to mitigate a rug-pull event such as a business failure, malicious action or serious technical failure I'd probably want to automate this.
If that sounds like I'm sort of paranoid, it's probably because I am. I do this with all my company's cloud data.
It was a huge issue with Auth0 recently when they were bought by Okta. We've spoken to customers who have had their prices increased 2-20x virtually overnight with no forewarning and they've been forced to go through a process with customer support in order to get access to their user base and move off.
I'll get someone from the team with a better understanding of the password hashing to get back to you on this but I believe it's bcrypt2.
As Dave mentioned we're trying to make it as easy as possible to get your users out. I'll chat to someone from the team about the automation, it's an interesting idea
The self-service export is UI driven at the moment, as exporting passwords requires approval from an additional owner/admin for security. We could definitely extend this to be initiated by API though
Personally, I would rather manage it myself. I have found an open source system called Ory which allows you to fully customize the identity, federated identity support with other components (ie, act as your own IdP), highly scalable, offers ACLs, support for multi factor authentication, social login, and can fully customize the login experience to your liking.
I manage the deployment, upgrades, and monitoring through a series of helm charts and k8s. Their system is so efficient it can run entirely on a single node k8s cluster (ie, dev machine with minikube). Not going to lie, it’s definitely a lot of work but worth the trade off. No longer have to burn $$$ while testing simple flows in my apps.
In many applications identity is not the main part of the business. Once you're up and going you can devote time to identity management.
Obviously there are Open Source projects and libraries that do the same thing, but usually these companies have better docs and dashboards. So the value is just decreased initial cost at the expense of a possible outage or eventual disruption, but these things happen with any external provider, you just have to make the cost/benefit analysis.
A bit like e-mail: e-mail is usually a crucial part of the business too, but nearly no one manages their own e-mail service nowadays.
> A bit like e-mail: e-mail is usually a crucial part of the business too, but nearly no one manages their own e-mail service nowadays.
I liken it to a database. Most people use databases in their apps. Some people use a fully managed proprietary solution (graph db, dynamodb), others use a managed solution that conforms to a given standard (managed mysql/postgresql). Some people run databases themselves. But very few people would build a database from scratch.
Auth is much the same. You have a spectrum of needs, based on how much control you need. SaaS solutions get you functionality faster and with less maintenance while giving you less flexibility. Self-hosted solutions let you leverage the efforts of the OSS community or vendor while still maintaining operational control as well as data sovereignty.
Only a very few folks should write their own auth, it's a solved problem with lots of good solutions out there.
It's very nice to externalize that liability/risk as much as you can. Hopefully standards like Passkey will help make that much easier to do without third party middle providers like Auth0/Okta/et al.
> Presumably there isn't a migration workflow away from these products, save for asking your customers to perform a manual action.
In my experience most third-party auth providers give you email addresses and correlating accounts by email address often does 80%-90% of the work. You can often script adding all your current user emails as users in the new system and give them unset/invalid passwords. You just can't prevent the need for manual password resets under the new auth provider, but often that is the only manual step and it is a common "Forgot Password" workflow so it will feel familiar/easy enough to most users.
Regulators love to remind: you can't outsource your risk.
Your firm is accountable if customer data is stolen, which is what would happen if the passwords are compromised.
Even if it's "only" lost creds, your firm will still absorb the full "reputation risk" hit. No customer or reporter is going to say "well, but you didn't really lose your customers' passwords, it's the third party provider you chose." They'll hold you accountable.
That said, using a "Sign in with Microsoft" button means some 70%-80% of SMBs can use you without you having to have or outsource their creds, since they can just sign in as their emails/passwords from O365. For most of the rest, "Sign in with Google" picks them up. And, of course, get a majority of US consumer "wallet share" with "Sign in with Apple".
A small (and big) business sign in page would look like this (maybe without the GitHub):
https://login.tailscale.com/login
As another example for consumer logins, with FB, Discord, Twitter, along with the business domain logins:
https://www.xsplit.com/user/auth
The important one for small businesses trying to be compliant would be Continue with Microsoft for 0365 companies, while Continue with Google also gets you everyone in Google Workspaces.
"Real" SSO option could come later, as shown above Tailscale doesn't even have it. But these buttons are SSO as far as the typical user is concerned.
By using the logins the business users already have, nobody has to store creds for your B2B users but themselves.
It might be difficult now, but it will only get more difficult as time passes.
We're building a one stop shop for new SaaS products. Integration takes a few minutes and our current record time is 1 minute 52 seconds for a first time user.
Current features: - ISO certified secure auth - Connected apps (Drive, Github, Gitlab) - Custom branding + domains - 14 SDKs (incl. react, nextjs, etc.) - Azure + 8 social SSO options - Organizations and multi-tenanting (b2b2b & b2b2c support) - MFA w/ OTP generators or SMS - Passwordless sign in - Basic feature flags (full release management suite coming) - Completely customizable flows - Request access forms
Also on the way - Billing (Q3) - Release management suite - Experimentation - Marketing and lead gen
There's heaps on the way. Check it out and let us know what you think
Some things we find missing at Seam (we use both Clerk and Auth0 on different apps):
1. Inability to change email or reset password without using "privileged" API, would love to redirect users to a Kinde/Clerk/Auth0 page to manage their profile
2. Ability to store secure secrets into a user with auditable access
3. Difficult in-app login
Could you expand on what you mean by difficult in-app login with Clerk/Auth0?
- Auth0 (up to 7000 users, if I can read the comparison page right)
- Supabase Auth (50,000 MAU).
The driving factor we're pushing for going forward is to bring all of these dev products (auth, release management, billing, experimentation) under one roof. You'll only have to integrate once and from there on out every other feature is a single line of code.
That way you can manage your users in the same place that you manage your subscriptions, release beta products to a very specific set of users etc. all in one place.
Also, congrats on launching. Best of luck in capturing the market you're looking for.
- "ISO certified secure auth": What does that mean? I could not find proof of your ISO certification. Can you please share?
- 10k M2M tokens for $250/month sounds like a really bad deal if I can just spin up https://github.com/ory/hydra that can easily handle 10k requests per second.
- Looks like you're using OAuth2 as the primary "login" and "session management". What compelled you to do this?
- It looks like you're using some open source technology under the hood for the OAuth2 flows - which one are you using (out of curiosity)?
And finally, what sets you apart? It looks like the same solution for the known problem that big players (such as Okta and Auth0 - publicly traded) have already mastered. Ory (github.com/ory) for example has it's global network approach where you no longer need datacenter locations and is Open Source. Clerk is targeting React devs. What's your niche? Doing everything from auth to billing is, in my experience, way too much for a small team with little resources. Just getting Auth right is a mammoth task.
Spinning one up is easy, sure. Making sure it's production ready, is not so much.
You can find details of our ISO and other certifications on our compliance page: https://kinde.com/docs/important-information/compliance-cert... we're also happy to provide a copy of the certificate if you reach out to support@kinde.com.
In terms of pricing, 10k M2M tokens are included on our $25/month plan (as well as many other features) so no need to spend $250 :) We feel this is a fair value exchange for everything being offered on the plan. Of course, there is always the roll-your-own option and great open source solutions like Hydra and that's awesome too for people that are confident going down that path - but it's not for everyone.
The great thing we have found about going the OAuth2 route is that you are free to use Kinde with any library that supports OAuth2. We also have SAML available as an auth option.
There is no denying there are a number of great players in the auth space but this is really only the start for us. We’re an experienced team aiming to help create a world with more founders by bringing together the fundamentals of product development. The fact that we’re small means we’re able to move quickly. We’ve just shipped v1 of feature flags and have more exciting offerings to come!
Multi-tenant (each of my customers gets a fully separate directory, with access to all tenants for our admins)
SAML and OAuth (customers can set up SAML themselves via the SaaS interface, or we set the SP up for them)
Rule based group assignment based on SAML attribute evaluation (e.g. assign users to this group if the attribute X = Y)
APIs to manage users, groups, organisations (tenants)
We've built something using Okta, but all our customer users are in one Directory/Tenant.
Auth0 nearly gets there with Organisations but can't help with the sub-groups and rule based management.
For context, we have an education product and customers are districts or schools, and the sub-groups are typically schools and/or classes or groups of users (e.g. seniors or juniors).
We also need to support SAML Federations like InCommon, OpenAthens, UK Access Management Federation which makes the challenge harder (these federations want a single SP to which many IDPs authenticate) for Universities. None of the modern platforms support this.
If anyone has found an out of the box solution for this, I'd love to hear about it.
If it would:
a.) Perform group assignment based on SAML attributes (like Okta's group rules), and, b.) "natively" support SAML Federations used in the Higher Education space (which Shibboleth appears to be the only thing that supports)
I'd sign up tomorrow and start migration of my 150k users.
Would love to know what particular things FusionAuth lacked, or what is a dealbreaker. Based on your requirements, I didn't see any issue, but maybe I'm missing something?
My email is in my profile if you'd prefer to use that.
I think it checks all your boxes :)
Note - Warrant is an authz engine so it doesn't handle authn/identity/SSO but can plug-in with any authn system.
> Multi-tenant (each of my customers gets a fully separate directory, with access to all tenants for our admins)
Yup.
> SAML and OAuth (customers can set up SAML themselves via the SaaS interface, or we set the SP up for them)
You'd have to build an interface using our APIs for this. Not available out of the box, but we do have it in the general roadmap (https://github.com/fusionauth/fusionauth-issues/issues/91 is the tracking issue).
> Rule based group assignment based on SAML attribute evaluation (e.g. assign users to this group if the attribute X = Y)
You could do this with Lambda HTTP Connect (a paid feature) or webhooks (a free feature. https://fusionauth.io/docs/v1/tech/lambdas/#using-lambda-htt... has more
> APIs to manage users, groups, organisations (tenants)
Yup.
> SAML Federations like InCommon...
Hmmm. We have an open issue for supporting this, but I'm not sure what is involved. If it is straight SAML, it should work, but SAML is pretty ... multi-facted so testing would be needed.
The SAML Federation one is where all the modern SaaS fall short. Its still SAML but it involves:
All the metadata for 100s of IDPs being downloaded and made available to enable
Publishing the SP metadata to the federation(s) which may involve fees.
Specific rules around metadata (attributes) being released and adhered to.
And if your directory insists on having an email addresses for a user, that might be an issue.
There's a reason why Higher Education businesses have cropped up around doing SAML Federation.
I have had a trial of FusionAuth, and it was great, just didn't solve enough of our pain points to justify a migration.
Sounds like the SAML federation is pretty education focused, so maybe FusionAuth isn't a good fit. Maybe something more open source like Shibboleth would help? Seems like a tough spot, hope you find something.
I went to a talk by Heather Flanagan[0] about how the browser third party cookie changes are going to impact the education space, and the education sector does have some special requirements.
I will say that we do sometimes move items on our roadmap around and can prioritize certain features. This requires a customer to commit to contract of a certain size, of course. Our sales people would love to chat if this is you :) .
I am really curious to hear more about what a good solution there looks like to you?
For us we've built out auth, and now the next step is billing and release management. Once you have these different factors in one place you should see heaps of benefits
It’s missing “billing” compared to Kinde but that’s something I can add with another open source tool — Lagos.
Good luck. I can see the value in startups using this in the short term to quickly get something to market without burning their capital but in the long run it would be better to manage it yourself with good open source tooling.
Also I keep reading the name as Kindle
Obviously a bit of a concern for us if you were struggling, would be keen to hear more
How did you make it?