How can we effectively share health information between different health personell in different organizations?

There are obviously several technical answers to this question. Some of the answers are seemingly both feasible, effective and a good idea - until the next big thing comes along. Perhaps some day we will save everything in an unstructured blob and have an AI sort things out. Can't wait for that one..

On the other hand, the underlying complexity of health information adds to the problem. Knowing which information is relevant to share at different times is not easy. Some types of health information are snapshots in time and totally irrelevant in three weeks, while other types of information are important pieces of the puzzle that is needed to give the patient the correct treatment.

The complexity of complex diseases

Statistics show that patients with comorbidity or multimorbidity accounts for a disproportionately large part of the total amount of care given by the health care system in Norway.

Some estimates show that roughly 80% of all the resources are spent on about 20% of the patients, who are typically co- or multimorbid.

These co- or mulitimorbid patients often use several health care providers. This greatly increases the need for enabling the sharing of health information. It also adds a load to the allready stated problem, because some of these patients have large amounts of data distributed across the different organizations. In some cases more than 30.000 documents. Searching and choosing the relevant pieces of information in those cases is tricky - at best.

My semi-humble opinion

The fundamental problem doesn't lie within the ones and zeros, nor the complexity of health information.

It lies in the murky world of trust : The governing laws and juridical system, the responsibilities, the agreements, the knowledge about how processes and routines are carried out in the organizations that communicate with each other. The security measures and mechanisms that are in play, and how securely the systems and interfaces are designed, built and deployed etc.

Without trust between the different actors we won't be able to share a single thing. Regardless of the technical solutions or our capability to acheive semantical interoperability.

In other words: the answer to the question is about as clear as mud. So for this blog post I'll explain how I perceive trust, and why I believe trust to be the most fundamental issue that needs to be solved before we are able to effectively share health information between different actors in Norway.

How trust can be modeled and built is material for a later post...

Trust you say?

What is trust anyway?

This is one of my favorite quotes - allegedly from E. Hemingway:

The best way to find out if you can trust somebody is to trust them

I interpret this quote to mean that trust is not a binary thing, it is a decision.

And where there is need for a decision, there is always underlying uncertainty .

Because, when there is no uncertainty you don't really need to make a decision. In other words: when all the facts are known, you don't need to decide anything. The decision is given.

The caveat is that you won't know wether the decision was good or bad until you gain some experience with the party you've decided to trust. It's possible that you'll make the wrong decision, but you won't know until you've tried.

So, to trust something or someone is a decision that is based on facts you have about the party you need to trust, in addition to previous experiences you or others have had dealing with the same party.

The health sector in Norway - a primer

Since the title of this blog post contains the words health information, I think it is time to give some context.

But first a true story from my life.

Shut up and give me the morphine!

I experienced how health care systems don't talk to each other when I suffered an acute and intense back-pain last year. A suprisingly effective lack of systems interoperability forced me to tell my story over and over again - which is rarely a good thing unless the story is really funny or interesting. In my case the story could be summed up in these three words: "give me morphine".

My close encounter

Here is a concise recount of what happened after about half an hour of intense pain and nearly shitting my pants:

1. Call 911 (113 in Norway)
2. Ambulance arrives with health personel
3. Tell ambulance personnel what's wrong
4. Get morphine
5. Transported to emergency
6. Repeat what's wrong to the emergency doctor
7. Transferred to hospital (in the same building)
8. Repeat what's wrong to the hospital doctor
9. Repeat what's wrong to other hospital doctor
10. Get more morphine until able to stand and walk

Interestingly, there were three different EHR systems into play (sic!) and none of them were interested in speaking with each other.

I would have preferred that they had trusted each other more...

Health sector vs. the law

Since health information is personal data and is considered sensitive, all health care providers with EHR systems are responsible for processing health information.

Counteracting legislation or a perfect mix?

The health care providers in Norway actually have three layers of law to understand and to comply with:

• EU (GDPR)
• Public management legislation
• Health care legislation

With GDPR in play, the organizations have two good reasons to keep the health information safe and secured:

