Theoretically speaking, it's possible to entirely delegate the authentication and/or authorization tasks to existing external, third-party providers such as those we mentioned before; there are a lot of web and mobile applications that proudly follow this route nowadays. There are a number of undeniable advantages in using such an approach, including the following:

• No user-specific DB tables/data models, just some provider-based identifiers to use here and there as reference keys.
• Immediate registration, since there's no need to fill in a registration form and wait for a confirmation email--no username, no password. This will be appreciated by most users and will probably increase our conversion rates as well.
• Little or no privacy issues, as there's no personal or sensitive data on the application server.
• No need to handle usernames and passwords and implement automatic recovery processes.
• Fewer security-related issues such as form-based hacking attempts or brute-force login attempts.

Of course, there are also some downsides:

• There won't be an actual user base, so it will be difficult to get an overview of active users, get their email address, do statistics, and so on
• The login phase might be resource-intensive, since it will always require an external, back and forth secure connection with a third-party server
• All users will need to have (or open) an account with the chosen third-party provider(s) in order to log in
• All users will need to trust our application because the third-party provider will ask them to authorize it for accessing their data
• We will have to register our application with the provider in order to be able to perform a number of required or optional tasks, such as receiving our public and secret keys, authorizing one or more URI initiators, and choosing the information we want to collect

Taking all these pros and cons into account, we can say that relying on third-party providers might be a great time-saving choice for small-scale apps, including ours; however, building our own account management system seems to be the only way to overcome the aforementioned governance and control-based flaws undeniably brought by that approach.

In this book, we'll explore both these routes, in an attempt to get the most--if not the best--of both worlds. In this chapter, we'll create an internal membership provider that will handle authentication and provide its very own set of authorization rules; in the following chapter, we'll further leverage that same implementation to demonstrate how we can give our users the chance to log in using a sample third-party auth provider (Facebook) and use its SDK and API to fetch the data that we need to create our corresponding internal users, thanks to the built-in features provided by the ASP.NET Core Identity package.