Launch HN: PropelAuth (YC W22) – End-to-end auth service for B2B products
37 comments
Congrats on the launch! I'm curious about how this compares to existing Auth microservice solutions like Ory Kratos[0][1]. For the "short-lived tokens" that you mention, is that similar to Ory Kratos used with Ory Oathkeeper[2][3] with JWTs? That's a similar approach that I've seen companies like Uber taking for their microservice Auth.
0: https://www.ory.sh/kratos/
1: https://github.com/ory/kratos
2: https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-i...
3: https://github.com/ory/oathkeeper
0: https://www.ory.sh/kratos/
1: https://github.com/ory/kratos
2: https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-i...
3: https://github.com/ory/oathkeeper
I could imagine that this is just a wrapper around ORY services.
Yup, the short lived tokens are JWTs - wasn't sure how much detail to go into in the description.
For comparing to something like Kratos, probably the best way of putting it is, the first line of the quickstart guide for Kratos is "Ory Kratos has several moving parts and getting everything right from the beginning can be challenging" - and we want to provide the opposite initial experience. We want there to be an understandable UI for login + team management that you can interact with immediately and quickly configure. Kratos and Oathkeeper are really cool though, especially when you want to go significantly deeper in tuning things. As we add on more complexity, we want to make sure that that initial experience is still really walk up usable.
For comparing to something like Kratos, probably the best way of putting it is, the first line of the quickstart guide for Kratos is "Ory Kratos has several moving parts and getting everything right from the beginning can be challenging" - and we want to provide the opposite initial experience. We want there to be an understandable UI for login + team management that you can interact with immediately and quickly configure. Kratos and Oathkeeper are really cool though, especially when you want to go significantly deeper in tuning things. As we add on more complexity, we want to make sure that that initial experience is still really walk up usable.
> Ory Kratos has several moving parts and getting everything right from the beginning can be challenging
That's them overstating it. You could deploy it in couple of hours (in its simplest form).
That's them overstating it. You could deploy it in couple of hours (in its simplest form).
Love this, and love that there's more going on in this space. Three questions:
1. SAML?
2. SCIM?
3. In your domain model, do users belong-to organizations? Or is it a has-and-belongs-to-many sort of deal? Can I configure that?
1. SAML?
2. SCIM?
3. In your domain model, do users belong-to organizations? Or is it a has-and-belongs-to-many sort of deal? Can I configure that?
Thanks! SAML and SCIM are both on our short-term roadmap and are really important. We want to implement it such that the code you write for supporting orgs today works regardless of the type of integration - and then the differences would primarily be the experience for your end-users.
There's a one to many mapping from users to organizations. We can also support users that don't have organizations. What types of configurations would you want?
There's a one to many mapping from users to organizations. We can also support users that don't have organizations. What types of configurations would you want?
Having the option for users to exclusively belong to organizations would be nice. It makes implementing tenant boundaries, and avoiding cross-account broken access control, much easier.
That makes sense, it definitely simplifies things. I like the idea of choosing between "everyone is signing up with their work accounts" and "users can join potentially multiple organizations, work related or otherwise". Thanks for the feedback!
This is really cool. As someone who's moved a very large SaaS product to a Customer IAM SaaS vendor the missing piece is typically user authorization. Currently the identity of who the user is is owned by the SaaS where's the RBAC and groups are maintained application side.
This type of thing could be really useful but I wonder how hard it will be to generalize the problem.
This type of thing could be really useful but I wonder how hard it will be to generalize the problem.
Thanks! Generalizing it is something that we think a lot about. There's a lot of value in providing something simple like RBAC with a few roles, until you need something more custom.
I personally think that the ability to opt into more complexity is really interesting. Starting with a basic set of roles within a single organization is appealing when you are small, and then importantly having the ability to layer in groups or layer in scopes/actions associated with those roles.
I personally think that the ability to opt into more complexity is really interesting. Starting with a basic set of roles within a single organization is appealing when you are small, and then importantly having the ability to layer in groups or layer in scopes/actions associated with those roles.
How do you plan for data portability? If we start with PropelAuth and later decide to migrate to a self-built platform, do you provide any tools to simplify the offboarding experience?
I love the concept of the product. We're essentially focused on building an internal version this project, so if we could scale up with you and offboard (if need be) at a later date, that would be awesome.
We're also seriously considering ORY Kratos.
I love the concept of the product. We're essentially focused on building an internal version this project, so if we could scale up with you and offboard (if need be) at a later date, that would be awesome.
We're also seriously considering ORY Kratos.
For offboarding, we provide full data dumps of all user + org information - password hashes included. I want people to use us because they want to not because their data is stuck with us.
I wrote about the differences between us and ORY Kratos here: https://news.ycombinator.com/item?id=30702430 Happy to chat anytime, if you want, my email is in my bio.
I wrote about the differences between us and ORY Kratos here: https://news.ycombinator.com/item?id=30702430 Happy to chat anytime, if you want, my email is in my bio.
PropelAuth is great and a breeze to integrate! We were dreading building out B2B features like orgs and spending time making login flows for our analytics dashboard product. This was all provided out of the box with Propel.
You can tell Andrew uses it himself from the practical docs and providing nice things like express middleware. I imagine it must be a bit mind bending to dogfood the service.
You can tell Andrew uses it himself from the practical docs and providing nice things like express middleware. I imagine it must be a bit mind bending to dogfood the service.
Appreciate it! PropelAuth's authentication is powered by PropelAuth which is definitely confusing sometimes. I try and think of them as two different services (APIs/hosted pages as one service and an internal configuration service as the other) which helps me.
The plus side is everything we build for ourselves we can release to customers.
The plus side is everything we build for ourselves we can release to customers.
This looks awesome. I’ve known for a while that I will eventually have to support organizations and teams for https://canopycharts.com and have been dreading writing all that code myself.
Seems like I might not have to :)
Seems like I might not have to :)
Your landing page is really clean, I like it!
It's always fun to hear the workarounds people do to avoid adding orgs/teams - my personal favorite is the single account everyone share a password case :)
Happy to chat anytime - my emails in my profile!
It's always fun to hear the workarounds people do to avoid adding orgs/teams - my personal favorite is the single account everyone share a password case :)
Happy to chat anytime - my emails in my profile!
What would you say is your main differentiator to Auth0?
My main gripe with Auth0 was that they lacked support for organizations, until they added support for that a year ago. With that in place now, I don't see any USP that would make me use your product.
My main gripe with Auth0 was that they lacked support for organizations, until they added support for that a year ago. With that in place now, I don't see any USP that would make me use your product.
Our main differentiator today is a much quicker time to go live - which usually boils down to us providing more hosted UIs out of the box, guides focused on B2B use cases, and libraries that are more centered around organizations.
Anecdotally, pretty much every startup we talked to that tried to use Auth0's organizations either stopped pretty quickly or ripped it out due to API slowness.
If you've used their org support, I'd love to chat to hear more
Anecdotally, pretty much every startup we talked to that tried to use Auth0's organizations either stopped pretty quickly or ripped it out due to API slowness.
If you've used their org support, I'd love to chat to hear more
This looks great and super approachable. WorkOS[0] seems to be tackling something similar but more enterprise focused.
[0]: https://workos.com/
[0]: https://workos.com/
I'm glad you find it approachable :) Definitely, WorkOS has more of an enterprise focus which is also important - we are more focused on early stage startups today.
I am working on a side project solving the exact same thing. The project is not open source yet and I am not very actively working on it. I kind of created it to learn golang and some web technologies and other infra tools that I normally don’t use at work. Good to know that there is a market for, not that i have plans to commercialise it but if i open source it people might be interested to contribute.
I'm a little confused how the PropelAuth concepts map to typical B2B scenarios.
For example, say Alice works for Acme, and she signs up for Jira. She is now the admin, so puts the credit card in to upgrade the account, and then invites her colleagues.
Is Acme an "organization" in terms of PropelAuth? Organizations sound looser and more user defined, almost more like a Gmail group of users than a "company".
For example, say Alice works for Acme, and she signs up for Jira. She is now the admin, so puts the credit card in to upgrade the account, and then invites her colleagues.
Is Acme an "organization" in terms of PropelAuth? Organizations sound looser and more user defined, almost more like a Gmail group of users than a "company".
Appreciate the feedback! We've had people use organizations in both ways, honestly. The implementation is definitely more like a Gmail group of users than a company.
In your example, some people have implemented it as Acme is the organization, and some people have implemented it as specific teams within Acme are an organization.
I suspect we'll need to add a second tier (e.g. a team or a group) underneath a more rigid definition of a company. Would that have made things more clear?
In your example, some people have implemented it as Acme is the organization, and some people have implemented it as specific teams within Acme are an organization.
I suspect we'll need to add a second tier (e.g. a team or a group) underneath a more rigid definition of a company. Would that have made things more clear?
Yeah, for my specific use case, I'm less interested in user-defined teams and more interested in company admins inviting users with specific roles (which sounds like a common scenario).
We're currently integrating Auth0 for authentication but sticking to our own authorization stuff. Auth0 organizations seem way heavier than what we need, more for like white-labeling an app to a handful of huge enterprise clients, rather than just having lots of small clients with a handful of users each.
We're currently integrating Auth0 for authentication but sticking to our own authorization stuff. Auth0 organizations seem way heavier than what we need, more for like white-labeling an app to a handful of huge enterprise clients, rather than just having lots of small clients with a handful of users each.
That makes sense - and is definitely something we'll need to more clearly support. The distinction between the two cases is also pretty clear, thanks for you all your thoughts here!
We had similar feelings about Auth0's org implementation, it doesn't really match the way most companies think about orgs, especially at an early stage.
We had similar feelings about Auth0's org implementation, it doesn't really match the way most companies think about orgs, especially at an early stage.
This company/team distinction describes what we're looking for next in our implementation :)
Also, hey, I'm Adam, a very happy customer of PropelAuth at Kable.io. Andrew is an incredibly responsive founder, who has been a great partner in the launch of our own B2B business. High recommend from me -- PropelAuth rules
Also, hey, I'm Adam, a very happy customer of PropelAuth at Kable.io. Andrew is an incredibly responsive founder, who has been a great partner in the launch of our own B2B business. High recommend from me -- PropelAuth rules
I created a test account and added an organization. Then sent an invite to my other email. I got the invite email and clicked on the link which brought me back to the same browser/session where I was already logged in as the owner and it gave me a registration error. I logged out and then clicked the invite link again and this time it worked. FYI.
Ah, sorry about that. The issue is if you try and accept an invite for a different email address than what you are signed in for, it stops you. But, it's definitely a confusing experience when testing since it's really common to create a few test accounts - thankfully it doesn't happen much in prod.
What would your ideal experience there be?
What would your ideal experience there be?
From the docs it looks like you have dedicated instance of service for each user, is that correct. Or it is a kind of multi tenant system where data might be colocated. I am guessing that it is a multi tenant system but If you spin off an instance for user, how do you do that?
We have a special focus on B2B features that make it easy for an end user to sign up, create and manage their own organization in your product, invite their co-workers, and so on. This includes roles within the organization (RBAC). We provide frontend and backend libraries where organizations are a first class concept, and we host UIs on your domain to manage the rest.
We didn't start out with this focus. PropelAuth actually started out of a chess side project I was working on. As side projects go, I started by focusing on the core product and fun aspects of it. Things like user authentication felt like a distraction from the things I wanted to work on.
I’ve set up auth at different jobs and for friends' companies in the past, and I never felt like any tool nailed it. The experience I wanted was “all aspects of auth are taken care of for me, UIs included” and then to have minimal libraries to check if users were logged in or not. The MVP of PropelAuth was a set of basic UIs that we hosted on our customers domain, some admin tools, and a few frontend/backend libraries.
We were also dogfooding ourselves—and because we sell to businesses, we built out some B2B specific features: creating organizations, inviting coworkers, roles/RBAC, and the UIs for all that. When talking with early customers, those turned out to be the features that got the strongest reactions. B2B founders were looking for that, and existing auth tools didn’t have these features or didn’t have them in an easy to implement way. So that’s been our focus ever since.
The product today acts similarly to a self-contained auth microservice that you can configure. It has simple UIs like signup and login and then more advanced ones like security pages (with 2fa enrollment) and organization management (with roles support).
The frontend libraries request short lived tokens for your users that your backends can verify. It also exposes APIs to fetch user and organization information.
We have a free plan, and charge $0.02 per monthly active user for the next plan up.
We’d love to hear any feedback you have! If you want to try out the product, you can sign up on our website at https://www.propelauth.com. You can check out our docs at https://docs.propelauth.com/ and there are guides at https://www.propelauth.com/blog-categories/guide. Thanks!