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


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…

View original post 93 more words

Posted in Uncategorized | 1 Comment

Announcing PolicyServer

Over the course of the last years Brock, Michele and I have all been actively designing and implementing identity solutions for customers of all sizes and industries. Solutions range from simple to complex – and almost always involve both identity (authentication) and access management (authorization).

It turns out that, for authentication there is pretty much always only one right way to do it, once you know all the facts and requirements. Once you are done with the “who is the user” (aka authentication) part, you will inevitably need to solve the “and what is this user allowed to do” (aka authorization) problem next.

So, many people asked us to provide the same turnkey solution for authorization as we do for authentication with IdentityServer.

One very tempting fallacy is that you can use your new and shiny identity system to also distribute authorization data to your applications. This will not work! Despite what some vendors try to tell you when selling their “Identity and Access Management” solution. Identity is universal – authorization is application specific. Blurring those lines will get you in trouble. Back in 2016 I wrote a pretty popular blog post about that – and last year Brock and I did a talk about our ideas at NDC. I don’t want to repeat all that again here.

Since we never really had a good answer, we decided to dedicate some time to think about the problem. We started by observing how our customers implemented their authorization in the past. The results were quite interesting – from highly specialized application logic to “standard” concepts like access control lists (ACLs) or (the failed) XACML, we found that the most prevalent general concept that people use is roles and permissions.

While this doesn’t sound like rocket science – almost no-one took the time to build a general solution for that. They rather re-implemented one or the other aspect of this pattern over and over again for each application they were building.

This was our starting point for what we now call PolicyServer (watch the above NDC video to see an early prototype). We had the following key tenets in mind.

Built from the ground-up for modern applications

With that we mean the modern multi-client, multi-platform, API-driven systems that companies implement today. It must be compatible with all current prevalent architecture styles like cloud, microservices, multi-tenancy (you name it) and of course, uses claims-based identity at its core.

Identity != Permissions

There will be a strict separation of authentication and authorization. This way you can keep your architecture clean and ready for growth. Everything else will become a problem when your software becomes more complex than initially planned.

Identity + Permissions == Authorization

Identity will be the input to the authorization system. A user will most likely have different permissions in different applications – the combination of identity and context produces the actual authorization policy.

Enter PolicyServer

So simply said – PolicyServer allows you to model applications roles, membership and permissions for your applications. But of course, there is much more to it.

Policy design

We want to be able to model arbitrary applications styles – from simple, single applications to application systems and multi-tenanted applications. In PolicyServer, policies are containers for application roles and their associated permissions, but policies can be hierarchical and support inheritance.

Role membership

Membership to application roles can be defined statically (and drawn from the separate identity system) or based on rules and claims-transformation.


Permissions belong to application roles. In your applications, you can use the application roles for coarse grained authorization, and permissions for fine-grained authorization.

Management API and UI

Every management aspect of PolicyServer is API first. There is a full-featured web-based UI for managing policies – but you can also automate everything, or drive policy creation and permission management from your own application.

Auditing and compliance

Permission usage and policy evaluation can be fully audited and the resulting audit trail can be tailored to meet common compliance criteria.

Client libraries

So far we have focused mainly on .NET – this includes a base client library, but also support and deep integration into the new ASP.NET Core policy-based authorization system. This has also been back-ported to MVC5/Web API 2. In the future we will support more common application platforms – but given the API nature of our runtime engine, integration is trivial.


The three of us all have implemented authorization products and solutions for customers in the past, and so PolicyServer is the result of us collaborating – as we all shared a passion for the problem space.

While implementing more and more pieces, it became pretty clear, that this is a lot of work. Given our engagement with our existing open source projects like IdentityServer and IdentityModel, we couldn’t afford to start another OSS project. That’s why we decided to create two versions of PolicyServer.

One version is a free OSS version that includes all the necessary bits and pieces to implement the separation of concerns between authentication and authorization. But it will be for a single application only and not include the management pieces or the advanced modeling capabilities.

The other version is a commercial product that has all the above-mentioned features –  and if you think that would be a good fit for your application – let’s have a chat!

Posted in PolicyServer | 20 Comments

NDC London 2018: IdentityServer Update

We are at NDC in London right now and are about to start our session “IdentityServer4 v2 on ASP.NET Core v2 – an Update”.

