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?

  • 1
    What do you mean by "other applications"? Are we talking about how to apply web authorization to client applications?
    – Neil
    Sep 22 '14 at 8:27
  • Do you mean some sort of API key/tokens authorization?
    – jao
    Sep 22 '14 at 8:32
  • use [authorize()] keyword if needed authorization at each action
    – Tushar
    Sep 22 '14 at 9:55
  • By other applications I mean Client applications (Web Application A and B are using the WebAPI services by invoking REST calls). I think I need some sort of tokens, maybe public private keys? Sep 22 '14 at 11:23
  • 1
    I recently found this blog post. I believe it will solve your problem. codebetter.com/johnvpetersen/2012/04/02/…
    – ajagelund
    Sep 23 '14 at 8:07

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.