OAuth 2.0でのHolder-of-Key TokenとKeycloakについて

はじめに

日立製作所の@tnorimatと申します。OAuth 2.0でのHolder-of-Key Tokenについて、コンセプトとその実現方式、そしてKeycloakへのパッチ投稿と実装について記します。

Notes: 本投稿の内容は、公開情報を元に独自に解釈したものです。

Holder-of-Key Tokenについて

OAuthで使われているトークン類は、多くの場合Bearer Token(ベアラトークン)です。Bearer Tokenでは、トークンの所持者以外の第三者でもトークンを行使できるという課題がありました。これに対しHoler-of-Key Tokenではトークンの所持者以外の第三者がトークンを行使しようとした場合これを検知できます。具体的には、Holder-of-Key Tokenとは下記のようなものです。

トークンの所持者証明が行える形式のトークン。
所持者証明を行うために、公開鍵暗号アルゴリズムを使用する。
“Holder-of-Key”＝鍵の所持者であるが、ここでのKeyとは公開鍵暗号アルゴリズムでの秘密鍵（非公開鍵）を指す。
“Proof-of-Possession”という言い方もされている。

OAuth 2.0でのHolder-of-Key Tokenが必要とされるシーン

高いセキュリティ水準が要求されるAPIサービスがあげられます。例えば以下の仕様で必要とされています。

Financial API - Part 2: Read and Write API Security Profile

Financial APIとは、OpenID Foundationが策定している金融業界向けのAPI仕様のことです。

OAuth 2.0でHolder-of-Keyの対象となるToken

OAuth 2.0において、Holder-of-Keyの対象となりえるトークンは、認可コード、アクセストークン、リフレッシュトークンとなります。

OAuth 2.0でHolder-of-Key Tokenを実現する方式

実現方式はいろいろあります。前述のFinancial API Part 2の仕様では、以下2つの方法が挙げられています。

[MTLS] : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
[OAUTB]：OAuth 2.0 Token Binding

双方の仕様ともまだInternet Draftの段階であるため、今後内容が変わる可能性があることにご注意ください。

双方の方法の特徴を以下に示します。

[MTLS]は既存の技術（TLS、クライアント証明書）をそのまま利用するのに対して、[OAUTB]は独自のTLS拡張を必要とします。
所持証明の対象は、[MTLS]ではクライアント証明書に対応する秘密鍵（非公開鍵）であり、[OAUTB]では、Token Binding IDというデータ構造に対応する秘密鍵（非公開鍵）となります。
所持証明の方法は、[MTLS][OAUTB]ともに、公開鍵暗号アルゴリズムを利用したディジタル署名とその検証となります。
「鍵の所持＝トークンの所持」とするために、[MTLS]ではクライアント証明書をトークンと「バインド」し、[OAUTB]ではToken Binding IDというデータ構造をトークンと「バインド」します。
「バインド」とは、対象となる2者に関係があることを検証できるための処理を施すことです。

Holder-of-Key Tokenの効果

前述のとおり、Holder-of-Key Tokenをもちいることで、第三者によるトークンの行使を検知することができます。これについては、OAuth2.0のセキュリティのベストプラクティスであるOAuth 2.0 Security Best Current Practiceの2.2. Token Replay Preventionで記されており、その対策が3.7.1.2. Sender Constrained Access Tokensで述べられています。

例えば、攻撃者が被害者のトークンに加えてクライアント証明書やToken Binding IDを盗聴でき、それを用いてトークンを行使しようとしたとします。

[MTLS]では、TLSハンドシェイク時クライアント証明書を用いたクライアント認証を行うことになっています。この際このクライアント証明書に対応する秘密鍵で、TLSハンドシェイクで交わされたメッセージのダイジェストに対しディジタル署名を行う必要があります。攻撃者は秘密鍵まで盗聴できていないので、これを実施できません。

[OAUTB]では、トークン送信時にToken Binding IDを含むToken Binding Messageを同時に送る必要があります。この際Token Binding IDに対応する秘密鍵で、あるデータ(Exported Keying Material、etc...)にディジタル署名を行う必要があります。攻撃者は秘密鍵まで盗聴できていないので、これを実施できません。

どちらの方法が良いのか

適用の容易さという観点からは、[MTLS]が良いと考えます。

プライバシー保護の観点からは、[OAUTB]が良いと考えます。

[MTLS]では、クライアント証明書とトークンがバインドされます。そのため、このトークンを受け取ったサーバーが裏でアクセス情報を共有すると、あるクライアント証明書の所持者がどこにアクセスしたかがわかってしまう恐れがあります。OAuth 2.0のPublicなクライアントの内ユーザーのデバイス上で動作するアプリケーションについて、場合によってはクライアント証明書の所持者すなわちデバイスのユーザーの関係ができかねません。これについては、Financial API - Part 2: Read and Write API Security Profileの9. Privacy Considerationsで触れられており、ユーザーのデバイス上で動作するPublicなクライアントは、[OAUTB]を適用するべきとあります。

[OAUTB]では、Token Binding IDとトークンがバインドされます。Token Binding IDはアクセス先のサーバーごとに異なるものを使用することができるため、このような問題は起きないであろうと考えます。ただし、トークンの送受信者すべてが[OAUTB]固有のTLS拡張に対応する必要があり、この点を鑑みると[MTLS]の方が適用が容易であると考えます。

OAuth 2.0でのHolder-of-Key Tokenの実装例

オープンソース・ソフトウェアであるkeycloakで、OAuth 2.0でのHolder-of-Key Tokenの実装がされています。バージョン4.0.0.Finalから「OAuth 2 Certificate Bound Access Tokens」という名称で、この機能が入っています。
この実装は筆者が作成したものであり、そのPull Requestは、https://github.com/keycloak/keycloak/pull/5083 となります。

この実装では、[MTLS]の方法でHolder-of-Key Tokenを実現しています。Holder-of-Key Tokenの対象となっているトークンは、アクセストークンとリフレッシュトークンです。

このHolder-of-Key Tokenの適用方法は以下となります。

keycloakが動作するAPサーバーであるWildflyをMutual SSL(TLS)に対応させる

[MTLS]の方式では、TLSハンドシェイク時にクライアント証明書の提示を必要とします。
keycloakのドキュメントServer Administration Guide - 6.6.2. Enable X.509 Client Certificate User Authenticationの、Enable mutual SSL in WildFlyの節を参照ください。

クライアント単位でHolder-of-key Tokenを有効にする

keycloakでは、クライアント単位でHolder-of-Keyの有効・無効を設定できます。デフォルトでは無効となっています。
keycloakのドキュメントServer Administration Guide - 8.1.1. Advanced Settingsの、OAuth 2.0 Mutual TLS Client Certificate Bound Access Tokenの節を参照ください。