Consideration on Holder-of-Key Bound Token from FAPI implementer's perspective
by Takashi Norimatsu
We have been implementing FAPI Read Only API Security Profiles and FAPI Read and Write API Security Profiles to the Open Source Software. During this work, we have found some points to be considered for making FAPI Security Profile more beneficial.
In this talk, we will pick up one of such points, "Sender Constraint Token".
One of the methods to realize the sender constraint token is Holder-of-Key Bound and FAPI Read and Write API Security Profiles states that Authorization Code, Access Token and Refresh Token be Holder-of-Key bound.
To make these tokens being Holder-of-Key bound, FAPI Read and Write API Security Profile states that OAuth 2.0 Token Binding [OAUTB] or OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [MTLS] are acceptable.
At first, we pick up Holder-of-Key bound Authorization Code by [OAUTB] and [MTLS]. We discuss the applicability of each method and clarify whose key can be bound with the authorization code on each method by considering the nature of the technology each method adopts and the authorization code's nature theoretically. We also discuss whose key should be bound with the authorization code in the context of Authorization Code Grant and how to realize Holder-of-Key bound token which is not directly sent to the token receiver (namely, the client) from the token issuer (namely, the authorization server).
Next, we pick up Holder-of-Key Bound Access Token and Refresh Token by [OAUTB] and [MTLS]. We discuss the applicability of each method. We also tell some issues we found when we had implemented the Holder-of-Key bound access token and refresh token to OSS by [MTLS] and discuss how to resolve them.
Finally, we discuss the other method to realize the sender constraint token, that is "Client Bound Token" to get around issues when realizing the sender constraint token by Holder-of-Key bound authorization code, access token and refresh token.