Updates on our Workshops

I am pleased to announce that we are now offering two workshops. I was mentioning that on Twitter already, and got a lot of questions. So I thought it would make sense to summarise them all in one place.

You can find descriptions for both workshops on our training page: https://identityserver.io/training/

Identity & Access Control for modern Applications using ASP.NET Core
This is our flagship training that we are running now for many years.

This workshop is an introduction to modern security architecture, OpenID Connect and OAuth 2.0 from the perspective of an ASP.NET Core developer or architect.

When you start building applications using token-based security, there are a lot of moving parts around the protocols and the concrete APIs of your application framework – and you also have to put these blocks together to create meaningful architectures. That’s what this workshop is all about.

The workshop is always very well attended and very often the biggest workshop when run at conferences. This tells us that there is definitely a need for this type of content. We keep evolving it constantly to keep up with ASP.NET Core changes and the industry best practices.

See here for a detailed agenda and watch this video for a sneak peak into some of the topics we cover in this two or three day workshop.

We run this workshop either as in-house versions or open enrolments. Either contact us to discuss an in-house version, or check our page for upcoming open enrolments.

Advanced OAuth
This is our new 1-day course covering all the new specs and everything you need to know to create high security OAuth architectures.

We’ve been involved for the last couple of years implementing OpenID Connect and OAuth in the health sector in Norway. As you can imagine this is subject to many strict laws and regulations. Other highly regulated industries like finance and e-gov had similar pushes, and this resulted in various “higher security” profiles for OAuth and OpenID Connect.

Though pioneered in these high security environments, the specs and guidance is now being consolidated and make their way into “normal” applications that need more security than plain RFC 6749 has to offer.

This workshop starts, where our introduction workshop ends and talks about the latest specs and best practices for securing OAuth and adding additional features like stronger authentication of front- and back-channels, proof-of-possession, sender and audience constraints and much more.

This course is currently only offered for in-house/remote deliveries. If you are a company and are interested in this contact, please contact us. We are thinking about running open-enrolments later this year – so if you are an individual, please also contact us, so we can get a better feeling for the demand.

Here’s the overview page for this training, and here you can find a recent recording covering an excerpt of the security best practices content.

Hopefully see you soon in some training room around the world – virtual or in-person!

Posted in OAuth, OpenID Connect | Leave a comment

Automatic Token Management for ASP.NET Core and Worker Services 1.0

After a pretty long preview period, I am happy to announce that IdentityModel.AspNetCore 1.0 is now on Nuget.

This library solves a problem that we have with every single OIDC/OAuth client we are creating: token management.

Requesting and using a token is the easy part – managing the token and its lifetime is the hard part. But also boilerplate.

The library helps with access token lifetime management for pure machine to machine communication and user-centric applications with refresh tokens.
For user-centric it provides:
  • storage abstraction for access and refresh tokens (default implementation using the ASP.NET Core authentication session)
  • automatic refresh of expired access tokens
  • refresh token revocation
  • token lifetime automation for HttpClient
For worker services it provides:
  • caching abstraction for access tokens (default implementation using IDistributedCache)
  • automatic renewal of expired access tokens
  • token lifetime automation for HttpClient
I’ve been holding back with releasing, because I wanted to get some feedback from more people and customers, and I also wanted to make sure it is ready for all of the advanced scenarios I am using for our new Advanced OAuth workshop.

 

Best part – it also has docs. See here for workers, see here for web applications – and here for some more info on plugging in your own configuration and storage abstractions.
HTH
Posted in .NET Security, ASP.NET Core, IdentityServer, OAuth, OpenID Connect | 1 Comment

Major Update to IdentityModel.OidcClient

