4 ms·

Good article. The only thing I take slight issue with is: > 5) Don't roll your own authentication > Just don't. It's simply not worth the time and effort. Sim

Good article. The only thing I take slight issue with is: > 5) Don't roll your own authentication > Just don't. It's simply not worth the time and effort. Simply use a third party service that fits your project the most, and call it a day. I agree with "don't roll your own IDP", for sure, but having implemented my own libraries to handle CAS and then SAML authentication (because no libraries worth using were available on the language/framework I was using at the time), I can tell you that it was a huge learning opportunity and really gave me a much deeper appreciation for how these authentication systems work. I wouldn't want to put my code on a public facing network, but it was good enough for intranet use, and the knowledge gained has made it easier for me to implement SSO in a slew of paid, free, and homegrown apps over the years.

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 ago
  100%, 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.

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 ago
100%, 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.