Integrating Claims and OAuth2

I just created a sample library that illustrates how Claims can be easily integrated when using OAuth2 identity providers for authentication. I created the OAuth2 library from scratch (it was quite straightforward). In this library I wanted to hide as much of the OAuth2 protocol and claims mapping as possible so that a consuming application would just have to say which OAuth2 provider to use and what page/URL to return the user to once all the login and claims magic has happened.

Is very easy to use from MVC (these client IDs and secrets are throw-away):

static void RegisterOAuth2Clients()
{
    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Google,
        "421418234584-3n8ub7gn7gt0naghh6sqeu7l7l45te1c.apps.googleusercontent.com",
        "KDJt_7Rm6Or2pJulBdy0gvpx");

    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Facebook, 
        "195156077252380",
        "39b565fd85265c56010555f670573e28");
            
    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Live, 
        "00000000400DF045",
        "4L08bE3WM8Ra4rRNMv3N--un5YOBr4gx");
}

Here’s my view to give the user a choice as to which provider to use:

<h2>Login With:</h2>
<ul>
  <li>@Html.ActionLink("Google", "Login", new {type = ProviderType.Google})</li>
  <li>@Html.ActionLink("Live", "Login", new {type = ProviderType.Live})</li>
  <li>@Html.ActionLink("Facebook", "Login", new {type = ProviderType.Facebook})</li>
</ul>

And then you just have a Login action method to choose the OAuth2 provider you want to use:

public ActionResult Login(ProviderType type)
{
    // 1st param is which OAuth2 provider to use
    // 2nd param is what URL to send the user once all the login magic is done
    return new OAuth2ActionResult(type, Url.Action("Index"));
}

And that’s it. Once the login has happened claims are available viaClaimsPrincipal.Current.Claims (which is where they normally are).

If you’re familiar with using OAuth2 you’re used to seeing a authorization code callback endpoint. This is a detail of the protocol I wanted to encapsulate so that the consuming application didn’t have to “deal” with that. To hide this I use an AreaRegistration internally in the library to define the callback endpoint. In this area when the OAuth2 callback arrives with the authorization code, the library continues the protocol to exchange the code for a token and then uses that token to obtain the profile information for the user. Once that profile data is acquired, it is converted into claims. Then the WIF Session Authentication Module (SAM) is used to log the user in. We then redirect back to the URL indicated in the OAuth2ActionResult above. Magic!

Code is up on GitHub. Library is up on NuGet. Feedback is welcome.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s