I just pushed Preview 3 of the 4.0 version of IdentityModel.OidcClient – this includes some major updates (that you might or might not have asked for):

  • Removal of OpenID Connect Hybrid Flow.
    The codebase does Authorization Code Flow + PKCE only now. This is inline with RFC8525 and the AppAuth reference implementations. Also – this reduced the complexity of the codebase dramatically
  • Support for pure OAuth-based request.
    Before this change, the openid scope was mandatory, which always meant OpenID Connect compliance on the server. You can now omit openid and do pure OAuth 2.0 as well.
  • Removing JWT signature validation from the core codebase.
    The signature validation is now a pluggable component. I provide a default implementation using Microsoft’s JWT handler in a separate Nuget package. This allowed to remove that dependency from OidcClient.
  • Removed dependency on NewtonSoft.Json
    Still IdentityModel uses it, this will change as well at some point.

All in all, this make OidcClient slimmer and thus hopefully easier to integrate into existing applications.

Please give it a try.

Posted in IdentityModel, OAuth, OpenID Connect | Leave a comment

SPAs are dead!?

clickbait isn’t it? But this was Brock’s immediate reaction when we saw (and I recommend you read this first):

Full Third-Party Cookie Blocking and More

What this basically means is, that browser are getting more and more strict with how they handle their cookies. The reasons are security (see the recent SameSite changes) and in this case – privacy. Cookies have been exploited for a long time one way or the other – and this is now the reaction of browser vendors.

What does that mean to application architectures? Well – first of all – all these changes only affect cross-site scenarios. But if you are in that situation the immediate consequences will be:

  • front-channel logout notifications do not work anymore (used in pretty much every authentication protocol – like SAML, WS-Fed and OpenID Connect)
  • the OpenID Connect JavaScript session notifications don’t working anymore
  • the “silent renew” technique that was recommended so far to give your application session bound token refreshing don’t work anymore

Safari and Brave are the first browser implementing those changes. Chrome will follow in 2022 (hopefully sooner) etc…

Some things can be fixed, e.g. you can replace front-channel notifications with back-channel ones. Some people recommend replacing silent renew with refresh tokens. This is dangerous advice – even if your token service has implemented countermeasures.

If all the security concerns around storing tokens in browsers did not worry you so far, maybe this is a good reason to consider the BFF architecture for your SPAs (if you are looking for less fancy name – it’s what the BCP calls “JavaScript Applications with a back-end“).

So are SPAs dead? Well – SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.

(and they should be unless we fix some fundamental problems)

my 2c.

Posted in OAuth, OpenID Connect | 15 Comments

Online Workshops in 2020

For obvious reasons, all in-person workshops have been cancelled for the time being.

This is frustrating on one hand, but converting them to an online format, will allow people to attend who otherwise wouldn’t make it. The other upside is, that the prices are lower, and you don’t need to spend money on travel.

Our main training partner, NDC Conferences, has converted their three main events in Europe to online formats, which means I will run our very popular Identity & Access Control for modern Applications using ASP.NET Core 3 workshop as online training on these dates:

  • April 1st/2nd (sign-up here)
  • April 21st/22nd (sign-up here)
  • June 8th/9th (sign-up here)

See here for the complete agenda and hands-on labs as well as any updates to our schedule.

Hopefully we can make this work for everyone! cu there! Keep well!

Posted in Uncategorized | Leave a comment

Mutual TLS and Proof-of-Possession Tokens: Summary

This is the last part of my PoP and Mutual TLS post series.

Part 1 covered some history and motivation, and part 2 looked at various server setups.

Part 3 was supposed to be a walk-through guide on how to set-up ASP.NET Core and IdentityServer, as well as a client and an API.

While writing this up, I realized that this should be really in our documentation rather than on my private blog.

But to summarize those steps, you need to:

  • set-up MTLS at the hosting layer (e.g. IIS, Nginx, Apache etc..)
  • set-up ASP.NET Core to receive the client certificate from the hosting layer if present
  • enable MTLS in IdentityServer
  • associate IdentityServer clients with client certificates

Now the client can start sending the client certificate while requesting tokens and calling APIs. IdentityServer will embed the thumbprint of the client certificate in the access token, and the API will compare that value with the actual client certificate of the TLS layer.

If they match, voila! The client has successfully proven that it is really the owner of the access token – aka Proof-of-Possession.

The full walkthrough including samples etc. can be found here.

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

