Architecture of large-scale API (User Management)

Question

We are currently designing an API that will hide different services (Product, Content, User etc) that will be used by our own website, our own apps etc. It is not a public API.

We are looking into using ServiceStack as a foundation, and that might be right.

However, the biggest concern is how to manage the users (each user has 30-50 attributes) and hopefully 100 000+ users.

As I've understand AspNet Identity is nothing for Production so therefore we need to create our own implementation of AspNet Identity.

1. What is your experience of creating a Custom Identity Provider (any examples)?
2. We would like to use several external auth services (OpenId, twitter etc), how should that be managed?
3. How will that then affect the structure of the API (Lets say we are using WebApi instead of ServiceStack). I would like to use as much standard UI as possible.

Any ideas, solutions or examples are appreciated.

Answer 1

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).

Custom IDPs

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.