IdentityServer3 and upcoming SameSite Cookie changes in Browsers

You have probably heard that starting with Chrome 80 in February, the behavior of cookies will change. This is a breaking change and effects every single web application on the internet.

Microsoft has patched their supported platforms (ASP.NET, Katana 4 and ASP.NET Core) and provides instructions how to deal with the changes until the web has stabilized again.

IdentityServer3 runs on Katana 3, which is not supported by Microsoft anymore. We announced the end of free maintenance for IdentityServer3 already end of 2017 and started offering a security maintenance program mid 2019.

We are aware that still many companies out there use IdentityServer3 – which means their applications will break in the next months because of the changes mentioned above.

There is no easy fix for this, since the underlying platform itself does not support the new cookie semantics. We took some engineering effort to update the old IdentityServer3 code-base to support the 2020 SameSite behavior, and make this available to our IdentityServer3 security maintenance customers. If you are not already in that program, please contact us immediately.

Posted in IdentityServer, Uncategorized | 9 Comments

Use explicit typing for your JWTs

JWTs are being used in many places these days – identity tokens, access tokens, security events, logout tokens…

You actually have to be careful when validating a JWT that you don’t mistakenly confuse it with a JWT that was issued for a different purpose, but “looks” very similar to what you expect.

One example is from the OpenID Connect back-channel logout spec. Besides the “normal” validation steps like signature, issuer, audience and expiration – in addition you need to check for the existence of a specific claim – and it MUST NOT contain a nonce claim. Why? – well because otherwise you might confuse it with an identity token.

Explicit typing
The new JWT BCP document recommends introducing explicit types for JWTs.

Confusion of one kind of JWT for another can be prevented by having
   all the kinds of JWTs that could otherwise potentially be confused
   include an explicit JWT type value and include checking the type
   value in their validation rules.  Explicit JWT typing is accomplished
   by using the "typ" header parameter.

And the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens draft proposes using at+jwt for the value of the typ header in OAuth 2.0 access tokens.

We agree that this is an issue and added the typed typ header in the new IdentityServer4 v3 – here’s an example access token:

Screenshot 2019-09-13 14.37.26

The value is configurable via our options – and if you don’t like it, you can go back to the standard value as well.


Posted in IdentityServer, OAuth | 2 Comments

Two is the magic Number

..and not 3.

To build authentication systems for modern applications, all you need to understand are two OpenID Connect / OAuth 2.0 flow. That’s it.

Client Credentials Flow
This is probably the simplest flow and it is designed for server to server communication. It’s a simple HTTP request/response flow: client ID + secret in, token out. Done. (spec, C# code sample)

Code Flow + PKCE
For all other application types (server-side web app, SPA, native app) you use an authorization code-based flow. The classic OAuth 2.0 code flow has the code substitution attack problem – but this has been mitigated by e.g. OpenID Connect Hybrid Flow or PKCE. Since PKCE is considerably easier to implement from a client point of view, just go with that. It is the official recommendation for native and web apps anyways, and since ASP.NET Core 3 is supporting it out of the box now as well (in fact it is turned on by default), that’s really all you need.

This makes for a really clean authentication/token story. Now make sure your token service support those flows (e.g. IdentityServer) and set PKCE to be required for all interactive clients.

The other flow you might care about is for devices (without browsers or keyboards) – but this is not very commonly used. Oh well – maybe it is 3. Anyways, it gets easier.

Posted in ASP.NET Core, IdentityServer, OAuth, OpenID Connect | Leave a comment

IdentityServer for ASP.NET Core 3

In short: is released (along with the introspection and access control validation handler).

As part of the longer version, you might ask yourself how we can do that before ASP.NET Core 3 itself is released. Well – it’s a slightly complicated story.

Since the IdentityServer Nuget packages are referenced in some of the ASP.NET Core 3 templates, we had a bit of a chicken/egg situation, and we worked closely with the ASP.NET Team (thanks Javier!) to make sure we are doing this right.

Our 3.0 version is referencing ASP.NET Core 3 Preview9 which is fully supported for production and we were promised that there won’t be any changes that affect us between now and their RTM. IOW – ASP.NET Core 3 will ship with a reference to our 3.0 – and on the 23rd September, we will release a 3.0.1 which then will in turn reference their 3.0…and hopefully all the stars align ;)

(For those who know – this concludes a long – and sometimes painful – journey, that started back in 2012)

Long story short – our version of IdentityServer4 targeting ASP.NET Core 3 is now on Nuget, and you can give it a try. Next step for us is updating all our docs, samples and workshop materials, which should be done by the 23rd September.

What’s new?
Well not a lot really. Our main focus was to ensure compatibility with ASP.NET Core 3, but since we had the opportunity to do a bit of a re-org, we added the last missing pieces that were required for our FAPI compliance. Namely support for the PS* family of signing algorithms (along with support for elliptic curves as well) and s_hash support. More details in upcoming blog posts.