• Loosing it or giving access to the wrong people or organizations might be very expensive.
• They might loose the trust of their patients if it becomes known that their most sensitive information has been accessed by someone that might use it for other purposes than treatment (e.g. an employer, an insurance company etc).

On the other side of the coin, the health care legislation actually require the organizations to give health personnel access to patient health records when they are needed for treatment, regardless of wether they work within the same organization or for a different organization.

The organizations are obligated to share health information, but they better not share it with someone who doesn't need it for treatment of a patient.

What is mine is yours - or was it the other way around?

In Norway all health care services are free of charge, which is damned phantastic. Come join us if you want great health services, enjoy paying high taxes, crave lousy weather and good looking swedish waitors. Here is the link to where you apply for recidency. And this is where to find a job. You will be greeted with lapskaus and boller og brus. I am certain that you will love it here!

Ok, so free of charge is perhaps not entirely correct.. Most health services are publicly funded, which actually means that we pay for it through taxes. I still think the concept is pretty awesome though, and I do pay my taxes with pride - knowing that one day I will probably be on the receiving end.

Where would you like to have your vasectomy done, sir?

All inhabitants of Norway have several rights that grant them freedom to choose certain aspects of their use of the health care sector:

• The general practitioner scheme (fastlegeordningen): Every inhabitant has the right to have a GP, and the municipalities are responsible for providing their inhabitants with their own personal doctor-person. I highly reccommend mine.

• The right to choose the place of treatment (fritt behandlingsvalg): If you have heard about a hospital somewhere far from where you live that has prettier nurses and better doctors than your local hospital, and serve cold beers and bbq for lunch you can choose to be treated there.

These are great features, but these rights also require health information to flow between different businesses, which again requires the systems to interoperate.

The health regions and categories

The public health sector in Norway is split into four health regions:

• the northern region (aka Mordor)
• the middle-part-of-norway region (aka "the best region in the country")
• the western-part-of-norway region
• the southern-and-eastern-part-of-norway region.

Since almost no people (with their wits intact) choose to live outside of Oslo in Norway, the southern-and-eastern-part-of-norway region is larger than the other regions combined.

These four regions provide services that are divided into two main categories:

• The specialist health care services - basically the hospitals
• The primary health care services - where you'll find the GPs and nursing and care, etc.

If you are both healthy and lucky you'll never get any value back from the taxes you've paid. If you are like most people though, you get to enjoy the services from two or more of these providers several times during your life.

The business model

All of these providers are organized as individual organizations/companys. Some of them are subsidiaries of the regional organization, others are subsidiaries of municipalities, and others again are independent and privately held.

Most/all of their funding comes sizzling down in steady streams through the fat governmental money pipeline, singing "do-wah-diddy-diddy-dum-diddy-do".

This is the same money pipeline where most of my salary comes from. Which is why I almost feel religious talking about it. It's beauty is absolutely mezmerising.

The system landscape

National systems and infrastructure

We have some national systems in different flavours. We also have other national stuff that is useful, like common infrastructural components, a dedicated separate membership-based network called "Helsenettet", a dedicated CERT for the sector and a common national code of conduct.

Local and regional EHR systems

The health information is largely produced and stored in the local or regional EHR systems, and is seldom shared across organizational boundarys.

Every health care provider is responsible for providing their health personnel with suitable EHR systems, where they are required to register relevant and neccessary information about the patients they treat and details of the treatment they are given. Every organization choose their own system. And, these systems can be quite different from each other depending on the type of health services they provide.

Do systems have personality traits?

The local systems are quite introvert. They just really like to keep to themselves, and rarely talk to others. There are several reasons for this, many of which are historical: most of these systems were built at a time where it actually was illegal to share health information outside of the business boundaries - unless there were very good reasons for doing so.

Manual vs Automatic

Todays practice of sharing health information is mainly done through messaging or by some physical medium. This practice has an advantage that at the same time is a great disadvantage: it requires manual processing - someone has to do something and/or make a decicion. This obviously doesn't scale..

