OpenID Connect and the IdentityServer Roadmap

Since OpenID Connect has been officially released now, I thought I’ll tell you a little bit more about our plans around our identity open source projects.

IdSrv is a very popular identity provider with excellent support for WS-Federation and WS-Trust. It has decent support for OAuth2 and OpenID Connect (basic client profile) since quite some time – but these protocols were more like an afterthought than part of the initial design. IdSrv uses by default the pretty dated ASP.NET membership, but can be easily extended to use different data stores.

We built AS because we wanted to implement OAuth2 “the right way” and we thought it is easier to start from scratch than retrofitting it into IdSrv. We deliberately didn’t add any authentication / user management pieces to AS because we wanted it to be freely combinable with existing infrastructure. For people without existing infrastructure, this was often a problem because setting up the IdP and AS at the same time was a steep learning curve.

While both projects solved very specific problems, there was room for improvement:

  • Combine identity management and a full featured OAuth2 implementation in a single component – still be able to use them independently if needed
  • Make it more lightweight so it can be hosted more flexibly
  • Incorporate OpenID Connect true cross platform client / relying party support (which was always a problem with WS-Federation)
  • Make authentication and acquisition of access tokens possible in a single round trip – which is a scenario that becomes more and more common.

So we actually decided to combine all those improvements and feature ideas into a new project currently codenamed “IdentityServer v3” :

  • Single codebase and server component to deploy
  • OpenID Connect and OAuth2 as the core protocols – but extensible to add support for e.g. WS-Federation
  • Built as an OWIN/Katana component with no dependencies on a specific host (e.g. IIS)
  • Completely customizable – think “STS toolkit”
  • Ability to incorporate arbitrary identity management systems – support for Brock’s MembershipReboot and ASP.NET Identity by default
  • Separation of core STS and user / configuration management for more flexibility
  • ..and more

We are not done yet – but will have more details soon – in the meantime – here’s a preview screenshot of a consent screen for a native client requesting identity claims (user id and email) as well as access tokens for an HTTP API backend.


Posted in AuthorizationServer, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 22 Comments

Test driving the WS-Federation Authentication Middleware for Katana

Microsoft just released an alpha version of the “most wanted” middleware for Katana: WS-Federation authentication!

I tested the bits against ADFS and of course – IdentityServer – and it is unspectacularly easy to get started (that’s a good thing).

1 The WS-Fed middleware itself
As with all other middlewares you wire it up in your Startup class:

app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions


    MetadataAddress = https://idsrv.local/…/metadata.xml,

    Wtrealm = “urn:owinrp”,


    TokenValidationParameters = new TokenValidationParameters


        ValidAudience = “urn:owinrp”



Remember the various configuration entries for the FAM and SAM in web.config – those have been essentially condensed down to the MetadataAddress property. Nice!

Of course you can still take control over validation yourself. But that’s for a future post.

2 Establishing the local authentication session
In WIF the FAM used the SAM to sign in locally (and that was hardwired). The equivalent of the SAM is now the Katana cookie middleware. It is not yet as feature rich as the SAM (e.g. chunking and reference mode missing) – but it is an alpha release.

