I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have.
And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period.
Pick an auth provider and you better believe in their business as much as your own. You will incur damage when you leave.
> And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period.
Actually, not true. I can't speak for every auth provider, but FusionAuth and Auth0 both let you have the password hashes. If you know the algo (ask your provider!), you can load the hashes (and other ancillary password data like the salt) and your users will never be the wiser.
Here's a guide I wrote about how to migrate off of Auth0: https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ The end goal of the guide is to move to FusionAuth, but the steps to get your password hashes out of Auth0 (the 'Exporting Users' section) will work no matter where you migrate to.
I maintained and extended a self rolled auth system built on top of django and it was a constant headache. We lost weeks of engineering productivity fighting with keeping the various libraries up to date and running into the usual "forgot password" edgecases.
I spent a few days with FusionAuth for a demo project and once I grokked it I really wished we had used it or something similar instead. Amazing abstraction layer to have at your disposal.
You absolutely can migrate away from Auth providers. Auth0 (disclaimer: former employer) hashes passwords with Bcrypt, which is most likely the same exact algorithm you would choose. Bcrypt stores salts & rounds as part of the hash making those hashes fairly portable.
Even if you wanted to change algorithms, there are ways to do this so that it is transparent to the user, such as running the plaintext password through a new algorithm after a successful authentication and storing it in a new column.
You own the user table, but the auth logic is written by an expert.
If going with a third-party service, my advice would be to make sure you understand how to export the data out of the system, including hashed passwords using a non-proprietary algorithm.
I would expect that the way to do this sort of migration is to run it until the costs associated with maintaining the migration infrastructure exceed the projected losses due to churn. You don't need to worry much about auth provider pricing because these are typically billed on the basis of monthly-active-users, so even if you have a small number of users who aren't active, they'll hardly show up on your bill. When this pool of unmigrated users is small enough that you can tolerate churning a percentage of them, you can turn off your migration infrastructure and enforce a hard password reset.
That said, I don't know what kind of business has a significant percentage of users who churn because of a one-time password reset. I can't imagine any b2b contracts being canceled because the service provider enforced a password reset. Maybe retail sites are different?
If you have a middleware that lets you swap providers, you can start off with a ready made solution and switch if necessary.
Obviously, this still means you need to maintain control over your data; but that's surely something a startup will do in any scenario, right?
This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.
The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been a manual implementation of the underlying protocol a decade ago. So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto.
This notion that it is a "no-brainer" decision to happily trade your customer database and a % of revenue to remove the burden of stewardship seems crazy to me.
Proper password and session management have been made accessible for many years if you use any "modern" backend.
However, now they've been bought by Okta, which has a pretty bad reputation.
So, I guess we'll get to find out eh?
> Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works.
Source: https://martinfowler.com/bliki/PackageCustomization.html
Predating Fowler by about 10 years.
I know why people are against building custom solutions. I’m just gonna say that I personally felt safer running third party Django apps that handled authentication but on a server I controlled, vs for example, Auth0. Not to mention the pricing model. The disadvantage is that you may have to put some effort into helping maintain it if it’s part of your critical path, but that seems like a good tradeoff to me. The point is to get an MVP out quickly, right? If things work out, having the resources to maintain an auth system seems reasonable.
This is not to pick on Auth0 so much; it seemed cool when I tried it out. It’s just scary to me to have my user database out of my control.
Every one of these external dependencies is... a dependency. Each one brings with it the risk of the external company going under, prices rising to unacceptable levels, intermittent outages, etc. These are all independent events. For the sake of argument, if the risk of a company going under any given day is 1 in 100, then using five separate companies means our risk is 5 in 100 (1 in 20).
We need to weigh the risks plus impact against the advantages.
High risk + low impact or low risk + high impact are generally acceptable.
Auth is a space where generally it's moderate risk and high impact while the advantages are... quite low versus just throwing Keycloak onto your cluster and getting on with your day.
> If it’s a core business function — do it yourself, no matter what.
https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
Of course, then the issue becomes "what is core?"
Except when there are none, you have to build it yourself.
I'm currently building what's essentially an internal specialized platform that is used for data science/engineering as well as actually providing the models.
The data is strictly private to the level that you might actually end in jail if you have a breach. While we use AWS, said use of AWS is more than half the reason we have to build custom solution around Keycloak, because a) AWS SSO is purposefully limited in a way that prevents us from using it b) AWS really doesn't work well with SSO for getting credentials for AWS SDK applications.
We also need to self-host because we can't outsource auth, including possibly requiring a legal shield against known hostile actors like USA. (shit's complex on that)
Then we have essentially "normal business requirements", meaning that we actually want SSO that results in user logging in exactly once - when they login to their VDI in closed-off VPC. And that turns out to be really complex, especially in case of accessing AWS services later :/
My company moved to Okta from a home grown solution in 6 months and I suspect after the work we put in place to facilitate that would allow us to move somewhere else in even less time as long as they supported importing hashes.
Does this mean that anyone who didn’t know to do this is screwed?
As far as I can tell, nothing has actually changed from the customer perspective. It's not like Auth0 is going away or becoming unusable. Okta didn't spend $6.5B to burn all of Auth0's customers.
Why would you offload payments instead of e.g. connecting directly to payment gateways yourself, but wouldn't do the same for auth & notifications?
What kind of notifications are we talking about where you can get away with self-hosting? AFAIK, Push Notifications on smartphones have to go through Google and Apple's servers. Maybe if you're doing email notifications?
For email though, not sure, that's a completely different topic. It comes with many headaches, using a service like SendGrid or Mailchimp seems like a good idea, and if you really want to roll our own mail servers down the line you can still do that.
GDPR compliance is not something you can just buy.
I can see why not to do notifications, but it’s hard to avoid doing some form of it if you’re making an app with focus on low latency realtime updates.
The bigger problem is that out of all three categories, I only really feel content with trusting Stripe, and only so much. Auth0 has its issues, and decent authentication systems you can roll on your own are plentiful. Maybe building it yourself no longer makes sense, but I do think owning your user database is a good idea, even if you do primarily lean on OAuth.
I don't think deciding not to do something out of fear of doing it wrong is the right approach... If it's business decision then at least it's backed with some reasoning - don't do it because it's cheaper to buy it.
How different is that in terms of what Stripe offers?
There are generally a number of domestic gateways in each region (I’ve worked with gateways in Australia, Malaysia and a couple of other places) but there are also larger providers.
There are name brands like Braintree and lesser known but still quite large, like Adyen. The API quality is extremely variable.
Checking out multiple gateways is a good idea. Stripe is supposed to be great but IIRC is relatively expensive.
That is to say that even 20 years ago there were middlemen in the payments space, they just were pretty horrendous to work with.
Also, handling the abstraction between multiple kinds of payment methods (cryptos, different card networks, PayPal, etc.) may also be a considerable amount of complexity that a payment vendor can help with.
I have never directly interacted with the financial system at its lowest levels. I’ve heard it is quite a trip.
You don't have to use JWT to get a standalone solution (see for example this guide which I wrote: https://fusionauth.io/docs/v1/tech/guides/single-sign-on/ JWTs are used briefly, but most of the heavy lifting is done with application sessions).
If you have a single application, definitely use devise, passportjs, spring security or whatever is in your framework. 100% agree. But pretty quickly you often are adding in a forum, helpdesk, GSuite for employees, etc etc and having a single source of truth for a user is good.
If you use "none", anyone can forge a JWT that says anything. I always say:
* You should have some other way of verifying that the JWT was unchanged by the client, like say being on a private network or using client TLS certs
and
* You should benchmark and know that the signing overhead is a significant source of performance degradation in your system.
Otherwise, sign your JWTs! :)
If you're creating a product that is primarily or exclusively for mobile devices, what's the downside of relying on "log in with Google" and/or "sign in with Apple"?
We started trying to plug our app into an external SAML authentication flow (Azure) and it is making it much harder to prove certain semantics around user session lifetime and app security. Maybe it would be "easier" if we had just started with cloud native shiny BS, but I doubt it. Auth state would still be scattered across multiple systems, even if they all lived in Azure (or wherever).
Any time you take a problem that exists on one computer and spread it across many computers, it gets exponentially more difficult and prone to error.
Hard to argue with that.
Unfortunately sometimes you can't say "we have the single source of truth" about a user; federation exists for organizational reasons.
Always remember that which you read is just someone else's flavor of an experience in which they try to convey their ways on you. I am not bashing what they wrote just recognize how things would be if risks are not taken.
I don’t follow
> core foundational member of multiple payments companies
If you’re building a payments company, your product is literally doing the payments yourself!
> with each better than the last,
So, the first ones weren’t very good huh? Perhaps you could have outsourced them?
> Security will become paramount to everything and outsourcing for "cheap" will have a much greater cost than one realizes in the moment.
You’re conflating the use of a 3rd party for cost reduction with using a 3rd party due to efficacy and efficiency due to specialization. There’s zero chance you’re as good at Auth as a whole team of security engineers at an auth provider, period.
There are also simple ones that you can get started with for free/cheap.
Don't roll your own auth. But do feel free to use a battle tested auth library / or framework hosted in your own app.
Then you get both benefits: 1. You don't have to put your destiny in someone else's hands, and 2. You're not getting the risks associated with building your own auth.
I'm glad Stripe mostly killed all that.
Trusting auth systems is always a gamble. Remember when Google 2FA was only actually checking the first factor? I sure do.
In my business the simple account and password ID model is insufficient. Most of our accounts are for families or organizations with complex contact protocols. Because on site service is the product we have the luxury of extensive physical in person verification. Assuming that every auth issue is for a typical Internet SaaS is a huge mistake.
I sometimes write auth/SAML solutions. They're not super complicated once you understand the basics of the system.
I'm wondering for those who build it:
- how did you implement impersonation
- how did you implement tenants ( and switching in between). Most have a follow-up dialog after logging in, which you can select.
- did you implement something in your gateway that checks the token, instead of every service separately ( too lighten the load to the STS)
But this was in the context of a cloud/infrastructure provider, for which IAM, billing and payments are the 3 pillars of the ecosystem. You just can't outsource these business foundations to a third party.