Instead, we want to be able to search and request information across organizational boundaries automatically, e.g. by having the EHR systems consume APIs.

I know.. This isn't exactly rocket science. We've had web based APIs for decades, but when it comes to GDPR and the health legislation there isn't a whole lot of room for error. And the rules and laws are not easy to understand when you put them into the perspective of sharing health information.

Deciding to mistrust

To sum up why I think trust is the most fundamental issue to solve I have hand crafted a numbered list containing a few of the issues that lead to mistrust.

1. Who bears the responsibility if health information is stolen? The delivering part or the consuming part? Here the law is as unclear and interpretable as it probably should be.
2. The organizations choose to not trust each other. Why? Don't the other organizations know what they are doing?
3. With what precision should we authenticate the health personnel?
4. With what precision should we authenticate the organizations?
5. Some health personnel might be up to no good, how can we stop them before they snoop around in their neighbors health records?
6. Some health personnel might be up to no good, how can we detect that they have snooped around in their neighbors health records?
7. Which doubious security mechanisms are in play? Perhaps the guys who consume services are using nOAuth or nOIDC? noTLS? Poorly implemented authentication? Home grown crypto algorithm/crypto libraries? Home grown PKI?
8. Are the health personnel using poorly implemented or really old EHR systems leaking like a tea strainer?

There are individual answers to all of these questions. And yes, some of the answers can be combined to form what is referred to as a common "trust framework". But it often turns out that the obvious answers aren't as obvoius as one might assume.

An example is eID for physical and legal entities. What if the requirement is some ridiculously high LoA, but the user is authenticated through one or several federation gateways. What happes with the LoA after five hops through five different gateways? Does the identity still comply with the LoA? Do all these gateways take their security equally serious?

Goodbye

Well, it was good to finally get this off my chest. I plan to write about how trust can be modeled and realized in a future post.

In the meantime, have a great day and thank you for reading!

In the two previous posts in my DPoP blog series i looked a little closer at the DPoP specification, and implemented the Authorization Server side of the spec using Duende IdentityServer.

In this post I will describe how things went when I implemented a javascript client that uses the DPoP mechanism.

How did it go, you ask?

Well, to quote Colonel Kurtz in Apocolypse Now: "The horror.. The horror.."

Source code and a demo

I'm not really sure that sharing my code for this blog post is a good idea for my future career.. But I'll take my chances. Before you proceed, just a quick word of advice: Don't use my code as a reference for any production system :). I know I wouldn't.

With that said, you'll find the source code for my client implementation here: https://github.com/udelt/dpop_js_test

And you'll find a demo of the client here: https://dpoptest.z1.web.core.windows.net/index.htm.

Patience is a virtue

The Authorization Server and the API for the demo runs on "cold" Azure instances, and will take a moment to load if it hasn't been accessed in a while. So, you might need to be patient while waiting for a response from the Duende IdentityServer and the API in the DPoP client demo.

Developing a DPoP enabled client

I haven't coded any javascript in many years, so I decided that this was a great opportunity to catch up.

Initial attempts

• I first looked at Filip Skokan's POC implementation of DPoP - aaaaand.. I didn't understand a thing...
• I then looked at OIDC/OAuth client libraries - aaaaaand... I didn't understand a thing

Bummer.. I quickly realized that I needed to focus on learning some javascript, so I started reading the Mozilla documentation pages to understand some of the new concepts in javascript.

I never ride on the same day that I saddle....

To make a long story short, I ended up spending a lot more time on learning javascript than I anticipated. I'm not convinced that this was a great investment since I really don't do any work developing javascript applications. Well - I'm sure I'll have no trouble quickly unlearning what I've just learned.

Keeping it simple

After my intense javascript crash-course I was running extremely low on self-esteem, and decided on the following:

• Steal what I can from Filip Skokan
• No frameworks - just pure javascript (ES6)
• No existing OAuth/OIDC client side library
• Only use a simple OAuth flow: client_credentials
• There will be no client secret
• There will be no PKCE
• I'll spend no time on responsive html
• Using Node as development server
• Deploy the client to Azure Storage (Static Web Site)
• Using Visual Studio Code as IDE
• Only test on chromium based browsers
• All crypto mechanisms using the Web Crypto API in the browser

