A while ago I wrote a controversial article about the problems that can arise when mixing authentication and authorization systems – especially when using identity/access tokens to transmit authorization data – you can read it here.
In the meanwhile Brock and I sat down to prototype a possible solution (or at least an improvement) to the problem and presented it to various customers and at conferences.
Also many people asked me for a more detailed version of my blog post – and finally there is now a recording of our talk from NDC – video here – and slides here. HTH!
Again Techorama was an awesome conference – kudos to the organizers!
Seth and Channel9 recorded my talk and also did an interview – so if you couldn’t be there in person, there are some updates about IdentityServer4 and identity in general.
Right now there is quite some movement in the financial sector towards APIs and “collaboration” scenarios. The OpenID Foundation started a dedicated working group on securing Financial APIs (FAPIs) and the upcoming Revised Payment Service EU Directive (PSD2 – official document, vendor-based article) will bring quite some change to how technology is used at banks as well as to banking itself.
Googling for PSD2 shows quite a lot of ads and sponsored search results, which tells me that there is money to be made (pun intended).
We have a couple of customers that asked me about FAPIs and how IdentityServer can help them in this new world. In short, the answer is that both FAPIs in the OIDF sense and PSD2 are based on tokens and are either inspired by OpenID Connect/OAuth 2 or even tightly coupled with them. So moving to these technologies is definitely the first step.
The purpose of the OIDF “Financial API Part 1: Read-only API security profile” is to select a subset of the possible OpenID Connect options for clients and providers that have suitable security for the financial sector. Let’s have a look at some of those for OIDC providers (edited):
- shall support both public and confidential clients;
- shall authenticate the confidential client at the Token Endpoint using one of the following methods:
- TLS mutual authentication [TLSM];
- JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC];
- shall require a key of size 2048 bits or larger if RSA algorithms are used for the client authentication;
- shall require a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication;
- shall support PKCE [RFC7636]
- shall require Redirect URIs to be pre-registered;
- shall require the redirect_uri parameter in the authorization request;
- shall require the value of redirect_uri to exactly match one of the pre-registered redirect URIs;
- shall require user authentication at LoA 2 as defined in [X.1254] or more;
- shall require explicit consent by the user to authorize the requested scope if it has not been previously authorized;
- shall return the token response as defined in 4.1.4 of [RFC6749];
- shall return the list of allowed scopes with the issued access token;
- shall provide opaque non-guessable access tokens with a minimum of 128 bits as defined in section 22.214.171.124.2 of [RFC6819].
- should provide a mechanism for the end-user to revoke access tokens and refresh tokens granted to a Client as in 16.18 of [OIDC].
- shall support the authentication request as in Section 126.96.36.199 of [OIDC];
- shall issue an ID Token in the token response when openid was included in the requested scope as in Section 188.8.131.52 of [OIDC] with its sub value corresponding to the authenticated user and optional acr value in ID Token.
So to summarize, these are mostly best practices for implementing OIDC and OAuth 2 – just formalized. I am sure there will be also a certification process around that at some point.
Interesting to note is the requirement for PKCE and the removal of plain client secrets in favour of mutual TLS and client JWT assertions. IdentityServer supports all of the above requirements.
In contrast, the “Read and Write Profile” (currently a working draft) steps up security significantly by demanding proof of possession tokens via token binding, requiring signed authentication requests and encrypted identity tokens, and limiting the authentication flow to hybrid only. The current list from the draft:
- shall require the request or request_uri parameter to be passed as a JWS signed JWT as in clause 6 of OIDC;
- shall require the response_type values code id_token or code id_token token;
- shall return ID Token as a detached signature to the authorization response;
- shall include state hash, s_hash, in the ID Token to protect the state value;
- shall only issue holder of key authorization code, access token, and refresh token for write operations;
- shall support OAUTB or MTLS as a holder of key mechanism;
- shall support user authentication at LoA 3 or greater as defined in X.1254;
- shall support signed and encrypted ID Tokens
Both profiles also have increased security requirements for clients – which is subject of a future post.
In short – exciting times ahead and we are constantly improving IdentityServer to make it ready for these new scenarios. Feel free to get in touch if you are interested.
Seth and the Channel9 crew visited me in my office in Heidelberg to learn about IdentityServer and German culture.
We had a nice day in Heidelberg involving identity, a whiteboard, code, beers & bratwurst ;) enjoy.
- Part 1 (interview and Heidelberg)
- Part 2 (modern authentication architecture whiteboard session)
- Part 3 (identityserver4 in action)
The dotnet CLI includes a templating engine that makes it pretty straightforward to create your own project templates (see this blog post for a good intro).
This new repo is the home for all IdentityServer4 templates to come – right now they are pretty basic, but good enough to get you started.
The repo includes three templates right now:
dotnet new is4
Creates a minimal IdentityServer4 project without a UI and just one API and one client.
dotnet new is4ui
Adds the quickstart UI to the current project (can be combined with is4)
dotnet new is4inmem
Adds a boilerplate IdentityServer with UI, test users and sample clients and resources
See the readme for installation instructions.
Well – not really new – but redesigned.
IdentityServer4 has two diagnostics facilities – logging and events. While logging is more like low level “printf” style – events represent higher level information about certain logical operations in IdentityServer (think Windows security event log).
Events are structured data and include event IDs, success/failure information activity IDs, IP addresses, categories and event specific details. This makes it easy to query and analyze them and extract useful information that can be used for further processing.
Events work great with event stores like ELK, Seq or Splunk.
Find more details in our docs.
When we designed IdentityServer4, we wanted to make it easier to extend the core token service with custom protocol endpoints.
So one thing that comes up every now and then is using IdentityServer4 as an identity provider for SharePoint and also older ASP.NET applications using System.IdentityModel (or even WIF) and Katana.
This requires support for WS-Federation – and this is perfectly possible – and actually even easier than it used to be in IdentityServer3. I made the code for it available on github and wrote a little walkthrough of how it works here.
Our documentation now also has a brief description of the underlying mechanism and useful tips for implementing other (custom) protocols. SAML2p anyone???
And last but not least, our friend Scott Brady wrote a detailed walkthrough on using the WS-Federation endpoint with SharePoint. Enjoy!