Yeah, there's definitely something to be said for using trusted identity providers like Google - there are a lot of advantages to that, but it has some disadvantages to it as well.
I would certainly never recommend that someone roll their own hash functions or their own implementation of JWT, or heavens forbid their own cryptography, as doing so would inevitably go disastrously wrong.
That being said, federated logins aren't a one-size fits all solution. Plenty of companies choose to use existing hash libraries and well-known, well-maintained auth libraries for session or token management, and many of them have valid reasons for doing so. I personally think there's nothing wrong with doing that as long as you are both deliberate and careful about it.
I agree to a degree. Companies, with the ample resources (with talented developers) should absolutely contemplate writing their own auth... when existing solutions do not fit their needs and provided that they are unable to contribute to the standards (in spec or impl) or extend an existing open solution. Many, even the "big dogs", also get it wrong; for example Apples early impl of OpenID. You also don't have to go with a hosted/managed third party to use an IAM nor must it be federated. There are several "host it yourself" IAM solutions which provide OpenID compliant services. Since they are open source you could even extend them with your needed custom auth "additions" for your special edge cases. You can also extend OpenID spec with your special use cases similar to HEART and UMA.
I think these articles have merit and value for learning. The issue I take is the impression these articles give the inexperienced devs who proliferate the web trying to build their own solutions and products with a team of 1 (or very few), who don't understand (and seem to have the bare minimum concern for users security) who are the predominant audience of these articles. For those individuals these articles, almost always without disclaimer, practically vindicate that they can and should, roll their own auth.
Should a company write their own auth? Maybe. Under very limited reasons and with the right team who have vast experience in auth. Should Joe Blow and the 3 musketeers roll their own auth? If making products for actual consumption absolutely not. Not if you want to respect your users privacy and provide them with real security (federated or not). Not if you want to spend time adding value to your actual business instead of rebuilding the wheel. I'm probably being hyperbolic but I would venture to say 90%+ of products don't need custom auth solutions.
If you roll your own auth please, at the very very least, make it publicly available so that the security experts and white hat hackers of the world can tare it apart to help rigorously audit and test it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yeah, there's definitely something to be said for using trusted identity providers like Google - there are a lot of advantages to that, but it has some disadvantages to it as well.
I would certainly never recommend that someone roll their own hash functions or their own implementation of JWT, or heavens forbid their own cryptography, as doing so would inevitably go disastrously wrong.
That being said, federated logins aren't a one-size fits all solution. Plenty of companies choose to use existing hash libraries and well-known, well-maintained auth libraries for session or token management, and many of them have valid reasons for doing so. I personally think there's nothing wrong with doing that as long as you are both deliberate and careful about it.
I agree to a degree. Companies, with the ample resources (with talented developers) should absolutely contemplate writing their own auth... when existing solutions do not fit their needs and provided that they are unable to contribute to the standards (in spec or impl) or extend an existing open solution. Many, even the "big dogs", also get it wrong; for example Apples early impl of OpenID. You also don't have to go with a hosted/managed third party to use an IAM nor must it be federated. There are several "host it yourself" IAM solutions which provide OpenID compliant services. Since they are open source you could even extend them with your needed custom auth "additions" for your special edge cases. You can also extend OpenID spec with your special use cases similar to HEART and UMA.
I think these articles have merit and value for learning. The issue I take is the impression these articles give the inexperienced devs who proliferate the web trying to build their own solutions and products with a team of 1 (or very few), who don't understand (and seem to have the bare minimum concern for users security) who are the predominant audience of these articles. For those individuals these articles, almost always without disclaimer, practically vindicate that they can and should, roll their own auth.
Should a company write their own auth? Maybe. Under very limited reasons and with the right team who have vast experience in auth. Should Joe Blow and the 3 musketeers roll their own auth? If making products for actual consumption absolutely not. Not if you want to respect your users privacy and provide them with real security (federated or not). Not if you want to spend time adding value to your actual business instead of rebuilding the wheel. I'm probably being hyperbolic but I would venture to say 90%+ of products don't need custom auth solutions.
If you roll your own auth please, at the very very least, make it publicly available so that the security experts and white hat hackers of the world can tare it apart to help rigorously audit and test it.