For those who can’t be here – you can find my slides on Speakerdeck. There will be also a video recording in a couple of weeks.

Here’s a quick summary.

New web site

Just in time before NDC we managed to release our new web site at This also finally includes a selection of reference customers that we can publicly talk about.

The new ASP.NET Core v2 authentication system

This is the main part of our talk. For the last couple of year Microsoft had a hard time finding the right balance between flexibility and ease of use when it comes to authentication in ASP.NET. That’s why they had to re-write authentication from ASP.NET to Katana to ASP.NET Core v1 to ASP.NET Core v2.

It’s fair to say that that the current version is pretty good – still not exactly the way we like to have it – but it mostly gets the job done. This is also the starting point of our demo.

We gonna show how IdentityServer4 makes use of the new authentication handler system, the new authentication middleware and its DefaultXXX configuration. We show how to use a custom cookie handler instead of ours, how to add support for social logins like Google, how to add WS-Federation support (aka legacy ADFS support – because why else would you care about WS-Federation). We’ll show the brand new SAML authentication handler from Anders Abel and we’ll show how to utilize the new authentication system to add additional API endpoints to your IdentityServer host which are in turn protected by IdentityServer itself – inception!

Speaking of SAML2p – our partner Rock Solid Knowledge has a brand new plugin for IdentityServer4 v2 that adds SAML2p IdP capabilities and allows SSO over OpenID Connect, SAML and WS-Federation.

Logout is hard!

In the information age, data is the new pollution. And it is much harder to get rid of data than to accumulate it. That’s why OpenID Connect has three specs for logout. We always had support for JavaScript-based session management and front-channel notifications. We also added support for back-channel notifications which are generally speaking more reliable then the good old browser iframe “trick” (aka hack). We have a sample for that here.

Admin UI Community Edition

Rock Solid Knowledge created a community edition of their AdminUI product. This gives you a web-based UI to manage users, clients, claims, resources etc. The community edition is limited to 10 users and 2 clients, which is enough to get started.

Best thing is, the AdminUI is available via a dotnet new template. IOW – you’ll have a functional IdentityServer with user and configuration management up and running literally in a couple of seconds. See our templates repo here.

Supporting us

Running an open source project like IdentityServer takes time and effort. We could use your help!

To make that easier for you, we try to be better with up for grabs issues in the future. If you want to get started with contributing to IdentityServer – look for the help wanted label on our issue tracker, and start a conversation. We are happy to help out.

We also see quite some traffic on StackOverflow – if you want to help out other users (and earn some reputation while you go), that would be very appreciated.

And last but not least – if you are working for a company that uses IdentityServer4, you should encourage your boss to sponsor us. This will allow us to expand our efforts – and btw – we also have some interesting marketing options if you company wants to position itself as modern and thus OSS friendly/supporting. Go check out our Patreon page for more info.

Supporting you

Brock and I are still doing on-site/remote training and consulting. Let us know if we can help you with anything in the identity & access control space!

We also have an infrastructure to offer production support.

OK – that’s it for IdentityServer4. We have more exciting news here at NDC – stay tuned.

Posted in .NET Security, ASP.NET Core, IdentityServer, Uncategorized | Leave a comment

Sponsoring IdentityServer

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 this level of commitment.

Thank you!

Posted in .NET Security, ASP.NET Core, IdentityServer, OAuth, OpenID Connect, Uncategorized, WebAPI | 1 Comment

Updated Templates for IdentityServer4

We finally found the time to put more work into our templates.

dotnet new is4empty

Creates a minimal IdentityServer4 project without a UI.

dotnet new is4ui

Adds the quickstart UI to the current project (can be e.g added on top of is4empty)

dotnet new is4inmem

Adds a basic IdentityServer with UI, test users and sample clients and resources. Shows both in-memory code and JSON configuration.

dotnet new is4aspid

Adds a basic IdentityServer that uses ASP.NET Identity for user management

dotnet new is4ef

Adds a basic IdentityServer that uses Entity Framework for configuration and state management


Install with:

dotnet new -i identityserver4.templates

If you need to set back your dotnet new list to “factory defaults”, use this command:

dotnet new --debug:reinit

Posted in ASP.NET Core, IdentityServer, OAuth, OpenID Connect, WebAPI | 8 Comments

