New in IdentityServer4: Resource Owner Password Validation

Not completely new, but re-designed.

In IdentityServer3, we used the user service for both interactive as well as non-interactive authentication. In IdentityServer4, the interactive authentication is done by the UI.

OAuth 2 resource owner password validation is disabled by default – but you can add support for it by implementing and registering the IResourceOwnerPasswordValidator interface.

This gives you more flexibility as in IdentityServer3 since you get access to the raw request and you have more control over the token response via the new GrantValidationResult.

Posted in ASP.NET, IdentityServer, OAuth, WebAPI | Leave a comment

New in IdentityServer4: Support for Extension Grants

Well – this is not completely new, but we redesigned it a bit.

Extension grants are used to add support for non-standard token issuance scenarios to the token endpoint, e.g. translating between token types, delegation, federation, custom input or output parameters.

One of the common questions we got was how to implement identity delegation – instead of repeating myself here – I wrote proper documentation on the topic, and how to use IdentityServer4 to implement it.

Get the details here.

Posted in ASP.NET, IdentityServer, OAuth, WebAPI | Leave a comment

New in IdentityServer4: Default Scopes

Another small thing people have been asking for.

The scope parameter is optional in OAuth 2 – but we made the decision that clients always have to explicitly ask for the scopes they want to access.

We relaxed this requirement a bit in IdentityServer4. At the token endpoint, scope is now optional (IOW for client credentials, resource owner and extension grants requests). If no scope is specified – the client will automatically get a token that contains all explicitly allowed scopes (that’s a per client setting).

This makes it easier, especially for server to server type communication to provision new APIs without having to change the token requests in the clients.

Endpoint documentation here – Client settings here.


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

Identity & Access Control for ASP.NET Core Deep Dive

Once a year Brock and I do our three day version of the Identity & Access Control workshop in London.

This year it will be all about .NET Core and ASP.NET Core – and a full day on the new IdentityModel2 & IdentityServer4.

You can find the details and sign-up here – and there is an early bird ’til the 23rd September.

Really looking forward to this, since the extra day gives us so much more time for labs and going even deeper on the mechanics are architecture of modern identity and applications.

See you there!

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

New in IdentityServer4: Clients without Secrets

Over the next weeks I will do short blog posts about new features in IdentityServer4. The primary intention is to highlight a new feature and then defer to our docs for the details (which will also force me to write some proper docs).

Clients without secrets
Many people asked for this. The OAuth 2 token endpoint does not require authentication for so called “public clients”. We always ignored that and always mandated some sort of secret (and not treating it as really secret for public clients).

In IdentityServer4 there is a new RequireClientSecret flag on the Client class where you can enable/disable the client secret requirement.

You can read about client settings here, and about secrets in general here.

Posted in IdentityServer, OAuth, OpenID Connect, WebAPI | 1 Comment

IdentityServer4 RC1

Wow – we’re done! Brock and I spent the last two weeks 14h/day refactoring, polishing, testing and refining IdentityServer for ASP.NET Core…and I must say it’s the best STS we’ve written so far…

We kept the same approach as before, that IdentityServer takes care of all the hard things like protocol handling, validation, token generation, data management and security – while you only need to model your application architecture via scopes, clients and users. But at the same time we give you much more flexibility for handling custom scenarios, workflows and user interactions. We also made it easier to get started.

There are too many new features to talk about all of them in this post – but to give you an overview:

  • integration in ASP.NET Core’s pipeline, DI system, configuration, logging and authentication handling
  • complete separation of protocol handling and UI thus allowing you to easily modify the UI in any way you want
  • simplified persistence layer
  • improved key material handling enabling automatic key rotation and remote signing scenarios
  • allowing multiple grant types per client
  • revamped support for extension grants and custom protocol responses
  • seamless integration into ASP.NET Core Identity (while retaining the ability to use arbitrary other data sources for your user management)
  • support for public clients (clients that don’t need a client secret to use the token endpoint)
  • support for default scopes when requesting tokens
  • support for ASP.NET Core authentication middleware for external authentication
  • improved session management and authentication cookie handling
  • revamped and improved support for CORS
  • re-worked middleware for JWT and reference token validation
  • tons of internal cleanup

We will have separate posts detailing those changes in the coming weeks.

Where to start?
Our new website will bring you to all the relevant sites: documentation, github repo and our new website for commercial support options.

Add the IdentityServer package to you project.json:

“IdentityServer4”: “1.0.0-rc1”

and start coding ;)

We also added a number of quickstart tutorials that walk you through common scenarios:

Everything is still work in progress, but we have the feeling we are really close to how we want the final code to look and feel.

