New in IdentityServer4 v4: Multiple signing Keys

So far IdentityServer4 only supported a single signing key at a time. There are historic reasons for that.

When we started with .NET Core, the only x-plat algorithm that really worked (without #ifdef hell) was RSA with SHA-256 (RS256) so we went with that. In the light of newer security requirements (e.g. FAPI), RS256 became discouraged, and newer algorithms like PSS or ES will take its place sooner or later.

A quick fix (one we could do without breaking changes) was to allow using a different signing algorithm than RS256. We added that in IdentityServer4 v3. But still we only allowed a single algorithm only, which makes migration from RS to something else, not really feasible.

Starting with v4, you can register multiple signing keys – or to be more precise, one for each algorithm you want to support, and clients and resources can express their preference if they want to. It’s a pure opt-in behaviour.

This way you can smoothly phase-out RS256 in favour of something else by switching your clients and APIs one by one when they are ready.

Check the updated docs – it’s really a small change, but pretty important going forward.

Posted in IdentityServer, Uncategorized | Leave a comment

OAuth 2.0: The long Road to Proof-of-Possession Access Tokens

I did a lot of WS-Security in my (distant) past – and whenever we started looking into migrating to OAuth 2.0, there was this one thing on the security check-list that was missing in the OAuth world: proof of possession tokens (short PoP).

Now might be finally the time where they become real. But some history first.

OAuth 1.x had PoP tokens, but they were complicated to use and involved some non-trivial crypto. As part of the OAuth 2.0 “simplification”, proof-of-possession became optional and bearer tokens became the standard choice. This was actually one of the reasons why the main OAuth spec author left just a couple of months before the document was actually finished. See this video for background/entertainment.

One of his legacies though was that the OAuth 2.0 spec got split in two specs – OAuth 2.0 itself (RFC 6749) – and token usage (RFC 6750). The only token usage spec that was written by that time, was the “bearer token usage” with “proof-of-possession” to follow at some point. This never happened.

PoP tokens have some nice additional security properties, because they are bound to the client that requested the token in the first place. This means that a leaked/stolen token cannot be used by an attacker without knowing the additional key material that defines that binding. This key material was typically never sent over the wire, which makes network-based attacks much harder. This is especially nice for mobile applications, where the client frequently connects to untrusted networks or for non-repudiation.

In WS-Security, the token binding was done purely at the application level (or message level as they called it). A couple of attempts have been made to replicate that idea in OAuth as well (see here, here and here).

All of these approaches were doable (though not straightforward) but suffered from problems like e.g. not being able to deal with streamed data (btw – WS-Security had the exact same problem). In the end, the extra complexity was questionable and all that was left from that effort, was the standardization of a claim to express the binding. It’s called cnf – or confirmation. But nothing beyond that.

Having a PoP mechanism at the transport layer seemed to be the better alternative as it was content agnostic and required less code to be written at the application level. Enter token binding – well don’t, it’s a waste of time. This looked promising, but Google backed out at some point, which made this not feasible as a standard at the internet level.

Mutual TLS
As kind of a “last resort”, there has been the OAuth MTLS spec cooking for a while. It describes both using X.509 client certificates for OAuth 2 client authentication, and using the certificate for PoP (or sender-constraining as they call it). Both parts can be used independently, as we’ll see later.

When most people hear X.509, CAs and “Mutual TLS”, they shy away because this is very complicated technology and – yes – this is true. But on the other hand, MTLS has kind of a renaissance and is very often used these days in “microservice” scenarios where it’s less about the PKI aspect than providing key material.

The Mutual TLS spec describes two authentication modes for clients – one is a full blown CA/PKI style where you authenticate based on a trust root and distinguished names, the other one though is for self-signed certificates, where you get the similar benefits without running a complicated CA infrastructure.

In both cases, the client certificate can be used to bind the issued token to the client using the cnf claim.

Another interesting idea is using “ephemeral client certificates” – this means the client must not necessarily use the client certificate for authentication – this can be done in any way you like, e.g. private key JWTs or  even shared secrets (though not recommended). The client cert’s only purpose is to provide some key material to the STS to do the token binding. This might be a gentle way to introduce PoP in your architecture.

To summarize: deploying client certificates is not necessarily as hard anymore as the last time you had a look it, and may be worth re-visiting.

What about SPAs?
Well – nothing really. MTLS is not really applicable, token binding is not happening. Other approaches have been tested, and while they work on a crypto level, they still can’t protected against the main attack vector in browsers, namely content injection attacks (aka XSS). So again – the extra effort is questionable.

In the SPA world, still the most secure option is to not store any tokens at all in the browser and only use them server-side. Feel free to layer PoP on top of that using the above technique.

What does this mean for .NET and IdentityServer Users?
IdentityServer4 had support for the MTLS spec since March 2019. We just recently extended that support for the upcoming version 4 for allowing more flexible hosting of the MTLS endpoints, e.g. on a sub-path, on sub-domains or on completely different domains. We also added support for adding the cnf claim also for ephemeral client certificates (.NET Core has an API to create X.509 certs on the fly which works really nice with that approach).

See here how to get the IdentityServer4 v4 pre-view build – and this is the updated documentation.

Posted in IdentityServer, OAuth | 1 Comment

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