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

[新野淳一，ITmedia]

この記事は新野淳一氏のブログ「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の秘密鍵による署名と取得済みのアクセストークンを組み合わせて提示をしていき、秘密鍵による署名には同じものが使えないという仕組みがあります。

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

開発生産性向上のための5つの取り組み

　こうしたAPIの開発をどういった形で進めているのかについてお話をさせていただこうと思います。 我々は開発の生産性向上について5つの取り組みをしております。

　1つ目はAPIの標準規約の策定です。メンバーのスキルのミスマッチですね。これはあるものだということで前提に考えております。人材不足の状況ではもう特にそうだと思っております。

　当社のAPI標準規約では中核的なRFCから抽出したエッセンスを記載するようにしています。このことで間違いのない無駄のないガイドを開発者に示すことができています。

　これまでの経験では、APIごとの微妙な違いが設計者の認識によって生まれるケースがありました。例えばレスポンスできるリソースがなかった場合に何を返すのか。

　ある人は正常なレスポンスコード「200」を返してレコードの件数が0件でしたという設計をする人もいます。

　一方でリソースがなかったのでレスポンスコード「404」を返す設計者もいます。こういった些細なことでも定義を先に示しておくことで設計者の悩む時間を削減し、前向きに開発が進められることを実現しております。