It’s been about a month since we released the first preview of the new claims-based identity programming model in ASP.NET. Yesterday we published a refresh of the preview with lots of improvements in WS-Federation support, and a brand-new feature: OpenID Connect!

Thanks for the Feedback

The new programming model was very well received, which makes us very happy; however, you were not shy about letting us know which features you wanted us to change and add. I would like to take this opportunity to thank Dominick and Poul for their deep involvement and great feedback!
Among the main points we heard:

• Ensure that the new components are compatible with the Azure Active Directory OAuth bearer middleware
• Maintain consistency with well-established conventions in the framework (e.g. support for SignInAsAuthenticationType)
• Keep the layering which separates pure protocol concepts from the middleware proper

We managed to address all of the above, and more. Besides the inevitable bug fixing, we rearranged the validation pipeline to ensure that every stage receives the info it needs in the notifications; we improved error handling & sign out support; and we verified some notable composite scenarios. Then, we added support for an entirely new protocol

OpenID Connect in ASP.NET and Azure AD!

By now you certainly heard of OpenId Connect, the recently ratified open standard that layers authentication on top of OAuth2 and the JWT token format. For a quick intro see this and this.

Azure Active Directory supported OpenID Connect already for quite some time – every time you sign in the Microsoft Azure portal, that’s what’s you’re using – but we didn’t have support for it in our web programming stack. Well, now we do

If you search the NuGet.org feed for “OpenIDConnect” and include prerelease packages, you’ll find a couple of new packages which contain base classes constituting the OpenID Connect primitives and the middleware proper implementing the protocol.

We’ll give more details (far more details) next week, however: if you want to get a taste of how it works, start by following from start to finish the WS-Federation & OWIN tutorial here.

Once you are done, switching from WS-Federation to OpenID Connect is super easy!

• Install the package Microsoft.Owin.Security.OpenIdConnect (remember, it’s in the prerelease feed)
• Go to Startup.Auth.cs, and substitute the ConfigureAuth implementation with the following:

publicvoid ConfigureAuth(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

    app.UseCookieAuthentication(new CookieAuthenticationOptions { });

    app.UseOpenIdConnectAuthentication(
        new OpenIdConnectAuthenticationOptions
        {
            Client_Id = "d71c88d1-f3d3-47e9-8313-06bc9af9a991",
            Authority = "https://login.windows.net/azurefridays.onmicrosoft.com/"
         }
}

Yes, we did shrink this even further
The most interesting part is the initialization code for the OpenIdConnectAuthenticationOption.

• Client_Id is the unique identifier assigned to your application by Azure AD at creation time. You’ve been using this value for all OAuth2 flows where the app acted as a client: in OpenId Connect you use it in roughly the same way in which you used the realm in WS-Federation
• Authority here represent your Azure AD tenant. AAD exposes metadata describing signing key and issuer values to validate, in analogy to what happens for WS-Federation and SAML: the Authority property is just a convenient way for you to refer to that document without knowing its exact address (which BTW is of the form https://login.windows.net/azurefridays.onmicrosoft.com/.well-known/openid-configuration and can be used directly in the MetadataAddress property if you prefer to set it explicitly)

That’s all you need for adding OpenId Connect sign on to your app!

Of course there’s far more that you could do. For example, with OpenId Connect it is very easy to sign in and at the same time obtain an access token for your app to access other APIs (such as the Graph, Office 365, your own, etc) and the new object model makes it very natural. We’ll talk about this and many other scenarios at length next week!

Next

As the boss of my boss of my boss puts it, “Widely-available secure interoperable digital identity is the key to enabling easy-to-use, high-value cloud-based services for the devices and applications that people use. OpenID Connect fills the need for a simple yet flexible and secure identity protocol and also lets people leverage their existing OAuth 2.0 investments. Microsoft is proud to be a key contributor to the development of OpenID Connect, and of doing our part to make it simple to deploy and use digital identity across a wide range of use cases”.

We were very keen to add OpenId Connect support in our web programming stack, and we are doubly excited to do so in the new OWIN security components in ASP.NET. You have been great in giving us feedback during the first preview, we hope you’ll find the time to try the new bits and let us know what you think:

• You can file bugs in https://katanaproject.codeplex.com/workitem/list/basic
• Use https://katanaproject.codeplex.com/discussions for discussions
• Drop by the Jabbr room for OWIN in https://jabbr.net/#/rooms/owin for chatting with the team in real time

In addition, if next week you happen to be at S.Francisco and you want to chat about this come find us, either on the //BUILD conference floor or at this meetup: we’ll be happy to give more details.

Thanks and enjoy!