Missing Claims in the ASP.NET Core 2 OpenID Connect Handler?

The new OpenID Connect handler in ASP.NET Core 2 has a different (aka breaking) behavior when it comes to mapping claims from an OIDC provider to the resulting ClaimsPrincipal.

This is especially confusing and hard to diagnose since there are a couple of moving parts that come together here. Let’s have a look.

You can use my sample OIDC client here to observe the same results.

Mapping of standard claim types to Microsoft proprietary ones
The first annoying thing is, that Microsoft still thinks they know what’s best for you by mapping the OIDC standard claims to their proprietary ones.

This can be fixed elegantly by clearing the inbound claim type map on the Microsoft JWT token handler:


A basic OpenID Connect authentication request
Next – let’s start with a barebones scenario where the client requests the openid scope only.

First confusing thing is that Microsoft pre-populates the Scope collection on the OpenIdConnectOptions with the openid and the profile scope (don’t get me started). This means if you only want to request openid, you first need to clear the Scope collection and then add openid manually.

services.AddAuthentication(options =>
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
    .AddCookie("Cookies", options =>
        options.AccessDeniedPath = "/account/denied";
    .AddOpenIdConnect("oidc", options =>
        options.Authority = "";
        options.ClientId = "server.hybrid";
        options.ClientSecret = "secret";
        options.ResponseType = "code id_token";
        options.SaveTokens = true;
        options.TokenValidationParameters = new TokenValidationParameters
            NameClaimType = "name", 
            RoleClaimType = "role"

With the ASP.NET Core v1 handler, this would have returned the following claims: nbf, exp, iss, aud, nonce, iat, c_hash, sid, sub, auth_time, idp, amr.

In V2 we only get sid, sub and idp. What happened?

Microsoft added a new concept to their OpenID Connect handler called ClaimActions. Claim actions allow modifying how claims from an external provider are mapped (or not) to a claim in your ClaimsPrincipal. Looking at the ctor of the OpenIdConnectOptions, you can see that the handler will now skip the following claims by default:


If you want to “un-skip” a claim, you need to delete a specific claim action when setting up the handler. The following is the very intuitive syntax to get the amr claim back:


If you want to see the raw claims from the token in the principal, you need to clear the whole claims action collection.

Requesting more claims from the OIDC provider
When you are requesting more scopes, e.g. profile or custom scopes that result in more claims, there is another confusing detail to be aware of.

Depending on the response_type in the OIDC protocol, some claims are transferred via the id_token and some via the userinfo endpoint. I wrote about the details here.

So first of all, you need to enable support for the userinfo endpoint in the handler:

options.GetClaimsFromUserInfoEndpoint = true;

If the claims are being returned by userinfo, ClaimsActions are used again to map the claims from the returned JSON document to the principal. The following default settings are used here:


IOW – if you are sending a claim to your client that is not part of the above list, it simply gets ignored, and you need to do an explicit mapping. Let’s say your client application receives the website claim via userinfo (one of the standard OIDC claims, but unfortunately not mapped by Microsoft) – you need to add the mapping yourself:


The same would apply for any other claims you return via userinfo.

I hope this helps. In short – you want to be explicit about your mappings, because I am sure that those default mappings will change at some point in the future which will lead to unexpected behavior in your client applications.

Posted in ASP.NET Core, IdentityServer, OpenID Connect, WebAPI | 6 Comments

End of IdentityServer3 Maintenance

Yesterday we made the decision to stop development and maintenance of IdentityServer3. This has a couple of reasons:

  • IdentityServer4 is the better OpenID Connect and OAuth 2 implementation in every aspect
  • ASP.NET Core 2 is now a mature platform
  • There is only that much time you can spend on OSS development and issue tracker support, so we decided to focus on current projects which are IdentityServer4, IdentityModel2 and oidc-client.js

This also applies to answering questions on the issue tracker – we recommend you either use StackOverflow for free support, or use our commercial support options.

Security vulnerabilities will be fixed ASAP of course. Please disclose them responsibly.

PS. If you are a customer or have an existing support contract, we will of course continue supporting you. If you want to start a new support contract for your IdentityServer3 deployment, please let us know.

Posted in IdentityServer, Uncategorized | 12 Comments