The demo

Welcome to the demo!

Herein lies the most central pieces of the client demo code.

Generating the key material

The first step in the DPoP flow is to generate the neccessary key material.

The key is used to sign the DPoP proof, and the public key will be transferred to the AS in the jose header in a jwk structure.

A friendly expert pointed out to me that there is no need to export the private key. I've now set the extractable parameter to false. Now, in case of an attack, the key material is kept safe. This tip will be rewarded with a cold beer the next time we meet :)

This job was easily acheived with the SubtleCrypto interface.

In this example the algorithm and curve is hard coded, but it is easy to extend with support for other algorithms.

export async function generateKey() {
    var key = await crypto.subtle.generateKey({
            name: "ECDSA",
            namedCurve: "P-384"
        }, false, ["sign", "verify"])
        .then(function(eckey) {           
            return eckey;
        })
        .catch(function(err) {
            console.error(err);
        });
    return key;
}

Creating the DPoP proof

When the key is generated we can use it to create the DPoP proof that the client presents to the Authorization Server.

This code example basically shows the final part of creating the DPoP proof, and I've more or less copied it directly from Filip Skokans DPoP POC.

export async function createDpopProof(privateKey, header, payload) {
    const p = JSON.stringify(payload);
    const h = JSON.stringify(header);

    const partialToken = [
        Base64Url.ToBase64Url(Base64Url.utf8ToUint8Array(h)),
        Base64Url.ToBase64Url(Base64Url.utf8ToUint8Array(p)),
    ].join(".");

    const messageAsUint8Array = Base64Url.utf8ToUint8Array(partialToken);

    var signatureAsBase64 = await Crypto.Sign(privateKey, messageAsUint8Array);

    var token = `${partialToken}.${signatureAsBase64}`;

    return token;        
}

The signature is generated by using the SubtleCrypto interface, which felt quite intuitive. The part that felt a bit weird was the Base64Url formatting, and the lack of conversion support in the browser.

export async function Sign(privateKey, messageAsUint8Array){
    var signature = await crypto.subtle.sign({
            name: "ECDSA",
            hash: { name: "SHA-256" },
            },
            privateKey,
            messageAsUint8Array)
        .then(function(signature) {
            const signatureAsBase64 = Base64.ToBase64Url(new Uint8Array(signature));
            return signatureAsBase64;
        })
        .catch(function(err){
            console.log(err);
            throw(err);
        });
    return signature;
};

Requesting the Access Token with the DPoP proof

The token request code is so simplified that it isn't really useful for other things than showing how the DPoP proof is transferred via the http header.

Oh, almost forgot: since you're an avid CSP champion, you'll be able to imagine that I added the url of the AS in the CSP meta tag.

export async function getAccessToken(url, dpopProof) {

    var result = await fetch(url, {
            method: 'POST',
            headers: {
                'DPOP': dpopProof,
                'Content-Type': 'application/x-www-form-urlencoded'
            },
            body: 'client_id=client&grant_type=client_credentials'
        })
        .then(response => {
            return response.text();
        })
        .catch(function(error) {
            console.log(error);
        });

        var jsonResult = JSON.parse(result);
        var token = jsonResult.access_token;        
        return token;
}

Generating the the Access Token hash for the new DPoP proof

When the client receives the AccessToken we can calculate it's hash value, and include that in the new DPoP proof that the client will present to the API.

Still using the SubtleCrypto interface. Also, still quite easy..

And the spec says no padding, so i removed the padding.

export async function createHash(accessToken, noPadding = false){
    var encodedAT = new TextEncoder().encode(accessToken);
    var atHash = await crypto.subtle.digest('SHA-256', encodedAT)
    .then(function(hash) {        
        var base = Base64.ToBase64Url(new Uint8Array(hash));
        if (noPadding){
            base = base.replace(/\=+$/, '');
        }    
        return base;
    })
    .catch(function(err){
        console.log(err);
        throw err;
    });
    return atHash;
}

