1. Not all users are comfortable with trusting a third party in order to use my app. Some people actively mistrust and avoid megacorps like Google and FB. They should only have to trust you, not a chain of companies.
2. Writing code to integrate numerous external API calls is a comparable effort to just doing it all custom.
3. The UX of jumping to a third party dialog to log in and then back in to the original app is jarring. "What just happened?"
4. It introduces more potential points of failure with less control over being able to deal with such issues. If the third party services or APIs fail, or a user can't access those domains for some reason, tough luck.
5. Someone else owning your app's user records is troublesome. You still need to have your own user records for things like session state, roles and authorization. You have to keep your user records synchronized with theirs.
6. Users sometimes do not want to link their accounts on other services to your app - they prefer separate identities. When your Google account's avatar appears in an app that has nothing to do with Google it can be annoying, or even perceived as a privacy violation.
7. User authentication involves a standardized, conventional set of practices and code that are well known and not hard to implement.
8. If the third party service you put at the core of your architecture decided to shut you down or compete with you, or they shut down themselves, you'd be in big trouble.
9. Sooner or later you will pay for this service. The more successful your app is, the more you will pay. If you do it yourself, there's no cost beyond your regular hosting costs.
10. KISS - Keep It Simple, Silly. Don't add unnecessary dependencies and complexity.
Well, I use npm's bcrypt + postgres DB of users (on an expressjs server, where I use knexjs for easy DB connection & use of JS logic in DB work).
1. Simply salt their PW when they create their account (which is simply a record in the DB) and store the salted version in the DB.
2. When they log in, salt the pw they entered during login and compare it with the salted one in the DB.
It's not tough.
Is it insanely secure? Nah, I am sure I am missing pieces involved in server and app security. But insanely stringent security doesn't matter for my purposes and use cases.
Password salting... About 4 lines of code: https://www.npmjs.com/package/bcrypt
Storing salted password in DB... another few more lines of code depending on what you use.
I'd say you can do this in under 10 lines of code.
However, that is of course excluding the underlying system and other logic which hosts this process of salting, storing, and then on login, comparing.
...However, if the question is really more like "How many of you are rolling your own auth which works in a high traffic, highly exposed situation, where expert levels of security are necessary?" then you'll likely encounter a different pattern of answers.
That said, those services (the good ones) tend to offer much more than a simple user database, for example:
* Login with Google/Facebook/Twitter/Github/...
* Login with IAM services like OpenID Connect / SAML (mostly for big companies)
* Two factor authentication, maybe with several token types (TOTP, SMS messages, recovery codes,...)
* Password recovery flow
* Rate limit the pace of password attempts, in order to prevent brute forcing
* Monitor incoming network traffic and block unusual behaviors
* Maybe implement a CAPTCHA or similar challenge for users with unusual behavior
* Make sure the storage of all secrets is actually properly protected (password hash, password recovery auth tokens, issued OAuth tokens, etc.)
* Audit logs
If you implement auth(z) by yourself, most likely if you're going to have to sacrifice on some of these points, otherwise you would spend all your time here and never work on your project!
Edit: These tools can be self-hosted and integrated to provide out-of-the-box auth functionality to your application.
* The ORY ecosystem of tools [1]
* Gluu [2]
* Keycloak [3]
[1]: https://www.ory.sh/docs/next/ecosystem/overview
[2]: https://www.gluu.org
Or too expensive compared to doing it yourself.
There's also a difference between rolling your own crypto and rolling your own auth. Leave the actual hash to experts and use NaCL's argon2 implementation. The salt+hash are just more user metadata that aren't super sensitive given modern password hashing algorithms.
My instincts and experience tell me that oauth is more complicated than it needs to be, but I'm still too inexperienced to say for sure. I'm in the early stages of a deep dive of web auth. The frustrating part of learning oauth is most of the articles/videos explain the steps of the flows, but they don't explain why each step exists. ie what are all the security holes that would exist if we skipped this step?
Anyone know any good oauth books/resources that build rationale from first principles?
On an internal work project, we outsource our authentication to Auth0, but stuff like user permissions handling and locking down our APIs has been something we keep pushing back on. We have this worry that, because it's security related, we'll "get it wrong" somehow if we do the authorization stuff ourselves. I've found it nigh on possible to find a nice third-party generic user-permissions web service though. Do such things exist? Libraries that don't have super tight integration with frameworks like Django and Flask? Stuff oriented towards a microservices architecture?
This should apply x100 for security related matters. I feel people only seem to bring this up with regards to hash functions and encryption but I think this should always encompass auth as well.
I use Firebase for auth. It saves development time, there's no user limit on the free tier even and it's battle tested.
I've implemented Gigya, Janrain, Auth0, Firebase and Amazon Cognito.
The only time I've seen them make sense is internal tools. The company I work at has a policy where any enterprise tool must auth with Okta which means logging into everything is a piece of cake for employees.
Some of these products also seem designed and priced around more complex use cases, such as SSO across a bunch of unrelated apps with different supported protocols. Not everyone has that sort of problem.
:)
I'd recommend using something like Fireabase as the front end, that issues JWTs etc., but the actual user database to still yours. Firebase calls this custom-auth. That way, you benefit from their client libraries in multiple languages (Js, Swift, Kotlin, ...), and also from the reliability and security of their server side, but since the actual DB is yours, you have the option of moving to another provider, like Cognito, if need be
"Don't reinvent the wheel" is easily bypassed by just reading auth code from prominent open-source projects to see real-world auth that is secure and works. You don't need a service and using a service doesn't negate an engineer from being competent to implement their own if necessary.