If you do want to store users locally, you have some adapters you can use. They leave a lot of room for interpretation (or rather implementation), meaning that you will probably have to implement a lot of stuff from zero!
Ory Kratos is like the system behind the Google, Twitch, or Pipedrive profile management, so it has the database of users and it offers variety of user flows for e.g. updating sensitive information, adding WebAuthn 2FA, managing one's profile, and so on.
To conclude, you most likely will be able to combine NextAuth with Ory Kratos or Ory Hydra if it makes sense for your use case!
Also, authentication and authorization are core for an app. If we do authentication here, how does authorization work? Can I bring my own authorization like oso etc.
1. What do you do when a user with email "foo@example.org" has already signed up, and now is trying to sign up using Google with "foo@example.org"?
2. How do you ensure that a user can update sensitive information (e.g. their recovery email address, or linking additional "Sign in with" providers) while keeping a balance between security and user experience?
3. What if you now want to add biometric auth for native mobile apps, or 2FA?
The complexity in building your own is not starting with the first 10%. As your app and business grows, teams are faced with ever increasing requirements. Leaning on an established open source provider built by experts in the area just saves you so much time, headaches, and potential security oversights!
> What Db does Ory use? Should we set up our own.?
We support all prominent SQL systems - so PostgreSQL, MySQL, CockroachDB, SQLite, ... - and of course all cloud SQL vendors. You can also choose to run Ory in Ory Cloud, then we take care of all of this for you!
> Also, authentication and authorization are core for an app. If we do authentication here, how does authorization work? Can I bring my own authorization like oso etc.
Absolutely! We have a project for this also: https://github.com/ory/keto
Hope this clarifies your questions!
> The functionality provided for credentials based authentication is intentionally limited to discourage use of passwords due to the inherent security risks associated with them and the additional complexity associated with supporting usernames and passwords
I cannot disagree more. Using 3rd party auth has a lot of issues such as data privacy (requirement of stating that in your privacy/GDPR policy if you are in the EU), increased user support request when they cannot remember which auth provider they used, or the ever growing cases in which Facebook/Google/Whatnot decide to close someones account without possibility to appeal and effectively shutting them out of your App. Or the risk that if Google/FB/Github might not like your webapp, they can disable auth for your users with the flip of a switch. Me personally, I avoid 3rd party auth for those reasons alltogether.
It's also important to note that almost no 3rd party providers offer the ability to require 2FA as part of their flows. So if you need 2FA and similar, you'll end up with your own system again. And you'll probably use passwords, because proving that you own two things - eg email and device - is not a second factor. If someone steals your laptop (something you no longer own :D ) it's just one factor!