Generating the DPoP proof for the API

The next step is to generate the DPoP proof that the client will present to the API. Also quite easily acheived with javascript. Actually, I think that this is one of the times during coding where I felt that javascript had a certain shine to it..

export async function createDpopProof(atHash, jwk, key, resourceUrl) {
    var dpopProof = {
        key: undefined,
        jwk: undefined,
        thumbprint: undefined
    };

    var dpop_proof_payload = {
        jti: await uuid.generate,
        htm: "POST",
        htu: resourceUrl,
        iat: Math.floor(Date.now() / 1000)
    };

    if (atHash)
        dpop_proof_payload["ath"] = atHash;

    var header = {
        typ: "dpop+jwt",
        alg: "ES256",
        jwk: undefined
    };

    if (!key){
        key = await cryptoModule.generateKey();
    }

    if (!jwk){
        jwk = await cryptoModule.exportJwk(key.publicKey);
        delete jwk.ext;
        delete jwk.key_ops;
    }        

    header.jwk = jwk;

    var dpopProof = await Jwt.create(key.privateKey, header, dpop_proof_payload);

    return { dpopProof: dpopProof, key: key, jwk: jwk};

}

Requesting the API resource with the new DPoP proof and Access Token

The final part is where it's all brought together => requesting the resource at the API.

This code example really only shows how easily the tokens are added to the http header. You don't really have to read it if you think it's boring.

export async function callAPI(accessToken, dpopProof) {
    var url = "https://dpoptestapi.azurewebsites.net/DPoP";
    var response = await fetch(url, {
            method: 'GET',
            headers: {
                'DPOP': dpopProof,
                'Authorization': `DPOP ${accessToken}`,
                'Content-Type': 'application/json'
            },            
        })
        .then(response => {
            var json = response.json();            
            return json;
        })
        .catch(function(err){
            console.error(err);
        });
        return response;
}

My conclusion

Regardless of my lacking experience and competence in Javascript I was able to implement the DPoP mechanism, although perhaps not without effort.. But, for a skilled javascript programmer I would assume that it is actually quite easy.

Not only for browser apps (public apps)?

As mentioned in my first blog post in this series, DPoP is an alternative to the existing mTLS mechanism.

Choosing between sender constraining token with mTLS or on the application layer by using DPoP (or similar) boils down to the ecosystems, environments and infrastructures that the apps run in. As mentioned in part 1 of this series, there are some pitfalls that could make mTLS challenging to use, and for these scenarios DPoP definitely is a viable option.

With that in mind, I really think that the DPoP mechanism is promising for other client types than browser based apps, e.g. mobile and desktop apps.

I would love to see sender constraining of tokens become a default behaviour in OAuth flows, where the choice of using mTLS or DPoP would be more or less transparent for the developer? (E.g: if no TLS client cert is available, then run with DPoP)

Securing the security mechanism

While sender constraining tokens with DPoP is a mechanism that protects the protocol flow itself, the threats for the client (browser) are unchanged. In other words: if the client is compromised, you are still in big trouble.

So, the difficult questions remain:

• How do you keep secrets safe in the browser?
• And, how do you protect your browser app against attacks?

There are, however, some obvious advantages of DPoP:

• The secrets (key material) can have a short lifespan
• DPoP proofs can have a short life span
• The spec is relatively simple to implement

Wrapping it up

While previous attempts (like the token-binding specification) came to a halt, there is some reason to hope that the DPoP spec receives enough attention and that the IETF is able to finalize the specification.

I really hope that the IETF is able to keep the simplicity of the mechanism intact, and that they agree that it complements mTLS in a way that is beneficial to apps that aren't easily able to use client certificates.

Since you might be too lazy to scroll all the way up to the top of the page, I've added a link to the source code and the demo page here at the bottom as well:

You'll find the source code for my client implementation here: https://github.com/udelt/dpop_js_test

And you'll find a demo of the client here: https://dpoptest.z1.web.core.windows.net/index.htm

