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

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.

> 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).

I could imagine that this is just a wrapper around ORY services.

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?

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?

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.

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.

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.

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.

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.

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.

This looks super promising. It's impressive how much has been built out already and I'm pumped to see where this goes.

Thanks, appreciate it!

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 :)

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!

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.

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

This looks great and super approachable. WorkOS[0] seems to be tackling something similar but more enterprise focused.

[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.

Congrats on the launch! I've started playing around with the free version and love what I've seen so far. I'm excited to see where the product evolves to.

Thank you, we're excited to hear any feedback you have as we grow!

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".

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?

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.

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.

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

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?

I really dislike Auth0, and so happy to see new entrants in the space. Best of luck, and congrats on the launch!

Thank you!

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?

Would this support adding users to an organization using phone numbers with sms sign up links?

Not yet, but we have started to get more requests for SMS support. If you'd be interested in an early version of our SMS support, definitely reach out and we can set you up with it.