Join the Stack Overflow Community
Stack Overflow is a community of 6.7 million programmers, just like you, helping each other.
Join them; it only takes a minute:
Sign up

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!

share|improve this question
    
    
@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 9 '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 9 '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 9 '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

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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