In my first post i tried to give a high level description of how the mechanism works.

Possible abstract for this post: Not so super programming skills vs IETF OAuth draft, part 1.

Duende IdentityServer

I wanted to test the mechanism. So, my first task was to implement DPoP in an Authorization Server.

Building an AS from scratch was definitely out of scope, so I decided to use the Duende IdentityServer as a starting point. Duende IdentityServer is an implementation of OpenID Connect. It should be considered as more of a core framework than a complete product. Now, I might not be totally unpartial, but believe me when I say that the framework is easy to work with - just plainly damned well written - and it has an appetite for extensions.

Keeping it simple

The specification describes the following

To request an access token that is bound to a public key using DPoP, the client MUST provide a valid DPoP proof JWT in a "DPoP" header when making an access token request to the authorization server's token endpoint. This is applicable for all access token requests regardless of grant type (including, for example, the common "authorization_code" and "refresh_token" grant types but also extension grants such as the JWT authorization grant [RFC7523]).

I interpreted this part quite literally, and aimed for the simplest possible solution:

• only testing client_credentials grant/flow
• no refresh token support
• not caring if I break existing flows (e.g. mTLS)

The token endpoint

I started by extending Duende IdentityServer with a DPoP validator class, and added it to the token endpoint.

var dpopResult = await _dpopValidator.ValidateAsync(context);

if (dpopResult.IsError)
{
    return Error("invalid_dpop_proof"); //TODO: conform to spec
}

The thumbprint of the public key in the DPoP proof

I want Duende IdentityServer to include the thumbprint of the public key in the DPoP proof in accordance with the specification. The goal is to enable the API to verify that the jwk in the DPoP proof that it receives from its client is the same that was used when the client requested the Access Token.

if (dpopResult != null)
{
    if (dpopResult.ValidatedDpopProof.ThumbprintBase64Url != null)
    {
         requestResult.ValidatedRequest.DPoPThumbprint = dpopResult.ValidatedDpopProof.ThumbprintBase64Url;
     }
}

The DPoP validator

My DPoP validator interface has one method that needs to be implemented. This stuff is a job for people that actually know what they're doing (e.g. Dominick and Brock) - in other words: my validator is not in any way complete..

public async Task<DpopValidationResult> ValidateAsync(HttpContext context)
{
      _proof = new ValidatedDpopProof(context);           

      if (_proof.DpopHeader == null)
          return null;

      //2. check "typ"
      if (!_proof.JoseHeader.ContainsKey("typ"))
      {
          return Invalid("DPoP proof does not contain \"typ\" claim", null, null);              
      }

      if (_proof.JoseHeader["typ"].GetString() != "dpop+jwt")
      {
          return Invalid("DPoP proof is not correct type");
      }

      //3. check algorithm
     if (!_proof.JoseHeader.ContainsKey("alg"))
     {
         return Invalid("DPoP proof is not well formed", "JOSE header does not contain \"alg\" claim", null);
      }

      var algorithms = new string[] { "RS256", "RS384", "RS512", "ES256", "ES384", "ES512", "PS256", "PS384", "PS512" };
      var joseAlg = _proof.JoseHeader["alg"].GetString();

      if (joseAlg == "none")
         return Invalid("DPoP jose header cannot contain \"none\" as value");

      if (!Array.Exists(algorithms, alg => alg == joseAlg))
      {
          return Invalid("DPoP jose header contains invalid algorithm", null, null);
      }

      if (!_proof.Payload.ContainsKey("htu"))
      {
            return Invalid("DPoP proof is not well formed", "The \"htu\" claim is not present", null);
      }

      if (_proof.Payload["htu"].GetString() != "https://dpopidentityserver.azurewebsites.net/connect/token")
      {
            return Invalid("Invalid htu value");
      }

      if (!_proof.Payload.ContainsKey("htm"))
      {
            return Invalid("DPoP proof is not well formed", "The \"htm\" claim is not present", null);
      }

      if (_proof.Payload["htm"].GetString().ToLower() != context.Request.Method.ToLower())
      {
            return Invalid("Invalid htm value");
      }


      //4. Validate jwt signature using key in jose header
      var jwtHandler = new JwtSecurityTokenHandler();
      var validationParameters = new TokenValidationParameters
      {
          IssuerSigningKey = _proof.Jwk,
          ValidateIssuerSigningKey = true,
         RequireAudience = false,
          ValidateIssuer = false,
          ValidateAudience = false,
          RequireExpirationTime = false
      };

      jwtHandler.ValidateToken(_proof.DpopHeader, validationParameters, out var validatedToken);

      if (validatedToken == null)
          return Invalid("DPoP Error", "DPoP validation failed", null);

      return new DpopValidationResult(_proof, null, null);
}

