I have a question, although it's not about this product in particular.
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?
One view of it is that owning a database of passwords is a massive liability in 2023. Both in the cost sense and the legal sense. Building/maintaining/securing it costs more than most people want to think it does (especially if you need to pay for regular external audits, which is mandatory in some industries). The legal risks if that database falls into the wrong hands are enormous. (There are plenty of class action lawsuits every year when breaches of passwords are discovered.)
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):
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.
This kind of service helps you get off the ground much faster. Adding a few social logins, plus email/password, plus MFA is not necessarily slow but it's not fast when you have to create the whole backend.
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.
Disclosure. I work for an auth vendor, FusionAuth.
> 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.
The value is always decreased costs in managing itself, “cleaning self of security breaches” but like you said the trade off is that it’s a single point of failure. If that company becomes defunct or a security issue arises (ie, poorly implemented specs or malicious employee) then your company is now racing to migrate off.
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.
It varies from provider-to-provider. With Auth0 you have to install a plugin from their marketplace to get an export. If you want the hashed passwords exported you have to email their support team and they pull it together for you - usually takes about 2 weeks.
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
That's really good and thanks for responding to the question. I think I could be tempted to try a service like this for a future project.
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.
Trust me when I say that we're paranoid about data too. Our security specialist was the second hire.
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
That's right, bcrypt2 - we also upgrade imported users passwords to this more secure hashing algorithm if they were previously using something less secure like md5. This is all done transparently on their first login with no impact to the user flow.
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
I find it somewhat annoying to see the intense community pressure to go with third party auth providers. I see auth, user and role/permission management as a core pilar of an online business and would think long and hard before handing this over. I realize doing this yourself requires a big investment in studying proven security practices and finding well established libraries, but I think it's well worth it.
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
I don't mean it in a bad way but I scrolled through the website, watched the video, and still don't really know what is the product/service/offering and when would I need it.
It's a drop in authentication system. You would need it to have users and logins for your app. Or you have to write and maintain your own. They say billing is coming so I guess it crosses the line into subscription management. I'm using auth.js with extra code for the same thing. That's been a revolution compared to wiring it all from scratch. Without subscription revenue (i.e. Just using this for accounts and auth) I couldn't justify the $75/mo needed for active directory SSO. But watching the demo video, I'd love to have a project with the financials to justify using Kinde
Yep, but you'll find with a lot of them the features are incredibly limiting on free plans. It's the same virtually anywhere in terms of having a free tier, so the issue becomes pricing on higher plans. We come in significantly lower for the same feature sets
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.
Thanks! That's a perfect explanation. Exactly right with the subscription management on the way, similar to linking up Auth0 with Chargebee in one product.
No problem - we're relaunching the website in the next few months so hopefully that'll be a bit clearer. At this stage the closest comparison would be clerk.dev!
Congrats on the launch, building a product in this space is incredibly difficult. I took a look at the stack, here are a few observations:
- "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.
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!
> 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.
Spinning one up is easy, sure. Making sure it's production ready, is not so much.
One of the things my business needs, but I cannot find a SaaS solution for is:
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.
> 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.
Yeah, we're looking at webhook type solutions but that puts the clever stuff "outside the box" which we're paying for. Okta's group rules do exactly what we want but we can't do the multi-tenant stuff and it doesn't do the SAML Federation side of things.
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 :) .
Hey! Full disclosure I work at PropelAuth, and unfortunately it doesn't look like we would meet all these needs, which is a bummer since it looks like we could help with most of it (multi tenancy, UIs for your customers to set up SAML, etc). We have the same problem as Auth0 though, and don't currently have sub-groups within organizations out of the box.
I am really curious to hear more about what a good solution there looks like to you?
Thank you, will keep an eye on it. Auth0 is definitely the closest I've seen to what my business needs (and I've spent waaay to much time one trials and demos of too many products so far).
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.
What we're building at Warrant (https://warrant.dev/) might work for a lot of what you mentioned including APIs to build and manage multi-tenancy, groups, users, orgs/tenants.
Note - Warrant is an authz engine so it doesn't handle authn/identity/SSO but can plug-in with any authn system.
Unfortunately not. It's capabilities are good but missing the same as the other popular options. So it can do everything our current platform can, but we need extra "stuff" to justify the migration.
I work for FusionAuth and responded to your comment elsewhere.
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'm going to be building out a SaaS soon, and expect to be doing a lot of SAML and OIDC auth. The field of auth services seems to be super crowded, between the incumbents like Auth0, Okta, Cognito, etc and a ton of startups all offering nice DX and lower pricing, like Clerk, Stytch, WorkOS, Supabase Auth, and so on (putting aside the options of rolling it yourself). After reading the homepage I'm not really sure why Kinde would be better suited for our use case than any of those other startups, since everyone says they're secure/have transparent pricing/are nice to use, but maybe just gotta try it to find out?
I co-founded zalter.com bootstrapped and kind of failed to grow it — mainly because of the market saturation IMHO. Did a lot of PoCs and unfortunately most companies are vendor locked-in.
Under the hood you often find a lot of differences in terms of what you get for the cost, limitations in user management depending on which company, and a few other factors.
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
I have been using open source tooling for authentication and authorization. So far I have had good experience with Ory ecosystem and self managing (they have a managed version as well).
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.
I was looking at the docs and kept seeing a lot of similarities with Auth0. Looks very promising and fully featured. Perhaps I missed it, but I was looking at the .NET SDK and didn't see much plumbing for verifying JWT with Kinde (in the context of a web API request). Is this not baked into the SDK?
Hey, thanks for digging in. The backend SDKs are really geared towards calling the management API, handling the auth flows and providing helpers for things like permissions / feature flags. We haven't baked in JWT verification just because there are already so many libraries which already handle this side of things. Although, it's definitely something we could extend the SDKs to include.
Honestly, I found it to be unusable in EU, trying to navigate the dashboard is extremely slow and the only regions you seem to be offering are AU and US.
Wow, you guys made it work — my company zalter.com didn't reach this level of Kinde as of yet. What's a marketing strategy you made it work? You do B2B outreach?
A little bit but trying to primarily drive growth through referrals from existing customers. If we can continue to build based on their requests and keep them happy, hopefully they talk about us in the future to other people looking for auth
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?