WebAPI authorisation for other apps

Question

I would like to create a WebAPI application that can serve some of my web sites. My goal is to abstract some common task such as email sending, address resolving etc by providing an API to all of my web sites.

I have created a WebAPI application that implements most of the above APIs but without any authorization. I would like to restrict the access only to my applications.

I could implement identity 2.0 or membership provider but all these are meant to be used from users and not from other web sites. My clients are web sites and not just users.

What would be a good and secure approach to this problem?

Answer 1

You're trying to limit the use of your shared (Web) API so only your sites can use the API.

An alternative to OAuth mentioned by Joe would be to create API controllers in your sites that use your shared API. So, a client would send a request to an API controller on their site and that API controller would call your shared API method. Your site's API controller can then directly return the results to the client. So:

Client --> Site API --> Central API
Client <-- Site API <------|

The advantages of this approach:

• You can secure the requests to the central API with an IP-filter in IIS, because only the sites server's IP addresses are allowed to use the central API. This is probably less complex and quicker to implement than OAuth.
• You won't have to deal with cross site requests in the client, which might get blocked by browsers.
• You can modify or cache the response from the central API if you want to do that. This way you can have site specific modifications without the need to modify the central API.

Answer 2

If what I assume is correct, you need to mimick what facebook/linkedin/twitter have and create something similar to:

OAuth ("The OAuth 2.0 Authorization Framework", RFC 6749)

What this means is that the client applications need to obtain the required keys to be allowed to access users/user-data from the single login.

The issue with this type of scenario is that it can become quite complex (so hopefully you're working with a team).

Some of the reasons it will become complex:

• Building out the internal infrastructure to deal with Authorization and the passing of data to client applications
• Security of the login feature (your service will be handling all logins and will need to at least have strong encryption, etc.)
• Maintaining an API/documentation that provides all the required information for other developers to use the API to access users/user-data

---

Another suggestion I might consider is to create a "thin" login functionality that lives below all other applications (basically, it is a single application that is structured in a way where all other applications are built on top of it (it sounds similar to what an API is, but it is different in the sense that the login and client application are more strongly coupled).

The main point you should realize from this is that any solution you find will be "somewhat" complex to implement (based on your exp. and how many are in your team, etc.).