ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（後編）（1/2 ページ）

公開 2023年12月06日 12時32分

[ITmedia]

印刷する Googleで優先するソースとして追加

この記事は新野淳一氏のブログ「Publickey」に掲載された「ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（後編）」（2023年12月3日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。

　ヨドバシカメラは現在、顧客との接点をドメインとして設計する新たなAPIを開発中であることを、クリエーションラインが主催し10月27日に開催されたイベント「Actionable Insights Day 2023」で明らかにしました。

　REST APIとして実装される予定のこのAPIについて同社は「ヨドバシスタッフの魂を注入する」としており、厳重なセキュリティやユーザーフレンドリーで高い利便性などが追求されています。

　ヨドバシAPIがどのように設計され、開発、実装されていくのか。その中味が紹介されたセッションの内容を見ていきましょう。

　本記事は前編と後編の2本の記事で構成されています。いまお読みの記事は後編です。

認証強度のレベルダウンを最小限にするための方法

　ただ、我々は顧客の情報を大切に守ろうとしておりますので、レベルダウンを最小限にしようとあがいておりまして、そこで採用しましたのが「OpenID Connect Dynamic Client Registration」です。

　これはクライアント認証をやるんですが、そのときに「private_key_jwt」を採用しています。private_key_jwtは秘密鍵で証明する方式で、その秘密鍵はハードウェアの中で安全に保存されています。

　ちょっと無理があるかもしれないんですが、これで我々としてはAAL 2以上、AAL 3未満といったところで、AAL 2.2ぐらいもらえないかなと思っております。

認可にはOAuth 2.0を採用、さらに所持証明を付加

　次は認可の話に移ります。

　ヨドバシAPIは多くの方々に使っていただけるように考えております。特殊な手法を使ってしまうとそういうことができませんので、認可にはごく一般的な仕様である「OAuth 2.0」を採用しています。

　認証と認可との分離を目的に認可コードフロー（RFC 6749 section-4.1）としました。認可後、OP（OpenID Provider）から認可コードが発行されて、認可コードと引き換えにアクセストークンを取得します。以降はAPI呼び出しのときにこのアクセストークンをサーバー側に提示し、リソースサーバー側でトークンの検証を行い、API利用を許可します。

　さらに顧客の大切なリソースをもっと強く保護したいと考えると、危険なのはアクセストークンが誰かに盗まれた場合です。

　ならば、盗まれたアクセストークンを使えなくすればよいと考えました。

　その対策は2つ。1つ目は、アクセストークンの有効期限を短くする。2つ目は、アクセストークンだけでは使えなくする。

　2つ目の実現のために、所持証明（Proof of Possession）を付加することにしました。具体的には「DPoP」（RFC9449: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer）と呼ばれる仕組みを採用しています。

　これはOPで認可コードからアクセストークンを引き替える際、DPoPの公開鍵もOP側に登録をしてもらいます。API呼び出しのときにはこのDPoPの秘密鍵による署名と取得済みのアクセストークンを組み合わせて提示をしていき、秘密鍵による署名には同じものが使えないという仕組みがあります。

　ですので、この署名を盗み取られたとしてもリソースサーバが不正を発見できるため、リプレイ攻撃はできません。そのため、アクセストークンを奪われても再利用できない、といったことを実現しております。