app.UseCookieAuthentication(new CookieAuthenticationOptions


    AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType


Contrary to the normal Katana authentication middleware design pattern, where you specify which middleware to use to establish the local session (the SignInAsAuthenticationType property), the cookie middleware you want to use must “listen” to a pre-defined authentication type. I hope this will change in later versions.

3 Signing in
To initiate the WS-Fed handshake, you simply emit a 401:

app.Map(“/login”, map =>


    map.Run(async ctx =>


        if (ctx.Authentication.User == null ||



            ctx.Response.StatusCode = 401;








Again there are some open questions, e.g. will the Katana AuthenticationManager APIs like AuthenticateAsync or Challenge in active and passive mode scenarios behave as expected. We will find out in a future post!

4 Signing out
Signing out works like this:

app.Map(“/logout”, map =>


    map.Run(async ctx =>







This does a federated sign out.

5 Access the claims
…and finally we have access to the user’s claims in our application:

app.Run(async ctx =>


        var user = ctx.Authentication.User;

        var response = ctx.Response;


        response.ContentType = “text/html”;


        if (user.Identity.IsAuthenticated)


            await response.WriteAsync(string.Format(“<h2>{0}</h2>”,



            await response.WriteAsync(“<dl>”);

            foreach (var claim in user.Claims)


                await response.WriteAsync(string.Format(

                    “<dt>{0}</dt> <dd>{1}</dd>”,




            await response.WriteAsync(“</dl>”);




            await ctx.Response.WriteAsync(“<h2>anonymous</h2>”);




This is an excellent start. More to come!

(full gist is here)

Posted in IdentityServer, Katana, OWIN | 5 Comments

Workshop: Identity & Access Control for modern Web Applications and APIs

Brock and I are currently working on a brand new two day workshop about all things security when building modern web applications and APIs.

You can either attend the full two day version at NDC Oslo (June) – or a stripped down one day version at SDD London (May). Both still have early bird offerings.

Hope to see you!

With ASP.NET MVC, Web API and SignalR tied together using the new OWIN and Katana framework, Microsoft provides a compelling server-side stack to write modern web applications and services. In this new world we typically want to connect client platforms like iOS, Windows or Android as well as JavaScript-based applications using frameworks like AngularJS.

This two day workshop is your chance to dive into all things security related to these new technologies. Learn how to securely connect native and browser-based applications to your back-ends and integrate them with enterprise identity management systems as well as social identity providers and services.

Tags: WS-Federation, SAML, OAuth2, OpenID Connect, OWIN, JSON Web Tokens, Single Sign-on and off, Federation, Delegation, Home Realm Discovery, CORS

Day 1: Web Applications

  • Authentication & Authorization on .NET 4.5 and beyond
  • Introduction to OWIN and the Katana Project
  • Katana Security Framework
    • Cookie-based Authentication
    • Enterprise Authentication with WS-Federation
    • Social Logins (e.g. Google, Facebook, Twitter, etc.)
    • OpenID Connect
  • Web Application Patterns
    • Single Sign On / Single Sign Off
    • Federation Gateway
    • Account & Identity Linking
    • Delegation
    • Home Realm Discovery

Day 2: Web APIs

  • ASP.NET Web API Security
    • Architecture
    • Authentication & Authorization
    • CORS
    • Katana Integration
  • Web API Patterns
    • Token-based Authentication
    • Delegated Authorization
  • OAuth2
    • Flows
    • Scopes
    • OAuth2 Middleware
    • Federation
  • OpenID Connect (revisited)
  • Bringing it all together


Posted in AuthorizationServer, Conferences & Training, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 14 Comments


To be more in-line with the OWIN / middleware mindset (and because Damian said so) – I broke up our OWIN security assembly into smaller components:*

Currently there are four packages:

  • Basic Authentication
  • X.509 client certificate authentication
  • Claims transformation
  • Requiring SSL and client certs

…plus a base package with various helpers…

A sample showing all four main packages together can be found here.

More to come…

Posted in IdentityModel, Katana, OWIN, WebAPI | Leave a comment

Using AuthorizationServer with Nancy (updated)

Since I am currently in the process of updating AuthorizationServer and its samples – I thought it would be the right time to throw away my custom Nancy extensions and use Damian Hickey’s nice Nancy.MSOwinSecurity package instead. The outcome is quite pleasing.

The Startup class now looks exactly like the Web API one (OWIN FTW yay):

public class Startup


    public void Configuration(IAppBuilder app)


        // no mapping of incoming claims to Microsoft types

        JwtSecurityTokenHandler.InboundClaimTypeMap = ClaimMappings.None;


        // validate JWT tokens from AuthorizationServer


            issuer: Constants.AS.IssuerName,

            audience: Constants.Audience,

            signingKey: Constants.AS.SigningKey);


        // claims transformation

        app.UseClaimsTransformation(new ClaimsTransformer().Transform);





…and the controller *cough* module looks like this:

public class IdentityModule : NancyModule


    public IdentityModule() : base(“/api/identity”)





        Get["/"] = _ =>


                var user = Context.GetMSOwinUser();


                var claims = from c in user.Claims

                                select new ViewClaim


                                    Type = c.Type,

                                    Value = c.Value



                return Response.AsJson<IEnumerable<ViewClaim>>(claims);





Full sample here.

Posted in AuthorizationServer, Katana, OAuth, OWIN | 5 Comments

AuthorizationServer v1.2

I just uploaded version 1.2 of AuthorizationServer.

The big change is that AS is now using MVC and Web API v5.1.1 – additionally there are some bug fixes and a new configuration switch – set the following appSetting to false if you want to pass through all incoming IdP claims (default is true):

<add key=”authz:FilterIncomingClaims” value=”true”/>


Posted in AuthorizationServer, OAuth, WebAPI | 3 Comments

How MembershipReboot stores passwords properly

Originally posted on brockallen:

I’m not going to go into all of the motivation behind proper password hashing — Troy’s done an excellent job of it and he has said it all better than I ever could have. The short version is that we assume that an attacker will eventually compromise the database and that we need to store passwords in a way to make it very hard for attackers to then extract the stored passwords. This leads to the modern approach to storing passwords which is done with a “password stretching” algorithm where you salt and hash in a loop for tens of thousands of iterations. The general consensus is that it should take about one second to compute a password hash. The number of iterations to arrive at one second is hardware dependent. One issue is that hardware gets better over time, so the number of iterations should adjust to…

View original 579 more words

Posted in Uncategorized | Leave a comment