Skip to content

Native OIDC client sample for Windows that uses custom URI scheme handler

January 20, 2018

Since the release of our IdentityModel.OidcClient client library we have had iOS and Android samples for using the system browser to allow a user to authenticate with the token server. Receiving the results from the system browser is interesting since the native client application is in a different process than the system browser. Fortunately those platforms provide an easy way to map a custom URI scheme (used in the client’s redirect_uri) to the native client application. This allows the response parameters from the authorize endpoint to be passed from the system browser into the native client so it can complete the protocol workflow.

Windows also has such a facility, but we never had a sample for it… until now. I just created a sample that does this.

There are two main aspects that are specific to Windows clients. First, the application needs to add certain registry keys to enable this mapping. The sample adds them when it starts. Second, when the browser redirects to the custom URI scheme it launches a new instance of the client application. This means the first instance that initiated the request is still waiting for the response. The second instance needs a mechanism to deliver the results to the first. The sample handles this by using named pipes.

I certainly had to dust off all the Win32 API cobwebs I had rattling around in the back of my brain. Anyway, check it out and hope it helps.

Sponsoring IdentityServer

December 18, 2017

leastprivilege.com

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)
{
   services.AddMvc();
   services.AddAuthentication(options=>
   {
      options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
   }).AddCookie();

   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);
   }
}

HTH

 

Demos — DevTeach Montreal, July 2017

July 7, 2017

The demos and slides for my sessions from DevTeach are here: https://1drv.ms/f/s!AjXKCyy1XZYBjyO7i8tyom6PhJM_ and the home page for IdentityServer is http://identityserver.io/.

Thanks for coming!