Ideas and Validation January 7, 2020

User auth/verification as a service

chris_davies

As a serial hacker, I find one of the most boring/time consuming parts of building a new app is the user management component. In my case, it always looks something like the following:

  • build a user model, using an email address as the username
  • build a user verification workflow using an email backend
  • build an authentication API (typically jwt token-based)
  • implement social auth login options, e.g. Google oAuth
  • build an integration with stripe
  • build a permissions system which decides what the user has access to based on whether they've verified their email address, what Stripe plan they've signed up to, and whether or not they're still on a free trial period

Is there anybody out there that shares my pain that would be interested in a service that provided all of the above for you? I've built the above functionality a number of times over the years and refined it over that time to the point where I think I can create a half-decent product out of it.

In terms of the pricing model, I'm thinking something like this should probably use Stripe application fees, e.g. take a small percentage of every transaction, instead of charging a monthly fee.

Anybody out there feel this is worth building?

  1. 5

    I think this idea is validated through existing user identity services like Auth0, etc. The only bullet item that I don't think they have a native solution for is the Stripe integration, but it is extraordinarily easy to configure this scenario using the existing Auth0 features.

    1. 3

      thanks, the general feeling here seems to be that there isn't much that this would offer that auth0/firebase don't already have covered, so not sure there's much mileage in it.

  2. 3

    I would use a library (i.e something I can pull into my code base), but never as an external service. It's just too critical and too bound with the core of an app to dish off to a 3rd party!

    1. 1

      This seems to be the overwhelming sentiment of the community - think I'll park this one for now

  3. 2

    This is exactly what Authress did. It was a pain point, and we converted our infrastructure into a real solution. We actually went to focus on the Authorization part of the user flow, since there are a ton of services that already support the login functionality.

    We have the stripe integration piece internally, but haven't exposed it yet. It didn't seam like many people wanted that, it was a bit niche. There are already products that https://www.chargebee.com/, and given the level of integration with stripe necessary, it's a huge overhead to duplicate that experience in an app for the users.

    Instead we've separate permissions out as a first-class citizen, so apps get fully control and visibility into what users have access to what.

  4. 2

    https://auth0.com provides a lot of what you're describing. So there's a market :)

  5. 1

    I use auth0. If Auth0 didn't exist. I'd use one of the other 200 free ones.

  6. 1

    Little late to the party, but as a relatively happy user of firebase auth, here's my 2 cents:

    The big issue with the current auth-as-a-service providers is the centralisation of user authentication. This gives too much power to the auth service - if they ban your account for whatever reason they can effectively kill your entire business by shutting down your user base. This also has privacy risks since the auth providers usually hold sensitive data on the user, especially if using mobile/email/social login. None of this has ever been abused, as far as I'm aware, but it's always a possibility.

    Personally, I'd happily switch (and pay) for a decentralised auth service. The nature of being decentralised complicates the design but IMO this is one of the few areas where "decentralised" isn't just a buzzword and actually has value.

  7. 1

    Our free SaaS boilerplate https://www.saasforge.dev has most of these features:

    • user model
    • user verification
    • JWT-based authentication
      The Stripe integration, as well as social logins, is coming soon.
  8. 1

    Many of the commenters here recommend either Auth0 or roll-it-yourself. As a side note, would would be especially useful would be a service to inspect/code review/pentest/advise on the security and regulatory complinace of custom-coded auth and user management solutions. It would be an extremely valuable service to have someone inspect my own apps to point out the holes so that I can fix them. This way, I could have the benefit of a vetted service (like Auth0) without the ongoing cost or vendor lock-in.

  9. 1

    hey, to answer all your questions, YES! :-) BUT, what would make it different to say Auth0 as one example? https://auth0.com/

    1. 1

      lots of people seem to think this way about auth0 or firebase. Doesn't look like there's much to be gained here

  10. 1

    Unfortunately, this already exists and is widely used in the form of Firebase, which this app is apparently using for its auth as well

  11. 1

    doesnt something like firebase comes very close to your idea?

  12. 1

    I've been building something similar with https://reactdashboard.com/

    It uses serverless functions, and works with netlify out the box. So you don't have to "lock-in" with a provider. Plus you can run your apps without server costs. 🤯

    Literally working on the Stripe integration as I write this.

    Also, if serverless isn't your thing - I've used https://jumpstartrails.com/ for my https://creatorsgate.com project as a test. So far so good.

  13. 1

    Check out Auth0 and AWS Cognito for examples of two existing services that provide the auth portion of this. From my perspective, the value prop for existing auth services is (1) ease of use and (2) security. On the ease of use side, I appreciate that using a third-party identity provider makes it easier to implement things like two-factor auth and gives me the option to use a pre-built authentication UI if I choose. On the security side, there's the benefit of not having to store password credentials in my own data store. Just to give some honest feedback, I would never rely on an unproven third-party authentication service even if ease-of-use was off the charts. FYI we use AWS Cognito at Reflect.

    However, if you were selling a framework or something that was the glue for Stripe/Auth0/etc, that would be something I'd take a look at. You might be looking at an open source model if you went down that road. AWS Amplify is the closest thing I can think of to that.

  14. 1

    It seems to me, that as a self described serial hacker it would make sense to build it for yourself, if for no one else. Use it. Offer it. If it’s good people may pay. If not you’ve saved yourself the pain of doing it another umpteen times :)

  15. 1

    I also found it very cumbersome to do authentication on every fresh project I started. And I always wanted to build everything myself just so I have control on every aspect of it.

    But then I started using Firebase... and the authentication system they offer is just amazing. It handles everything and is super easy to integrate. The most amazing part to me was the option to create anonymous accounts that can be turned into normal accounts without any hassle. A user can test your product, create lots of data, and then when they decide to make an account, the session and everything they created is just seamlessly connected to their newly created profile.

  16. 1

    I've thought about building this before, but the reality is, most people would not want to give up one of the core essentials (user database, management, authentication) to a third-party service. Relying on a third-party service for basic bread and butter stuff like signup, login, email verification, change password, signup with OAuth providers, etc. is enticing, but a huge risk. Sooner or later, when a site gets big, they'll switch away from you. Maybe there's a market for early stage apps, but will they really want to pay for this when they can get it off the shelf for free?

    Now, if you spin it as an enterprise user management system for SSO, auditing, etc. then that's something many identity provider vendors are making bank selling to enterprises, and a path to consider.

    1. 1

      I think this is probably true of myself even. These days I have a django app that can be dropped into any django project that covers all of this.

    2. 0

      A lot of enterprise cos. and consultants recommend that one should always use a service specialised in storing user credentials. The problem is however, that one wouldn't select an indie hacker's project as a solution because of the potential vulnerabilities.

      1. 1

        I personally wouldn't recommend that:

        1. You have to share data with third-parties, which leads to GDPR implications.
        2. You potentially give away stats about your users to your competitors (e-mail addresses, locations, etc.)

        Why would a conslutant recommend this? I don't think you even have more legal coverage in case of a data breach, as you were the one who actually colected the data.