How to use OAuth with Forms auth

Daniel picture Daniel · May 21, 2014 · Viewed 7.2k times · Source

What solutions are out there for combining a Form auth with a OAuth auth ?

Use Case:

There is an website where a user would login with a username and password and after he is auth a token will be provided, which enables access to different resources in the app for a period of time.

Now the Product Owner want's Facebook/Twitter/... Auth.

Posible solutions:

solution 1- AssServer tries to validate the Facebook ticket

edit sequence diagram

Answer

Sinaesthetic picture Sinaesthetic · May 31, 2014

We're actually doing this on our project. The solution was really simple. Here were the major points

  • Keep in mind that the OAuth spec recommends against storing the oauth bearer token on the client.
  • Make sure it is the app server that is making the auth requests to the oauth provider. Don't do it from the client (except on the authorization step because you don't really have a choice).
  • Leverage the framework. Let the membership provider handle authentication ticketing.
  • Create your custom membership provider and have it manage the auth process with your 3rd party provider.
  • Once auth succeeds, store the tokens in the session or within a claim with the user identity. In other words, keep the access and refresh tokens on the server.
  • Allow the framework to generate the auth ticket like it normally would
  • Between the auth ticket and the session cookie, you can retrieve the access token from the session/claim for making resource requests.
  • When associating the 3rd party login, you'll obviously have to make a call with the access token to the provider in order to get some info such as a facebook user id. Use that to link your internal user with the facebook user.

Other things to consider:

  • Make sure you destroy the session on sign out. Several frameworks will empty the cookie values but recycle the session id. Make sure the session id isn't being recycled.
  • Use an anti-forgery token with any request that requires session info which should just about everything. This will help you ensure that the session cookie wasn't hijacked.

Now, I think this is an important point: Typically, with providers like facebook and twitter, you use the authorization flow which means you have to use their form to login. They handle it, not you. There is a username/password "option" (grant_type: password) with OAuth 2.0 but I don't know if those providers allow it because that flow doesn't require the application to identify itself.

I think you pretty much got it. The authorization grant flow would be something like this: enter image description here

The password grant flow would be pretty much the same, but with out the redirect and authorization steps. You would just login with your own form and have the server make the auth request to the provider using the password grant type.

If you're just using it for authentication only, then you wouldn't be making a request with that particular access token to their resource server. I'd need to know more about your architecture to say more. However, generally, if you have an internal identity provider that handles roles and identity, you might consider a federated identity provider that can transform 3rd party tokens into your internal format and store that along with the 3rd party token. That way you can still make requests to the 3rd party if needed and still have what you need to move around internally if that makes sense. If that's even a concern, let me know and I'll explain that leg too.