[HN Gopher] Launch HN: PropelAuth (YC W22) - End-to-end auth ser...
       ___________________________________________________________________
        
       Launch HN: PropelAuth (YC W22) - End-to-end auth service for B2B
       products
        
       Hi HN! I'm Andrew Israel, an engineer and the founder of PropelAuth
       (https://www.propelauth.com). PropelAuth provides end-to-end
       managed user authentication and lets your users manage their own
       accounts and teams.  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!
        
       Author : aisrael
       Score  : 44 points
       Date   : 2022-03-16 16:21 UTC (6 hours ago)
        
       | hashamali wrote:
       | This looks great and super approachable. WorkOS[0] seems to be
       | tackling something similar but more enterprise focused.
       | 
       | [0]: https://workos.com/
        
         | aisrael wrote:
         | 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.
        
       | freeqaz wrote:
       | 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
        
         | sebmellen wrote:
         | I could imagine that this is just a wrapper around ORY
         | services.
        
         | aisrael wrote:
         | 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.
        
       | hobofan wrote:
       | 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.
        
         | aisrael wrote:
         | 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
        
       | hyferg wrote:
       | 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.
        
         | aisrael wrote:
         | 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.
        
       | satyrnein wrote:
       | 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".
        
         | aisrael wrote:
         | 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?
        
           | asommer12 wrote:
           | 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
        
       | veryvisa wrote:
       | Would this support adding users to an organization using phone
       | numbers with sms sign up links?
        
         | aisrael wrote:
         | 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.
        
       | chipgap98 wrote:
       | 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.
        
         | aisrael wrote:
         | Thank you, we're excited to hear any feedback you have as we
         | grow!
        
       | ucarion wrote:
       | 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?
        
         | aisrael wrote:
         | 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?
        
           | ucarion wrote:
           | 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.
        
             | aisrael wrote:
             | 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!
        
       | tasn wrote:
       | I really dislike Auth0, and so happy to see new entrants in the
       | space. Best of luck, and congrats on the launch!
        
       | voxmatt wrote:
       | This looks super promising. It's impressive how much has been
       | built out already and I'm pumped to see where this goes.
        
         | aisrael wrote:
         | Thanks, appreciate it!
        
       | mtoddsmith wrote:
       | 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.
        
         | aisrael wrote:
         | 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?
        
       | mroll wrote:
       | 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 :)
        
         | aisrael wrote:
         | 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!
        
       | davewritescode wrote:
       | 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.
        
         | aisrael wrote:
         | 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.
        
       | sebmellen wrote:
       | 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.
        
         | aisrael wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2022-03-16 23:00 UTC)