I'd use a framework even for very simple authentication. There's just so much to supporting a decent UX that people expect now;
- limiting login attempts with a die off time between tries
- blocking automated brute force login attacks
- verifying accounts by email on sign up / invitation
- verifying username and password changes by email
- a friendly forgotten password workflow
- supporting even one basic 2FA factor (especially important on enterprise)
- logging user activity
- permission management
You could easily write all those things yourself. None of them are very complicated. But if you get any of them wrong it's very, very bad. Why wouldn't you use something that thousands of people have tested already?
Without disagreeing with your point, I'll make an attempt to answer this question:
Why wouldn't you use something that thousands of people have tested already?
I think some of us find the most portable thing between projects -- across languages and platforms -- are outlines of what some part of an application has to be able to do and an ability to implement it from scratch.
There's certainly always some level at which off-the-shelf is a more productive and reliable choice. A DIY approach tends to yield more dividends to the degree that constraints or requirements in play would compel you to work against the grain of off-the-shelf stuff (thereby having to deal in the details anyway, not only for the problem, but for how the frameworks does things), and fewer dividends (or outright liabilities) to the extent that off-the-shelf will more than cover you.
Additionally, it's good to remember that something like Bob Martin's observation can apply: "framework authors are out to screw you -- that's not quite true, they're not exactly out to screw you, but they will screw you because the framework authors have their interests in mind, not yours." The language is a little bit over the top but it's true that dependencies are not solid foundation points, they're viscous potential points of future instability because they're projects driven by incentives that are not always aligned with yours. And the closer they are to the center of your app the more that might matter at some point. What happens with authentication if/when you decide to migrate frameworks? Or if your framework-supported application is only one of several (not all based on the same stack!) providing service in front of a common datastore?
It's worth reckoning with the overhead and hazards of DIY for sure, it's just also worth reckoning with the sometimes more subtle costs of framework buy-in.
I'll also add that while there are times I'm an enthusiastic supporter of framework use, I can't imagine being anything other than skeptical about outsourcing authentication to a third party service. Maybe there's a circumstance in which I'd find that would make more sense someday, but placing such a core thing in third-party hands gives me the shivers.
I can't imagine being anything other than skeptical about outsourcing authentication to a third party service..
Just to clarify, I said framework not service. I'm advocating in favor of using things like Passport.js that you run entirely yourself. I'm not advocating for auth services like Auth0 or Firebase Auth (which have there place, but require a lot more consideration beforehand).
Comments
I'd use a framework even for very simple authentication. There's just so much to supporting a decent UX that people expect now;
- limiting login attempts with a die off time between tries
- blocking automated brute force login attacks
- verifying accounts by email on sign up / invitation
- verifying username and password changes by email
- a friendly forgotten password workflow
- supporting even one basic 2FA factor (especially important on enterprise)
- logging user activity
- permission management
You could easily write all those things yourself. None of them are very complicated. But if you get any of them wrong it's very, very bad. Why wouldn't you use something that thousands of people have tested already?
Without disagreeing with your point, I'll make an attempt to answer this question:
I think some of us find the most portable thing between projects -- across languages and platforms -- are outlines of what some part of an application has to be able to do and an ability to implement it from scratch.
There's certainly always some level at which off-the-shelf is a more productive and reliable choice. A DIY approach tends to yield more dividends to the degree that constraints or requirements in play would compel you to work against the grain of off-the-shelf stuff (thereby having to deal in the details anyway, not only for the problem, but for how the frameworks does things), and fewer dividends (or outright liabilities) to the extent that off-the-shelf will more than cover you.
Additionally, it's good to remember that something like Bob Martin's observation can apply: "framework authors are out to screw you -- that's not quite true, they're not exactly out to screw you, but they will screw you because the framework authors have their interests in mind, not yours." The language is a little bit over the top but it's true that dependencies are not solid foundation points, they're viscous potential points of future instability because they're projects driven by incentives that are not always aligned with yours. And the closer they are to the center of your app the more that might matter at some point. What happens with authentication if/when you decide to migrate frameworks? Or if your framework-supported application is only one of several (not all based on the same stack!) providing service in front of a common datastore?
It's worth reckoning with the overhead and hazards of DIY for sure, it's just also worth reckoning with the sometimes more subtle costs of framework buy-in.
I'll also add that while there are times I'm an enthusiastic supporter of framework use, I can't imagine being anything other than skeptical about outsourcing authentication to a third party service. Maybe there's a circumstance in which I'd find that would make more sense someday, but placing such a core thing in third-party hands gives me the shivers.
I can't imagine being anything other than skeptical about outsourcing authentication to a third party service..
Just to clarify, I said framework not service. I'm advocating in favor of using things like Passport.js that you run entirely yourself. I'm not advocating for auth services like Auth0 or Firebase Auth (which have there place, but require a lot more consideration beforehand).