It has been a while, everyone.
Every year on April 1, I try to write a joke specification that might actually be useful, but once again I did not manage to write one this year. Before I knew it, April had reached the point where, of 3 equal parts, 1 had already passed. What had kept me busy this year, as it turned out, was trying to standardize a way to use “named” tokens with OAuth, and the time simply slipped away.
You may be wondering what I mean by “named.” Let me explain.
Ordinary OAuth tokens are called “bearer tokens.” A bearer is a person who bears, or carries, something, so the term means “the person who presents it.” “Token” may also be an unfamiliar word in Japan, but here it means a ticket. In the past, on subway systems and the like, passengers would put a coin called a “token” into the ticket gate to pass through. Some subway systems, such as Toronto’s, still work that way. Thus, “bearer token” may sound complicated, but in Japanese it simply means a “bearer ticket.” No matter who brings it, that person can enter as long as the ticket is valid. Japanese train tickets are basically of this type.
The problem with this type of ticket is that if you lose it or it is stolen, someone else can use it.
By contrast, there are “named” tickets. An international-flight boarding pass is one example. Your name should be printed on your boarding pass. At the gate, staff check whether that name matches your passport. (At the same time, they also check whether your face matches the photograph in your passport.) Because the ticket is “named,” even if someone steals the boarding pass, that person cannot use it. They do not have the passport paired with the boarding pass. (Even if you lose your passport along with it, the photograph then becomes the obstacle.) Because a “named ticket” is resistant to theft and loss in this way, it is considered more secure than a “bearer ticket.”
The document I hurriedly wrote to describe how to create the OAuth Token equivalent of such a named ticket is OAuth JWT Proof of Possession (OAuth JPoP). In addition to supporting all the methods described in RFC 7800, this document was written to support the approach envisaged by “Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients.” This, however, resulted in too many options, and using the approach end to end required selecting the correct parts from both documents, which was clearly inconvenient. We therefore held a side meeting at IETF 98 in Chicago and decided to extract and combine the necessary parts of these 2 documents. The result was “Mutual TLS Profiles for OAuth Clients”1.
The mechanism in “Mutual TLS Profiles for OAuth Clients” is simple. First, the Client authenticates to the Token Endpoint using Mutual TLS client authentication. The OAuth Server then retrieves the X.509 certificate used for that authentication from the TLS stack and stores its hash in association with the Access Token it returns. The Client next accesses the resource, again using Mutual TLS client authentication. The resource must verify that the hash of the certificate used at that point matches the hash of the certificate associated with the Access Token. This method is optional; approach 1 is to make the Access Token a JWT and embed the certificate hash in it. In other words, in terms of the boarding-pass example above, the certificate hash corresponds to the “name,” the X.509 certificate used for mutual TLS authentication is the passport, and the corresponding private key—something only you possess—is your “face.” Roughly speaking, that is.
The advantage of this method is that the OAuth Client itself needs almost no changes. The server side is what must support it.
On the other hand, there is also a risk. From the Client’s perspective, it cannot tell whether the Server treated the token as a “bearer ticket” or as a “named ticket.” Because the risk level differs depending on which was used, the Client needs that information for its own risk management. Therefore, when this method is used, the same resource URI must not accept “bearer tickets”2. Strictly speaking, a different Authorization Scheme should be used, but the decision to continue using the Bearer scheme was made to facilitate adoption in UK Open Banking3.
As for OAuth JPoP, I expect it will also make gradual progress. This is because TLS is sometimes terminated outside the security domain of the OAuth system in question; in such cases, end-to-end protection that does not depend on TLS is desirable. Microsoft was going to provide this use case, so I think the work will proceed at a relaxed pace once that appears.
Oh, but why is it “another” way, you ask?
In fact, before I wrote this draft, there was an approach that many people expected would become mainstream: Token Binding. I still believe that it will become mainstream in the future. However, it requires replacing the TLS stack and making other infrastructure-layer changes, so it cannot be implemented solely at the application layer. This prompted cries of, “We want to use it now, but we cannot,” and these drafts were the response: “Then how about doing it this way?” That is why it is “another” way.
See you!
- Not a very good name.
- I submitted a pull request explaining this point, but Brian did not see the need for it, so it has not been merged.
- So please do not throw stones at me…
Related posts
I Will Speak at APIDays London (11/13)
This announcement could hardly be any later, but I will appear at APIDays London on the 13th from 11:10 a.m. local time. The APIDays London website…
I Will Appear on the Okinawa Open Days Panel “Current and Future OSS Initiatives in Economic Security”
It is already the day of the event—in fact, I am writing this now (12/4 9:45) at my desk while preparing for the panel—but I will…
The “DS-511 Guidelines for Handling Digital Identity in Identity Verification for Administrative Procedures, etc.” Have Been Published
After 3 years of development, the Digital Identity Guidelines, to which I had the privilege of contributing as an expert (Expert Meeting on the Revision of…