0

I've seen a lot of questions regarding OAuth and using it to secure APIs using an external trusted provider.

However, in our organization, we have an existing ASP.NET MVC web application which contains a custom membership provider for authenticating users to use the web application. We are now developing an API (which will be accessed externally) which allows users of the API develop their own clients.

I am looking into different ways to secure the API without passing user credentials. The API will force HTTPS, but the security team does not want user credentials stored on the client systems. I have considered, a token based approach -- but most posts I have read here seem to suggest OAuth. Would the preferable route be some sort of OAuth implementation? And if so, how do I authenticate internal users who are not registered with a trusted provider?

Thanks!

ohlando
  • 321
  • 1
  • 7
  • http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server – spender Jul 09 '14 at 13:52
  • @spender I've downloaded and played with that sample, but even there, it appears to require a login through google. The forms login implementation is not complete. – ohlando Jul 09 '14 at 14:16
  • Any single app can have multiple ways of authenticating users. Generally speaking your log in form should present 2 options: one for the oauth provider of choice and one for internal. Once that selection is made then you authenticate using the chosen mechanism. stackoverflow.com itself does this. I'm not entirely sure what the issue you are having actually is. – NotMe Jul 09 '14 at 16:37
  • @ChrisLively the issue is that ALL users (both web and API) are internal users and would only have accounts on **our** system. Users will not be allowed to login using accounts from other systems. – ohlando Jul 09 '14 at 17:17
  • Then why are you bothering with oAuth at all? The purpose of oauth is to allow a user to use a single account for multiple systems and therefore get past the problem of a single user trying to maintain lots of different logins. If you are forcing them to have an account just for your system then there appears to be no reason to implement an oauth provider at all. – NotMe Jul 10 '14 at 15:38
  • You might want to read this: http://stackoverflow.com/questions/11775594/how-to-secure-an-asp-net-web-api/11782361#11782361 it's a much better route. – NotMe Jul 10 '14 at 15:46
  • @ChrisLively The only reason I wanted to implement OAuth at all was that access to the API did not require user credentials to be stored on the client and used for authentication on the server. This would allow access to each API be revoked independently. HMAC authentication is a good solution though -- if not overkill for transporting data over an already SSL secured connection. – ohlando Jul 14 '14 at 13:50

1 Answers1

0

One approach can be to use OAuth token created Microsoft ACS.

If each client user needs to be authenticated, you can use Microsoft ACS to create a trust relationship between you and the client organization (Id Provider) or even other Id providers such as Facebook / Google etc.

Alternatively you can also use service identities for each API client (assuming that each user does not need to authenticated) The clients gets a unique clientId and Secret created by your organization, that you can revoke when needed. The client requests a OAuth2 (JWT) token from ACS and send the token on each API calll. The API validates the token using standard OWIN library for JWT tokens.

Haroon
  • 1,052
  • 13
  • 28