As always – feedback is appreciated.

repo / commits / release notes

Posted in ASP.NET Core, IdentityServer, Uncategorized | 4 Comments

Releasing IdentityModel v4

IdentityModel has been growing organically over the last years, and we felt it is necessary to do some fundamental cleanup. At the same time it is used by a lot of people and companies (currently around 20 million downloads on nuget) – which is a bit scary when doing breaking changes.

But since we are at a point where a new .NET Core runtime is released, and thus many other libraries will release new major version, we thought that this might be a good opportunity to make the changes.

This version is a breaking release!!!

Stay on v3.x if you are using:

  • IdentityServer4 v2.x
  • IdentityServer4.AccessTokenValidation v2.x
  • IdentityModel.AspNetCore.OAuth2Introspection v3.x
  • IdentityModel.OidcClient v2.x fact, I am in the process of pushing updates to these packages that sets an upper bound for the IdentityModel dependency (aka ‘[3.10.10,4.0)‘).

All subsequent major versions of the above mentioned packages have switched to IdentityModel v4 and will be released along with IdentityServer4 v3 on the 23rd September.

In the coming days I will push IdentityModel v4 to nuget – here’s a high level list of the changes.

Target frameworks
I dropped the net452 target – v4 is targeting net461 and netstandard2.0 only.

Removed old *Client classes
I removed the protocol client classes like TokenClient in favour of the newer style extension methods for HttpMessageInvoker (the base class of HttpClient).
I added a new TokenClient and IntrospectionClient based on the new design which is now DI and HttpClientFactory friendly. I did that mainly because I needed them in some other project. Give them a try, and see if they work for you as well.

Removed access token related delegating handlers for HttpClient
I never was happy with their design, and they also did not work for some common scenarios. Part of the work has been moved to OidcClient (for native apps) and part of it has been moved to the ASP.NET Core specific IdentityModel.

Updated extension methods
The protocol extensions methods have been re-written from the ground up. The public API surface stayed mostly the same, but certain classes have been renamed for clarity.
The request objects now derive from `HttpRequestMessage` which gives you more control over the HTTP details (e.g. headers).

Updated Epoch Extensions
Year 2038 is coming! All extensions have been updated to use long instead of int. Alternatively – .NET has built-in support now as well. So feel free to switch to that if you like.

I probably changed some parameter, classes and namespace names..

As I said, I will push v4 in the coming days. Now is your last chance to chime in if you feel something is wrong.

Posted in IdentityModel, Uncategorized | Leave a comment

Claims-based Identity & Access Control for .NET, ASP.NET and WCF 4.5 now retired on PluralSight

Time flies!

I just got notice from PluralSight that the above mentioned three courses are now retired and are not included in search results anymore. If you still care about this content – the direct links still work, and here they are:

Introduction to Claims-based Identity & Access Control

Claims-based Identity & Access Control in ASP.NET 4.5

Claims-based Identity & Access Control in WCF 4.5


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

End of IdentityServer3 free Support

Back in 2017 we announced the end of IdentityServer3 maintenance. This excluded security bug fixes.

As of the 1st of July 2019 Microsoft officially ended support for Katana 3. This means that the platform we originally built-against is now unsupported and we completely stop supporting IdentityServer3 (including security bugs) for free now as well.

If you are still running IdentityServer3, you can get commercial support from us to further receive security notifications and updates and support in general. Or we can help you upgrading to ASP.NET Core and IdentityServer4. Contact us.

Posted in IdentityServer, Katana, Uncategorized | 1 Comment

Another Take on Access Token Management in ASP.NET Core (…and announcing IdentityModel.AspNetCore)

I spent a lot of time on the client side recently – as part of our PolicyServer client libraries work, customer work, our updated guidance for our workshops as well as the various talks Brock and I gave on building clients for token-based systems (see here for a recording).

In particular for ASP.NET Core-based clients we’ve been going back and forth between various approaches, from completely manual to completely automated (see here) trying to find the best balance between control and convenience.

I think I’ve settled on an approach (at least for now) that integrates nicely with ASP.NET Core and gives you a couple of extensibility points to adjust to your environment (especially around token storage).

Which brings me to the 2nd part – now being sufficiently confident that this is the approach I want to (re-) use, how can I ship it as a library? IdentityModel deliberately has very few dependencies – so adding it there was not an option. Instead we decided to create a new project called IdentityModel.AspNetCore – and the idea is to extend IdentityModel for ASP.NET Core specific functionality and features. Feedback is as always very welcome.

OK – without further ado – how does the token management functionality work?

Basically all functionality is encapsulated in this line of code:

var token = await HttpContext.GetAccessTokenAsync();

