ASP.NET Identity comes in two flavors:
- You can use your own signin, which will essentially become a 'private IDP' for you.
- You an use external IDPs (Facebook, Twitter, LinkedIn, etc.) via ASP.NET Identity, which will handle all the complexity.
I am not sure which option is "nothing for Production" in your opinion. If you can explain the concerns, the response here can be better.
Even when you use external IDPs, ASP.NET Identity can/will create a database with the user so the application can store additional attributes.
In any case, 100K+ users with 30-50 attributes seems something that a single server should be able to handle easily (with or without ASP.NET identity).
The general issue with custom IDPs is that a dedicated engineer (or team) is needed to ensure all is in place.
- There is cost for initial implementation, esp. with ensuring that all the security requirements are met.
- There are support costs associated with forgotten passwords, hacked accounts, etc.
- There are engineering improvements needed for new features (two-factor auth, SMS, then email, then something else), security improvements (e.g. a crypto algorithm considered vulnerable suddenly) and production issues.
- If the system is compromised or shown as weak by someone else, it is a significant public relations issue for the company.
Using External IDPs
You can achieve this using several technologies or providers: ASP.NET Identity, Azure Access Control Service, OpenID, Auth0 to name a few. All of these will provide a single interface for your application, or you can write directly against Google, Facebook, Twitter, Microsoft Account.
Once a user logs in, whichever service you use, it will provide you claims which you can consume in your application to find a user's email address, first name, last name, etc.
- The advantage of using a unifying service (such as Access Control Service) is that it will use only one protocol, and send tokens in a fixed token format regardless of what was used for authentication, and so the application has to communicate using one interface only.
- If external IDPs are used directly (e.g. Google, Facebook, Twitter, etc.) the application needs to parse and understand each token, which can vary in the claims contained in them for the same user attribute (e.g. one token may have first_name, another one may have givenName, etc.)
- The application may also need to handle multiple protocols (such as OAUTH, SAML) unless it is restricted to a single protocol, which would be OAUTH for most social IDPs, including Microsoft Account, Facebook, Google, Twitter, LinkedIn, etc.
Effect on the structure of the API
Authentication should not affect the public facing API that an app builds. In fact, authentication is handled in the way it is today (i.e. via IDPs) so it can be disconnected from the actual application, which can vary regardless of how the users authenticate.