![5© Hitachi, Ltd. 2018. All rights reserved.
１-2 Proof-of-Possession と Binding
公開鍵
秘密鍵
所持
証明
バイン
ディング
公開鍵
秘密鍵
所持
証明
バイン
ディング
検証
【トークン要求・発行時】 【トークン行使時】
[Proof-of-Possession（所持証明）]
所持証明の対象 ：
公開鍵暗号アルゴリズムにおける秘密鍵
所持証明の方法 ：
ディジタル署名
(秘密鍵による署名と、公開鍵による署名検証)
[Binding（バインディング）]
バインディングの対象：
- 公開鍵暗号アルゴリズムにおける公開鍵
- これに対応する派生情報(ex. ハッシュ値)
バインディングの方法：
- トークンの中に入れる
- トークンとバインドされている公開鍵の情報を返す
エンドポイントを用意
バインディングの検証方法：
トークンの行使者が所持証明時に提示してきた公開鍵の
情報と、トークンにバインディングされている公開鍵の
情報とが一致するかどうかを検査する。
所持証明とバインディング検証に成功したら…
リソースサーバーは、アクセストークンを送信してきた
クライアントが、認可サーバーからアクセストークンの発行を
受けたクライアントである、と結論づけられる。
認可サーバー リソースサーバー
クライアント
アクセストークン アクセストークン
クライアント](https://image.slidesharecdn.com/oauth2hoktoken-181129075254/85/OAuth-Holder-of-Key-Token-6-320.jpg)
OAuthのHolder of Key Token
- 1. © Hitachi, Ltd. 2018. All rights reserved. 株式会社 日立製作所 2018/11/29 乗松 隆志 OAuth 2.0でHolder-of-Key Tokenを 実現する仕様について
- 2. 1© Hitachi, Ltd. 2018. All rights reserved. 乗松 隆志(@tnorimat) 株式会社 日立製作所 OSSソリューションセンタ 所属 ⚫ オープンソースソフトウェアへのコントリビューション活動 keycloak(https://www.keycloak.org/) - Mutual TLS Certificate Bound Access Tokensによる、Holder-of-Key Tokenの実装 - RFC 7636 Proof Key for Code Exchange (PKCE)の実装 - 各種トークンに施す署名について、さまざまな署名アルゴリズムの対応 - 共通鍵を使用したJWS Client Assertionによるクライアント認証の実装 など。 自己紹介
- 3. © Hitachi, Ltd. 2018. All rights reserved. １. Holder-of-Key Tokenについて ２. 実現仕様の比較 ３. OAuth 2.0 Token Binding Contents 2
- 4. 3© Hitachi, Ltd. 2018. All rights reserved. １. Holder-of-Key Tokenについて
- 5. 4© Hitachi, Ltd. 2018. All rights reserved. 【トークン(ex. OAuth2.0のAccess Token、HTTPのCookie、etc…)の種別】 ⚫ Bearer Token 誰でも行使できる ⇒ 第三者に漏れると悪用される可能性がある。 ⚫ Holder-of-Key Token (他の言い方もある) 行使できる人が限られる （というか、トークンの送信者がトークンを行使できる者かを、トークンの受信者が 検証できる） ⇒ 第三者に漏れても悪用できない。 （というか、悪用した場合、トークンの受信者がこれを検知できる） 【Holder-of-Key Token実現のためのアイディア】 ⚫ Proof-of-Possession (所持証明：何を所持していることを証明するのか？) ⚫ Binding(バインディング：何と何を結びつけるのか？) １-１ Bearer Token と Holder-of-Key Token
- 6. 5© Hitachi, Ltd. 2018. All rights reserved. １-2 Proof-of-Possession と Binding 公開鍵 秘密鍵 所持 証明 バイン ディング 公開鍵 秘密鍵 所持 証明 バイン ディング 検証 【トークン要求・発行時】 【トークン行使時】 [Proof-of-Possession（所持証明）] 所持証明の対象 ： 公開鍵暗号アルゴリズムにおける秘密鍵 所持証明の方法 ： ディジタル署名 (秘密鍵による署名と、公開鍵による署名検証) [Binding（バインディング）] バインディングの対象： - 公開鍵暗号アルゴリズムにおける公開鍵 - これに対応する派生情報(ex. ハッシュ値) バインディングの方法： - トークンの中に入れる - トークンとバインドされている公開鍵の情報を返す エンドポイントを用意 バインディングの検証方法： トークンの行使者が所持証明時に提示してきた公開鍵の 情報と、トークンにバインディングされている公開鍵の 情報とが一致するかどうかを検査する。 所持証明とバインディング検証に成功したら… リソースサーバーは、アクセストークンを送信してきた クライアントが、認可サーバーからアクセストークンの発行を 受けたクライアントである、と結論づけられる。 認可サーバー リソースサーバー クライアント アクセストークン アクセストークン クライアント
- 7. 6© Hitachi, Ltd. 2018. All rights reserved. 2. 実現仕様の比較
- 8. 7© Hitachi, Ltd. 2018. All rights reserved. 2-1 Mutual TLS Certificate Bound Access Tokens 秘密鍵 所持 証明 バイン ディング 公開鍵 秘密鍵 バイン ディング 検証 【トークン要求・発行時】 【トークン行使時】 認可サーバー リソースサーバー クライアント アクセストークン アクセストークン クライアント X.509証明書 公開鍵 X.509証明書 所持 証明 仕様：OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens (draft-ietf-oauth-mtls-12) ★Internet Draftであるため、まだ今後変更が見込まれます。 Holder-of-Key対象のトークン： アクセストークン 所持証明の対象： クライアントのX.509証明書内の公開鍵に対応する秘密鍵 ★自己署名でも良いことになっています。 ディジタル署名対象データ： TLS Handshakeにおいて、クライアントとサーバーとの間で 交わされたメッセージのダイジェスト ⇒秘密鍵を知らなくても実施できる攻撃である、リプレイ攻撃に 対する耐性があります。 所持証明が行われるレイヤ： TLSレイヤ バインディングとその検証が行われるレイヤ： アプリケーションレイヤ バインディングの対象： - クライアントのX.509証明書 - これに対応する派生情報(ex. ハッシュ値)
- 9. 8© Hitachi, Ltd. 2018. All rights reserved. 2-2 Token Binding 仕様：OAuth 2.0 Token Binding (draft-ietf-oauth-token-binding-08) ★Internet Draftであるため、まだ今後変更が見込まれます。 Holder-of-Key対象のトークン： リフレッシュトークン、アクセストークン、認可コード 所持証明の対象： Token Binding IDと呼ばれる公開鍵に対応する秘密鍵 ★クライアントが、通信相手であるサーバー毎に異なる 鍵ペアを生成し使用できます。 ディジタル署名対象データ： TLSレイヤでネゴシエーション済みのパラメータ ＋TLSレイヤから取得するExported Keying Material(EKM) ⇒秘密鍵を知らなくても実施できる攻撃である、リプレイ 攻撃に対する耐性があります。 所持証明が行われるレイヤ： アプリケーションレイヤ バインディングとその検証が行われるレイヤ： アプリケーションレイヤ バインディングの対象： - Token Binding ID(TBID)と呼ばれる公開鍵 - これに対応する派生情報(ex. ハッシュ値) 所持 証明 バイン ディング 【トークン要求・発行時】 【トークン行使時】 認可サーバー リソースサーバー クライアント アクセストークン アクセストークン クライアント 所持 証明 TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Referred クライアント⇒ リソースサーバ 秘密鍵 公開鍵 TBID：Provided クライアント⇒ リソースサーバ 秘密鍵 公開鍵 バイン ディング 検証
- 10. 9© Hitachi, Ltd. 2018. All rights reserved. Token Bindingの方ができることが多い。 ＊クライアントは通信相手のサーバー毎に鍵ペアを持つことができる。 ＊トークンを払い出すサーバーに対し、そのサーバーに対する公開鍵ではない、 別の公開鍵をバインドすることができる。（ReferredタイプのTBID） が、新しく実装が必要であるため広めるのも難しいと思われる。 ＊ TLS：Token Bindingのネゴシエーション、EKMの提供 ＊ Token Binding：プロトコルのメッセージ処理、所持証明とその検証 ＊ OAuth 2.0：シグナリング、バインディングとその検証 Mutual TLS Certificate Bound Access Tokensの方は、既に広まった技術を使っており、 広めるのはToken Bindingより容易と考えるが、できることはToken Bindingより少ない。 2-3 比較
- 11. 10© Hitachi, Ltd. 2018. All rights reserved. 3. OAuth 2.0 Token Binding
- 12. 11© Hitachi, Ltd. 2018. All rights reserved. 3-1 Refresh Token 所持 証明 バイン ディング リフレッシュトークン クライアント 所持 証明 TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 バイン ディング 検証 認可サーバー リフレッシュトークン リフレッシュトークン要求・発行： リフレッシュトークン行使： トークンの要求元＝トークンの行使者 （＝クライアント） トークンの払出元＝トークンの行使先 （＝認可サーバー） であることから、最もシンプルな構成になっている。
- 13. 12© Hitachi, Ltd. 2018. All rights reserved. 3-2 Access Token 所持 証明 バイン ディング 認可サーバー リソースサーバー アクセストークン 所持 証明 TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Referred クライアント⇒ リソースサーバ 秘密鍵 公開鍵 TBID：Provided クライアント⇒ リソースサーバ 秘密鍵 公開鍵 バイン ディング 検証 ★アクセストークンのバインディングを実施するためのシグナリング（TB：Include-Referred-Token-Binding-ID)は省いています。 クライアント アクセストークン アクセストークン要求・発行： アクセストークン行使： トークンの要求元＝トークンの行使者 （＝クライアント） トークンの払出元≠トークンの行使先 （認可サーバー≠リソースサーバー） であることから、やや込み入った構成になっている。 ＊Token Bindingの、Referredという種類のTBIDを 使用する。 ＊ Referredという種類のTBIDを使用するということ を示すシグナリングが必要となる。
- 14. 13© Hitachi, Ltd. 2018. All rights reserved. 3-3 Authorization Code for Native App Client 所持 証明 バイン ディング クライアント PKCE：code_challenge クライアント⇒ 認可サーバー 公開鍵 TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 バイン ディング 検証 ★認可コードのバインディングおよびバインディング検証をするためのシグナリング（PKCE：code_challenge_method, code_verifier)は省いています。 ブラウザ 認可コード 認可サーバー 認可コード クライアント 認可コード 認可サーバー 認可コード要求・発行： 認可コード送信： 認可コード行使： トークンの要求元（＝クライアント）がトークンの払出元 （＝認可サーバー）と直接TLSコネクションを張れないた め、Token Bindingの仕組みでは所持証明とバインドがで きない。 ＊バインディングは、RFC 7636 Proof Key for Code Exchange(PKCE)を利用する。この際の所持証明につい ては仕様では触れられていない。 ＊バインディング検証および所持証明は、Token Binding の仕組みを利用する。 クライアントとブラウザが同じデバイスで動作している、 という前提らしく、ブラウザが、クライアントが保持する、 クライアント⇒認可サーバーの公開鍵にアクセスしこれ を使用している。
- 15. 14© Hitachi, Ltd. 2018. All rights reserved. 3-4 Authorization Code for Web Server Client 所持 証明 バイン ディング 所持 証明 TBID：Provided ブラウザ⇒ 認可サーバ 秘密鍵 公開鍵 TBID：Referred ブラウザ⇒ クライアント 秘密鍵 公開鍵 TBID：Provided ブラウザ⇒ クライアント 秘密鍵 公開鍵 バイン ディング 検証 PKCE：code_verifier ブラウザ⇒ クライアント公開鍵 バイン ディング 検証 ★認可コードのバインディング検証をするためのシグナリング（PKCE：code_challenge_method, code_challenge)は省いています。 クライアント 認可コード ブラウザ 認可サーバー認可サーバー 認可コード クライアント 認可コード 認可コード要求・発行： 認可コード送信： 認可コード行使： トークンの要求元（＝クライアント）がトークンの払出 元（＝認可サーバー）と直接TLSコネクションを張れ ないため、Token Bindingの仕組みでは所持証明と バインドができない。 ⇒ トークンの要求元をブラウザと考える。これにより、 認可サーバーとブラウザ、ブラウザとクライアントの 間では、Token Bindingの仕組みでことが足りる。 クライアントと認可サーバーの間は、他の仕組みを 必要とする。 ＊認可コードは、ブラウザの公開鍵とバインドされ る。 ＊認可コード行使時のバインディング検証は、RFC 7636 Proof Key for Code Exchange(PKCE)を利用 する。この際の所持証明については仕様では触れ られていない。
- 16. 15© Hitachi, Ltd. 2018. All rights reserved. 3-5 Authorization Code Grant (Native App Client) バイン ディング 【認可コード要求・発行⇒送信時】 認可サーバ 認可コード ブラウザ クライアント バイン ディング 検証 【認可コード行使⇒トークン払出時】 バイン ディング アクセストークン TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Referred クライアント⇒ リソースサーバ 秘密鍵 公開鍵 バイン ディング リフレッシュトークン認可コード クライアント 認可サーバ 認可コード 所持 証明 認可コード行使⇒トークン払出：認可コード送信：認可コード要求・発行： ★認可コードのバインディングを実施するためのシグナリング（PKCE：code_challenge_method, code_verifier)は省いています。 ★アクセストークンのバインディングを実施するためのシグナリング（TB：Include-Referred-Token-Binding-ID)は省いています。 PKCE：code_challenge クライアント⇒ 認可サーバー 公開鍵
- 17. 16© Hitachi, Ltd. 2018. All rights reserved. 3-6 Authorization Code Grant (Web Server Client) 所持 証明 バイン ディング 【認可コード要求・発行⇒送信時】 認可サーバ 認可コード 所持 証明 TBID：Provided ブラウザ⇒ 認可サーバ 秘密鍵 公開鍵 TBID：Referred ブラウザ⇒ クライアント 秘密鍵 公開鍵 TBID：Provided ブラウザ⇒ クライアント 秘密鍵 公開鍵 バイン ディング 検証 ブラウザ クライアント PKCE：code_verifier ブラウザ⇒ クライアント公開鍵 バイン ディング 検証 【認可コード行使⇒トークン払出時】 バイン ディング アクセストークン TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Referred クライアント⇒ リソースサーバ 秘密鍵 公開鍵 バイン ディング リフレッシュトークン認可コード クライアント 認可サーバ 認可コード 所持 証明 認可コード行使⇒トークン払出：認可コード送信：認可コード要求・発行： ★認可コードのバインディングを実施するためのシグナリング（PKCE：code_ code_challenge_method, code_challenge)は省いています。 ★アクセストークンのバインディングを実施するためのシグナリング（TB：Include-Referred-Token-Binding-ID)は省いています。
- 18. 17© Hitachi, Ltd. 2018. All rights reserved. 3-7 Token Refresh 【リフレッシュトークン行使⇒トークン払出時】 バイン ディング TBID：Provided クライアント⇒ 認可サーバー 秘密鍵 公開鍵 TBID：Referred クライアント⇒ リソースサーバ 秘密鍵 公開鍵 バイン ディング クライアント 認可サーバ 所持 証明 (旧)リフレッシュトークン (新)リフレッシュトークン (新)アクセストークン ★トークンリフレッシュで、リフレッシュトークンもリフレッシュされるケースを想定しています。 ★アクセストークンのバインディングを実施するためのシグナリング（TB：Include-Referred-Token-Binding-ID)は省いています。 バイン ディング 検証 リフレッシュトークン行使⇒トークン払出：
- 19. 18© Hitachi, Ltd. 2018. All rights reserved. ⚫ Authorization Code Grantでの認可コードのToken Binding - トークンの要求元と払出元が直接TLSコネクションで通信できないケースの一つ - PKCEを本来の用途ではない用途で使うため、本来の用途で使えない - PKCEを使ってバインディング・バインディング検証するとき、公開鍵に対応する 秘密鍵の所持証明をしていない（できない）気がする - Web Server Clientの場合、認可コードを、ブラウザの公開鍵とバインドしている - Token Bindingせずとも、PKCEでよい気もする 3-8 さいごに（気になる点）
- 20. 19© Hitachi, Ltd. 2018. All rights reserved. ⚫ HITACHIは、株式会社 日立製作所の商標または登録商標です。 ⚫ その他記載の会社名、製品名などは、それぞれの会社の商標もしくは登録商標です 他社所有商標に関する表示
- 21. © Hitachi, Ltd. 2018. All rights reserved. 株式会社 日立製作所 OAuth 2.0でHolder-of-Key Tokenを 実現する仕様について 2018/11/29 乗松 隆志 END 20