Skip to content

Sponsoring IdentityServer

December 18, 2017

Brock and I have been working on free identity & access control related libraries since 2009. This all started as a hobby project, and I can very well remember the day when I said to Brock that we can only really claim to understand the protocols if we implement them ourselves. That’s what we did.

We are now at a point where the IdentityServer OSS project reached both enough significance and complexity what we need to find a sustainable way to manage it. This includes dealing with issues, questions and bug reports as well as feature and pull requests.

That’s why we decided to set up a sponsorship page on Patreon. So if you like the project and want to support us – or even more important, if you work for a company that relies on IdentityServer, please consider supporting us. This will allow us to be able to maintain…

View original post 6 more words

Slides — Boston Code Camp, Fall 2017

November 19, 2017

Here are the slides for my session “Implementing Authorization forApplications & APIs” from Boston Code Camp. We plan to announce more in January about the code. Thanks for coming!


The userinfo endpoint is not designed for APIs

November 7, 2017

A common (but incorrect) practice I often see people doing is using the OIDC userinfo endpoint from APIs. It seems like a natural thing to want to do — you have an access token in your API and it contains identity scopes. This means the access token can be used at the userinfo endpoint to access the identity data for those scopes (like profile, email, phone, etc.). The problem is that the userinfo endpoint is designed for the client, not the API (after all, userinfo is defined in the OIDC spec, not the OAuth2 spec).

Another way to think of the problem is that the API has no control over the scopes that access token has been granted. The client controls those scopes. This means your API is taking a dependency on the identity information the client is configured to obtain from the token server, and this is quite brittle. If the client ever changes what identity scopes they request, your API is affected.

A better approach is to configure your API to request the claims that it needs for the user. That’s why there’s a UserClaims property on the ApiResource (and Scope) configuration object model(s) in IdentityServer. These configured user claims will be delivered to the API in the access token itself (or from introspection if using reference tokens). This allows your API to be explicit about what it needs about the user, regardless of the client’s configuration.

DevIntersection Las Vegas, October 2017

September 21, 2017

I will be speaking at DEVintersection this October in Las Vegas. The highlight will be the 2-day workshop on “Identity & Access Control for Modern Applications and APIs using ASP.NET Core”. If you register, use promo code “ALLEN” for a discount.

I also have two sessions, one on the fundamentals of OpenID Connect and OAuth2, and another on an introduction to IdentityServer for ASP.NET Core.

Hope to see you there!

Beware in ASP.NET Core 2.0: Claims transformation might run multiple times

August 30, 2017

In ASP.NET Core, you can add a claims transformation service to your application, as such:

public void ConfigureServices(IServiceCollection services)
      options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;

   services.AddTransient<IClaimsTransformation, ClaimsTransformer>();

And then your ClaimsTransformer might look like this:

class ClaimsTransformer : IClaimsTransformation
   public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
     ((ClaimsIdentity)principal.Identity).AddClaim(new Claim("now", DateTime.Now.ToString()));
     return Task.FromResult(principal);

And that might be fine. But beware that this might be invoked multiple times. If an app has this code (perhaps in different locations in the app which might be likely):

await HttpContext.AuthenticateAsync();
await HttpContext.AuthenticateAsync();

Then each time AuthenticateAsync is called the claims transformer is invoked. So given the above implementation we’d be adding the “now” claim multiple times.

Moral of the story, claims transformation should be more defensive and/or return a new principal, as such:

class ClaimsTransformer : IClaimsTransformation
   public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
      var id = ((ClaimsIdentity)principal.Identity);

      var ci = new ClaimsIdentity(id.Claims, id.AuthenticationType, id.NameClaimType, id.RoleClaimType);
      ci.AddClaim(new Claim("now", DateTime.Now.ToString()));

      var cp = new ClaimsPrincipal(ci);

      return Task.FromResult(cp);



Demos — DevTeach Montreal, July 2017

July 7, 2017

The demos and slides for my sessions from DevTeach are here:!AjXKCyy1XZYBjyO7i8tyom6PhJM_ and the home page for IdentityServer is

Thanks for coming!


VS Live Redmond, August 2017

July 6, 2017

I’ll be doing a 1-day version of our Modern Security for ASP.NET Core workshop at VS Live in Redmond on August 14th, 2017. If you’re interested, you can get $500 off the conference 5-day price by using the code “RDSPK01” at registration.

I’m also doing two sessions: One on User Authentication for ASP.NET Core web applications, and another on Securing APIs in ASP.NET Core.

Hope to see you there!