Mutual TLS and Proof-of-Possession Access Tokens – Part 1: Setup

2020 is the year where I want proof-of-possession tokens to become reality. Mutual TLS seems to be the only feasible way to do that today. So here’s another post about it….

This is a two-part post. In this post we will have a look at server-setup to support MTLS, and in the next part we will have a look at ASP.NET and IdentityServer configuration to add support for proof-of-possession access tokens.

The MTLS spec defines two big features:

  • Strong client authentication using a TLS X.509 client certificate
  • Binding access tokens to a TLS X.509 client certificate

Both features can be used either together – or individually.

The spec also allows for two types of client certificates:

  • PKI Mutual-TLS Method: This method assumes an a-priori established trust root and chain-trust certificate validation
  • Self-Signed Certificate Mutual-TLS Method: This method allows establishing trust with a specific certificate, e.g. via the thumbprint

Another technicality is how you are planning to host your MTLS endpoints. Since client certificates get negotiated at connection time, you cannot simply “MTLS enable” your complete web application, since this will have side-effects on other endpoints (e.g. your UI) that don’t need client certificates. This might result in the browser showing “certificate picker” dialogs, which is not desirable.

IIS, e.g. allows to configure the MTLS requirement on a path basis, e.g. /connect/mtls/*. This causes a re-negotiation of the connection, which (I was told) is not optimal, and also not a thing anymore in HTTP/2 going forward. Other servers like Nginx encourage hosting the MTLS endpoints on a different (sub) domain, which seems cleaner to me.

After a long discussion on the OAuth mailing list, the spec added an additional metadata entry called mtls_endpoint_aliases, which allows to point to arbitrary addresses to accommodate different hosting styles.

Over Christmas holidays I was working on the MTLS updates for IdentityServer and tried to setup a test system. This was a more complicated than I thought, so I had to do some additional research which infrastructure has the best support. Here are my results.

Azure App Service

I only had a quick look, but from that, my conclusion was that this only allows to configure MTLS application-wide, and also only supports the PKI MTLS method. This is a show stopper unfortunately.

Update: I got some feedback that this is a bit more flexible than I thought – but not much. Apparently Azure allows to configure exclusion paths for the MTLS config – this sounds like a configuration nightmare to be honest – but is doable I guess. This seems to be the only docs though…

Pure Kestrel

Kestrel allows for both the PKI and self-signed methods – that’s good. But again, only app-wide MTLS settings are supported.

IIS

IIS does support scoping the MTLS endpoints to certain paths – but as mentioned above, this does not seem to be favoured approach anymore. The other problem is, that it seems that IIS only supports the PKI MTLS method, or IOW you always need to establish trust to a CA upfront at the OS level – that’s not what I wanted. I had several conversations with Microsoft people about that, and no-one had a solution to that problem. If you know how that would work, I am interested in updating this document.

Nginx

I never worked with Nginx before, so this was kind of my last resort option. But man, I was shocked how easy it was to get started – and lo and behold, Nginx ticked all the boxes!

With Nginx you would typically setup two sites (or servers in Nginx speak) pointing to the same ASP.NET Core host, e.g. https://identityserver.io as the main site, and https://mtls.identityserver.io to isolate your MTLS endpoints.

For the general ASP.NET Core setup for Nginx see here.

For the MTLS endpoints, you set-up an additional server that has the following config entries:

server_name  mtls.identityserver.io;
ssl_verify_client optional_no_ca;

In this particular case, I accept all MTLS certificates (that’s the no_ca option). You can also configure trusted CAs at the Nginx level.

You then need to configure Nginx to pass the client certificate to your ASP.NET Core application via a header:

proxy_set_header   X-SSL-CERT $ssl_client_escaped_cert;

This will send the certificate as a URL-encoded string on the X-SSL-CERT header, which you then pickup in ASP.NET Core using the certificate forwarding middleware.

I am NOT an Nginx expert – if anyone has some comments on this setup, please let me know!

Hope this helps – in the next post I will have a closer look at the required ASP.NET Core and IdentityServer configuration.

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