MVC5 – Most Appropriate Authentication Type for MVC5 Project

It sounds like there are two goals:

1. Easy for end-users to authenticate with their existing social accounts
2. Easy for developers using your webservice

Authorizing people to use resources on your site makes OAuth2 a preferred mechanism due to the popularity and availability of client libraries.

1. Easy for end-users to authenticate with their existing social accounts

The end-user visits a site that uses your API and chooses to login. They are sent to your OAuth login page. Your login page shows a normal username and password prompt for accounts managed on your site and a set of social auth buttons where they can click to login via a site like Facebook. When the user chooses Facebook you redirect them to Facebook to approve the choice (starting the facebook auth flow). When the end-user completes the login at Facebook they are redirected back to your site.

When the user is redirected back to your site from Facebook you save that user's information into a user record in your database and then generate a new session for that user. You immediately redirect the end-user to their original downstream site with the oauth access_token, completing the original oauth flow.

2. Easy for developers using your webservice

If you are the provider of authorization then you should create a simple interface for developers to depend upon which does not change every time you add a new upstream auth provider which doesn't implement oauth perfectly. This is why I believe you should implement an OAuth2 provider site and that site should be a consumer of the social auth sites.

To the developer using your nice rest API, they will not be aware of the Facebook interaction unless you choose to give them a hint through the session capture post (for example).

TL;DR

Make consumers of your APIs like you by implementing OAuth2 and hiding social auth complexities. You can, during your oauth flow for your downstream sites, trigger an additional oauth flow with facebook.

Image because picture == words * 1000:

Can we call this oauth2-piggy-back?

Step by step flow

1. End user visits site that uses your API
2. End user is sent to your site to authorize or signup (oauth2)
3. End user picks social auth, clicks facebook login button
4. Your site sets a cookie or sets the state in the facebook oauth to know where the user came from
5. End user redirected to Facebook and accepts connection at facebook site
6. End user redirected to your site to complete facebook auth process
7. You lookup or create the user in your database
8. You create a new session on your server
9. You redirect the user back to their original site with your session token

It is impossible to prevent this issue from happening completely. There are two things you can do that will help but not completely migrate the problem:

• Use SSL only: If you control both the client and the server than there is no reason you can't encrypt the traffic, this prevents people from sniffing out your API calls by studying your traffic - it also protects user secrets and help prevent man-in-the-middle attacks.

• Use a Api Key. This should be a hidden key that can be attached to transactions that validates that the API call came from an approved application. Note that this is only useful if the traffic is encrypted, since the key is useless if it's visible over plain text.

Again, it is not possible to protect oneself completely as the nature of the web is pretty insecure. It wasn't built with security in mind initially so you should assume that anything exposed publicly can/will be used by another party at some point.