Give it a try – and give us feedback on the issue tracker. Release notes can be found here.

Have fun!

Posted in .NET Security, ASP.NET, IdentityServer, OAuth, OpenID Connect, WebAPI | 19 Comments

Why does my Authorize Attribute not work?

Sad title, isn’t it? The alternative would have been “The complicated relationship between claim types, ClaimsPrincipal, the JWT security token handler and the Authorize attribute role checks” – but that wasn’t very catchy.

But the reality is, that many people are struggling with getting role-based authorization (e.g. [Authorize(Roles = “foo”)]) to work – especially with external authentication like IdentityServer or other identity providers.

To fully understand the internals I have to start at the beginning…

When .NET 1.0 shipped, it had a very rudimentary authorization API based on roles. Microsoft created the IPrincipal interface which specified a bool IsInRole(string roleName). They also created a couple of implementations for doing role-based checks against Windows groups (WindowsPrincipal) and custom data stores (GenericPrincipal).

The idea behind putting that authorization primitive into a formal interface was to create higher level functionality for doing role-based authorization. Examples of that are the PrincipalPermissionAttribute, the good old web.config Authorization section…and the [Authorize] attribute.

Moving to Claims
In .NET 4.5 the .NET team did a radical change and injected a new base class into all existing principal implementations – ClaimsPrincipal. While claims were much more powerful than just roles, they needed to maintain backwards compatibility. In other words, what was supposed to happen if someone moved a pre-4.5 application to 4.5 and called IsInRole? Which claim will represent roles?

To make the behaviour configurable they introduced the RoleClaimType (and also NameClaimType) property on ClaimsIdentity. So practically speaking, when you call IsInRole, ClaimsPrincipal check its identities if a claim of whatever type you set on RoleClaimType with the given value is present. As a default value they decided on re-using a WS*/SOAP -era proprietary type they introduced with WIF (as part of the ClaimTypes class):

So to summarize, if you call IsInRole, by default the assumption is that your claims representing roles have the type mentioned above – otherwise the role check will not succeed.

When you are staying within the Microsoft world and their guidance, you will probably always use the ClaimTypes class which has a Role member that maps to the above claim type. This will make role checks automagically work.

Fast forward to modern Applications and OpenID Connect
When you are working with external identity providers, the chance is quite low that they will use the Microsoft legacy claim types. They will rather use the more modern standard OpenID Connect claim types.

In that case you need to be aware of the default behaviour of ClaimsPrincipal – and either set the NameClaimType and RoleClaimType to the right values manually – or transform the external claims types to Microsoft’s claim types.

The latter approach is what Microsoft implemented (of course) in their JWT validation library. The JWT handler tries to map all kinds of external claim types to the corresponding values on the ClaimTypes class – e.g. role to

I personally don’t like that, because I think that claim types are an explicit contract in your application, and changing them should be part of application logic and claims transformation – and not a “smart” feature of token validation. That’s why you will always see the following line in my code:


..which turns the mapping off. Newer versions of the handler call it DefaultInboundClaimTypeMap.

Setting the claim types manually
The constructor of ClaimsIdentity allows setting the claim types explicitly:

var id = new ClaimsIdentity(claims, “authenticationType”, “name”, “role”);
var p = new ClaimsPrincipal(id);

Also the token validation parameters object used by the JWT library has that feature. It bubbles up to e.g. the OpenID Connect authentication middleware like this:

var oidcOptions = new OpenIdConnectOptions
    AuthenticationScheme = "oidc",
    SignInScheme = "cookies",
    Authority = Clients.Constants.BaseAddress,
    ClientId = "mvc.implicit",
    ResponseType = "id_token",
    SaveTokens = true,
    TokenValidationParameters = new TokenValidationParameters
        NameClaimType = "name",
        RoleClaimType = "role",

Other JWT related libraries have the same capabilities – just have a look around.

Role checks are legacy – they only exist in the (Microsoft) claims world because of backwards compatibility with IPrincipal. There’s no need for them anymore – and you shouldn’t do role checks. If you want to check for the existence of specific claims – simply query the claims collection for what you are looking for.

If you need to bring old code that uses role checks forward, either let the JWT handler do some magic for you, or take control over the claim types yourself. You probably know by now what I would do ;)


…oh – and just in case you were looking for some practical advice here. The next time your [Authorize] attribute does not behave as expected – bring up the debugger, inspect your ClaimsPrincipal (e.g. Controller.User) and compare the RoleClaimType property with the claim type that holds your roles. If they are different – there’s your answer.

Screenshot 2016-08-21 14.20.28



Posted in .NET Security, OAuth, OpenID Connect, WebAPI | 4 Comments