This uses the same style as the built-in token storage APIs from Microsoft, but does a couple of things under the cover:

  • It uses an extensible storage mechanism to retrieve the current access and refresh token. The default implementation will load the tokens from the authentication session in ASP.NET Core
  • It will check the expiration of the access token, and if a configurable threshold is reached, refresh the access token (and also pass the refreshed tokens back to the storage abstraction)
  • Return the access token back to the caller

You can now call this API from wherever you see fit, e.g. directly from the code where you make the outbound HTTP calls, or preferred (by me), from within a delegating handler that gets injected in your HTTP client via the factory.

Remark: IdentityServer (and maybe other token services) has a feature to allow a refresh token to be used only once (the RefreshTokenUsage property on the Client). This feature is designed for public clients like native apps and not so much for confidential clients like ASP.NET Core web applications. It also gets in the way with token management like described above. If your token management code gets executed (almost) at the same time but e.g. on different nodes, some nodes will get an error during refresh because the refresh token has been used more than once. You should not use this option in this scenario.

Disclaimer: This is not a generic approach for refreshing tokens from arbitrary providers. The library makes the assumption that your primary OAuth 2 provider (the one that guards your APIs), is also OpenID Connect compliant (e.g. IdentityServer) and was used for authenticating the user. At least that’s how we built our applications – so it is bit opinionated.

The repo contains a sample that shows this approach. This is the very first version of this library – so please have a look and give me feedback if this would also work for you. Thanks!

Posted in ASP.NET Core, IdentityModel, OAuth, OpenID Connect, Uncategorized | Leave a comment

IdentityServer4 Roadmap

We didn’t have a lot of time recently to work on IdentityServer4 – and yes, I know there are a lot of open “backlog” issues right now. But fortunately everything is pretty stable and from the open issues, nothing seems to be really a show stopper. If we can’t get back quick enough, it’s mainly because we have to balance our time between OSS and paid work to make it work for everyone. If you think we are not getting back on an issue you opened, feel free to remind us.

Just a quick re-cap what happened recently.

2.3 – we added support for the “Device Authorization Grant” – this spec will go final soon!

2.4 – we added support the current draft of the “Mutual TLS” spec. This was sponsored work, and we are happy we finally have that feature built-in. Working on docs now.

2.5 – will be released fairly soon and will include another sponsored feature I wanted to have for a long time. More details soon.

After 2.5 we will finally get to the “small bugs” – so expect a 2.5.x pretty soon after that.

Then you might have heard that ASP.NET Core 3 Preview3 shipped with the long awaited templates including IdentityServer integration (docs here). This uncovered some problems going forward. Since the current IdentityServer is built against the 2.1 ASP.NET Core runtime, there will be incompatibilities with 3.0 (see e.g. here).

This means that we need to start now to also build against the new v3 bits and the first preview is already on nuget. This doesn’t make things easier…If you find any issues with our previews and ASP.NET Core 3, please let us know!

There will be a 3.0 of IdentityServer4 built against ASP.NET Core 3. This release will probably not have any major updates or new features, but tries to make sure we are not hit by any breaking changes in ASP.NET.

Since ASP.NET Core 3.0 will not be an LTS release, we will pretty soon after our 3.0 start working on a 4.0 targeting ASP.NET Core 3.1 which will be the new LTS. This version will have major feature updates. Confusing? Yes.

IOW – we will need to maintain three branches of IdentityServer soon: 2.x for ASP.NET Core 2.1, 3.x for ASP.NET Core 3.0 and 4.x for ASP.NET Core 3.1. Yay.

This also led to a major re-structuring of our repos. We merged the core IdentityServer repos into a mono repo, updated the build automation and moved to a simpler branching strategy.

Please keep that in mind if we don’t immediately respond to your questions ;)

Posted in IdentityServer, Uncategorized | Leave a comment

Try Device Flow with IdentityServer4

The biggest new feature in IdentityServer4 v2.3 is support for the beta Device Flow specification.

Device Flow is a flavour of OAuth 2.0 optimised for browserless and/or input-constrained devices. Things like TVs, gaming consoles, printers, cash registers, audio appliances etc. come to mind here.

The flow works like this:

  1. The client does a so called “device authorization request”. This returns both a device code and a user code.
  2. The client typically shows a URL to the user that includes the user code, e.g. The client might also show a QR code for that URL, to make that process even simpler.
  3. The user is now supposed to go to this URL on a separate device, e.g. a laptop computer or a phone/tablet. There the user will authenticate and consent. While this is happening, the client polls the token endpoint with the device code to find out when this part is done.
  4. Once the interactive part is done, the token endpoint will return the typical OAuth tokens like access and refresh token.
  5. Done

Or, if you think a picture says more than 1000 words – here’s the ASCII art from the RFC:

Screenshot 2019-02-08 13.03.06.png

You can try Device Flow with our demo instance of IdentityServer4 – and here is a fully functional client/api sample to go along with it.


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