3 ms·
Most of the time, reinventing the wheel will get you in troubles on such a sensitive topic as IDP. Troubles come in various forms: missing deadlines, maintenanc
by pavel910 6y ago
Most of the time, reinventing the wheel will get you in troubles on such a sensitive topic as IDP. Troubles come in various forms: missing deadlines, maintenance burden, change of employees who may or may not know a single thing about security. In small companies (web/digital agencies) productivity and reliability is what everybody wants, not proving the ability of implementing your own similar solution. Given enough time, anybody can implement the same set of features Okta/Auth0 provides. But how much time is that? How reliable is your code? Is it really secure?
As an engineer, I completely agree with you: reimplementing stuff on your own is an amazing learning opportunity (did it a billion times myself).
But as an owner of a digital agency in the past, I will take a 3rd party IDP over custom solution for production-ready products any time. It's just not worth the risk for solid businesses, not to mention the maintenance burden, lack of features, etc.
- core-questions 6y ago100%, doesn't disagree with anything in my post - my point was, it's not a bad idea to go through the effort of learning how to integrate with an auth system at a deep level so that you understand how it works. Still, writing the code for SP side isn't _that_ dangerous if you already had an app that was reasonably secure at the application level behind its own standalone auth mechanism. Would only make sense to do if your language / framework has no good bindings or plugins for this already, though.