Weakness in oAuth 2.0 - what are the alternatives?

4
votes

I am working on a mobile application that uses an api built with ASP.NET web api framework. We decided to use ACS alongside a custm STS as a mechanism to secure the api. We are using a custom STS because we need to authenticate users against our own identity store.

The information flow is as follows:

  1. Mobile app calls the custom STS with user credentials.
  2. User is authenticated against our own identity store.
  3. Once user is authenticated an authorization code is retrieved from ACS and used to retrieve an SWT access token.
  4. Token is returned to mobile app.
  5. Mobile app embeds access token in authorization header and fires request to API
  6. HTTP module in API validates the access token and data is returned if the token is valid.

Everything is done over SSL as we are using oAuth 2.0.

The problem with oAUth 2.0 is that it is at risk from man-in-the-middle attack as the SWT token issued by ACS is a raw token and not encrypted in any way. It is however, signed using a 256bit symmetric key.

We are using swt tokens because we are using an http based approach and the token fits nicely into the auth header of an http request.

Microsoft have provided some ACS security guidelines in the following post: http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx

we currently implement 2 of these as we check the issuer and the audience i.e that the token was issued by our trusted issuer (ACS) and that the token was issued for the correct audience (our api).

our scenario is based on the following article: http://msdn.microsoft.com/en-us/library/hh446531.aspx as such WIF is not used to handle incoming tokens. WIF is only used in claims processing.

given the above mentioned scenario is there anything else that we could be doing to improve the implementation we have to secure our rest based api?

any and all comments/criticism/suggestions welcome.

Thank you.

1
oauthacs
SSL mitigates the risk of man in the middle attacks. Without it, there's definitely an open door for that kind of attack to happen on your app. – Eugenio Pace

1 Answers

2
votes

I think you're already taking the correct approach. The most important thing is to verify if the token is signed by ACS. Never share your ACS secret key with anyone else. If they don't know the key, they cannot forge the signature.

Also do not store confidential information in the token (such as password, credit card number, etc.). You should expect the token may be obtained by someone else, but no one can forge a token with the correct signature.