Binding the DPoP proof to the access token

The DPoP spec describes how the access token should be bound to the key material contained in the DPoP proof. I felt lucky when I discovered that Microsoft has added some convenience methods that makes the job of creating the thumbprint in accordance with the spec really easy:

var jwk = new Microsoft.IdentityModel.Tokens.JsonWebKey(JoseHeader["jwk"].GetRawText());
Thumbprint = jwk.ComputeJwkThumbprint();

Now that the token validation result contains the DPoP proof thumbprint, the last step is to include the claim in the Access Token. I added the following line to the TokenResponseGenerator class:

8<...
if (!request.DPoPThumbprint.IsNullOrEmpty())
{
      tokenRequest.Jkt = request.DPoPThumbprint;
}
...>8

And the following code to the DefaultTokenService implementation:

8<...
 else if (request.Jkt.IsPresent())
{
      token.Confirmation = "{\"jkt\" : \"" + request.Jkt + "\"}";
}
...>8

The last steps involved adding the "token_type": "dpop" to the token response, but this was such an ugly hack that I am too embarrassed to show anyone..

Conclusion

I think I spent around a total of 6-7 hours in Duende IdentityServer to implement the features that I needed for my POC. Most of this time was spent on plumbing, frenetically trying to remember .net, c# and VS. The DPoP specific details were actually really easy to implement.

I think the specification is quite easy to follow, and Duende IdentityServer was easy to extend. At the same time I think that writing a production ready implementation will take a lot more skills than I possess, and more time - which is why I'll wait for the professionals to implement it correctly.

In my next post I'll show you how my attempts at writing a client that uses my DPoP implementation in Duende IdentityServer went..

Spoiler alert! It turns out that javascript does not love me..

In this series of three posts I will take a look at the DPoP draft from the IETF OAuth WG, and see if I am able to implement the specification using my not so super programming skills..

The problem of token theft

With OAuth 2.0 the API outsources the job of establishing trust to its clients to the Authorization Server. The API relies on the Authorization Server to ensure that the Access Token is issued only to clients that have been granted the right to act on behalf of the user, and that the client is authorized to access the resource.
With the awesome power that the holder of an Access Token posesses, it is clearly a weak link that Access Tokens by specification are Bearer tokens.

[A bearer token is] a security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

Bearer tokens have been used in OAuth 2.0 flows since the framework was published, so whats the problem? Well, one of the more obvious shortcomings of bearer tokens is the risk of tokens being stolen and misused. And basically, if the consequences of stolen tokens are high, the use of bearer token just doesn't cut it. In high risk scenarios the party which is responsible for the data that is exposed through the API would probably require a bearer to prove the possession of cryptographic key material. Or, sender constraining tokens, as some people call it - meaning that use of the token is restricted to the party who was granted access.

You see, a bearer token is comparable to cash: if someone steals your hard earned 100$ bill they can spend it all on cheap vodka at the liqour shop without the cashier ever knowing that it's actually your money, nor does he know the fact that you'd never spend money on cheap liqour. Only the fine stuff, right?

The token is mine, and only mine!

So how can we mitigate the risk of token theft? Well, the API should ideally be able to somehow verify that the access token was issued to the same client that sends the request to the API. There are several proposed solutions for how this could be accomplished, and most of them describe a way of cryptographically binding the access token to some secret that only the client knows. And then to have the client use the same secret when calling the API. Thus making the API capable of verifying that the same secret was used both at the AS and the API.

OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

The IETF WG has described a way of binding Access Token to clients by leveraging existing TLS implementations. Not only does it present an elegant solution for the need to bind the Access Token to the client, it also provides a way to strongly authenticate the client by using the underlying TLS connection.

The mTLS spec is now a Proposed Standard which means that the mechanism will be available in many Authorization Server products. The mTLS approach really makes a lot of sense, and seems to be the obvious choice to mitigate the problem.
...Well, this is true as long as the client can keep the private key that belongs to the client certificate a secret.

Oh... AND, if you are able to give the user a decent user experience - which does not involve the user selecting the correct certificate from a obscure list that pops up on his screen..

Oh... AND, when using ephemeral certificates (created on the fly) - as long as the web server permits self-signed certificates.

Oh... AND, if you want to use mTLS for client authentication - as long as it's practically feasible to create, deploy and manage client certificates for potentially thousands of clients.

Oh... AND, as long as TLS isn't prematurely terminated by some proxy you aren't in control of.

Sadly, this isn't allways the case.
Oh.. Let me rephrase: this is quite often not the case..

A compelling alternative

OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)

Some very clever people at IETF realized that the mTLS mechanism is a bad fit for some application types like SPAs and mobile apps. So they came up with an alternative solution, and named it DPoP (I know, sounds like a new break dance style, innit?).

The name was apparently conceived by strictly following the naming conventions of the IETF, as you can see from Brian Campbells Twitter thread. So, the introduction to my post was not so far fetched after all?

The DPoP proof

The specification describes how a client can prove that it is in possession of a private key (DPoP Proof) that is used when requesting a token from an Authorization Server.

The DPoP proof looks like this (pay extra special notice to the "typ" claim, and some newbies in the payload):

{
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
       "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
       "crv":"P-256"
     }
   }
   .
   {
     "jti":"-BwC3ESc6acc2lTc",
     "htm":"POST",
     "htu":"https://server.example.com/token",
     "iat":1562262616
   }

The DPoP HTTP Header and the Authorization Server

The DPoP proof is transferred to the Authorization Server by adding a new HTTP Header called DPoP, and it goes a little something like this:

POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
    VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
    nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
    QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj
    oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia
    WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg
    4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

   grant_type=authorization_code
   &code=SplxlOBeZQQYbYS6WxSbIA
   &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   &code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz-

After receiving the token request with the DPoP proof the Authorization Server can validate and bind the proof to the Access Token that the client requested - the Access Token now includes the new claim "jkt" which holds a value that uniquely identifies the proof that was presented.

{
     "sub": "someone@example.com",
     "iss": "https://server.example.com",
     "nbf": 1562262611,
     "exp": 1562266216,
     "cnf": { "jkt" : "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" }
   }

After the token is created it is returned to the client just like in the normal flow.

Requesting the API with DPoP

When the client makes a request to the API it includes the Access Token in the Authorization Header like usual, but in addition it adds a new DPoP proof which is constructed using the same key material as the DPoP proof for the token request made to the Authorization Server. The new DPoP proof includes a hash of the Access Token that the client received from the Authorization Server, binding the access token to the DPoP proof in order to make sure that the DPoP proof is tighly bound to this particular grant.

GET /protectedresource HTTP/1.1
   Host: resource.example.org
   Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
   DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
    VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
    nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
    QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
    oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
    WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF
    c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E
    OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

When the API receives both the DPoP proof and the Access Token it is now able to verify that the client that requested the Access Token is in possession of the same key material as the client that called the API.

Conclusion

I really like the approach this specification takes. The concept is easy to understand, and seems to be relatively simple to implement on the client and API with the capabilities found in modern browsers and programming frameworks.

In the next blog-post in this series I will describe how I implemented a proof-of-concept for the Authorization Server side using Duende IdentityServer.

WARNING: I don't do a lot of programming, so the code examples are not for the faint of heart :)