API 管理のポリシーに関する解説 [パート 2]: REST API 認証の 5 つの処理方法

※この投稿は米国時間 2023 年 2 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

API は、現代のあらゆるデジタル インタラクションを支えています。たとえば、モバイル デバイスからお気に入りのコーヒーを注文する、スポーツアプリで試合経過を確認する、このブログ投稿をお使いのデバイスで読むといった作業が API のおかげで可能になります。API に支えられたインタラクションの領域が広がっているということは、攻撃を受ける可能性のある領域も広がっていることにほかなりません。Google Cloud の 2022 年 API セキュリティ調査レポート: 最新のインサイトと主要なトレンドからは、2021 年には、過半数の組織が少なくとも 1 度は API 関連のセキュリティ上の脅威を経験しており、API が脅威アクターの格好のターゲットとなっていることがわかります。API のセキュリティを保護するには、慎重な戦略と多層のアプローチが必要です。しかし、優れた API 戦略の基盤は、API にアクセスしようとしているユーザーの ID の認証です。認証によって不正アクセスや不正使用を回避できるため、API やその接続先のバックエンド システムにとってはセキュリティとパフォーマンスの両面で重要な意味を持ちます。

Apigee での認証は主にポリシーを介して処理されます。ポリシーとは、API ゲートウェイが受信リクエストを処理するときに適用するルールです。しかし、適切な認証ポリシーを選択するには、使用する API とユースケースに適したセキュリティ、ユーザビリティ、シンプルさのバランスを考慮する必要があります。

Apigee の API 管理ポリシーについて解説するブログシリーズの第 2 回となる今回の投稿では、不正アクセスや不正使用を回避するためのさまざまな認証ポリシーについて取り上げます。トピックを掘り下げる前に、いくつか基本的なコンセプトをご紹介しましょう。

基本事項の確認: ID、認証、認可

ID とは、リソース（API、システム、サービスなど）にアクセスするために必要なデジタルのユーザー アカウントです。ユーザー アカウントは、ソフトウェア、モノのインターネット デバイス、ロボットなど、人間でなくても構いません。

認証とは、API へのアクセスを許可する前に、クライアントまたはユーザーのデジタル ID を確認するプロセスです。誰か（または何か）が、そのユーザーが本人であることを証明するための認証を行います。

認可とは、ユーザーがアクセスできるリソースを決定するプロセスです。

ID プロバイダ（IdP）とは、ID 情報を作成、維持、管理し、認証サービスを提供するシステム エンティティです。

Apigee での認証の実装

一般に、クライアントになんらかの形で認証情報を提供するよう求めることで認証が行われます。たとえば、ユーザー名とパスワード、OAuth トークン、JSON ウェブトークン（JWT）などの提供が求められます。API オーナーは、ポリシーを使用して認証を Apigee に実装できます。具体的には、Apigee のセキュリティ ポリシーによってすべてのリクエストを認証して認可し、コンテンツを保護できます。

Apigee では、50 以上のポリシーをすぐに利用できます。これらのポリシーには、基本認証、OAuth 2.0、SAML、相互 SSL、API キーなど、複数の異なる API 認証ポリシーが含まれます。このブログ投稿では、いくつかの認証ポリシーの機能、ポリシーを使うタイミング、アプリケーションのニーズに基づくポリシーの実装方法について解説します。

使用できるのは、Apigee が提供している一連のポリシータイプだけに限りません。API プロキシの機能を拡張し、Apigee のポリシーが対応する基本的な管理機能を基にイノベーションを実現するカスタム スクリプトとコード（JavaScript アプリケーションや Java など）を作成することもできます。

API のユースケースに適した認証方法の選択

使用する特定の認証方法を選択する際の基準になるのが、API の要件と API クライアントまたはユーザーのニーズです。特定の認証方法を選択する前に、実務担当者は以下の設計上の考慮事項に対処する必要があります。

1. API およびクライアント アプリケーションとの互換性: モバイル アプリケーションかウェブ アプリケーションか、アサーションが必要か、エンドユーザーは自分の代わりにリソースにアクセスする同意をアプリケーションに与えているかなど、クライアントに関する不明点を明確にすることを検討します。

2. ID プロバイダ: API 管理ソリューション（Apigee など）には通常、クライアント認証情報の自動発行といったすぐに使える機能がほとんど用意されていません。しかし、組織はカスタム機能を使ってユーザー ID を管理したり、外部の IdP を使用して複数のプラットフォーム間の一貫性を維持することを選択したりできます。

3. セキュリティ: 認証方法が異なれば、API とそのリソースのセキュリティ レベルも異なります。たとえば、API が機密データを処理する場合、OAuth 2.0 や相互 SSL などのより強力な認証方法を採用した方がよいでしょう。

4. セルフサービスのオンボーディング サポート: コンシューマ開発者のオンボーディング フローについて検討します。具体的には、開発者がセルフサービスで API にオンボーディングする際に、認証方法で対応すべきかどうかを検討します。

5. エンドユーザーの認証: 認証方法でエンドユーザー（人間のみ）による認証呼び出しにも対応する必要があるかどうかを確認します。

6. デベロッパー エンゲージメント アナリティクス: 認証方法で、開発者と API を使用するアプリに関する分析データを取得できる必要もあるかどうかを確認します。

以上の基準に基づいて、Apigee に実装可能なよく使用される認証方法をいくつか特定しました。以下の枠組みを参考にして、ご自身の API のユースケースに最適な認証方法を選択できます。

#1 API キー（識別のみ）

API クライアントを特定する簡単な方法の一つが、API キーを使用することです。Apigee に組み込まれた ID プロバイダが発行するクライアント ID は、API キーとして使用され、すぐに使える VerifyAPIKey ポリシーで検証されます。

API キーはシンプルですが、このメカニズムは受信リクエストの識別にしか使用できないという注意点があります。信頼性の低い環境では認証メカニズムとして使用すべきではありません。API キーの有効期限は一般に長く、アクセスログから読み取り可能であったり、ツールで適切にマスクされていなかったりすることも珍しくありません。

#2 OAuth2 トークン

OAuth2 は、さまざまな API プロバイダで幅広く使用されている包括的な業界基準です。Apigee は OAuth2 の多様な付与タイプをサポートしており（公式ドキュメントの説明を参照）、最も幅広く採用されている Apigee 認証メカニズムは OAuth2 標準を使用して構築されています。

#3 外部トークンまたはアサーション

外部で生成されたトークンを使用する場合、Apigee は暗号化によってのみ、そのトークンが信頼できる発行元によって発行されたものであることを確認します。Apigee はトークンの発行に関与しておらず、API リクエストに関連付けられたアプリケーション、開発者、API プロダクトに関する情報を自動的に保存することはありません。

これらの情報が必要な状況（例: デベロッパー エンゲージメントに関する分析情報を提供する、トークンの使用を特定の Apigee 環境に簡単に制限する）では、Apigee の ID と外部で管理されている ID の同期も追加で必要になります。外部で管理されている ID と Apigee のリソースを関連付ける一般的な方法として、自動化と Apigee API を介した Apigee と外部 IdP の同期があります。具体的には、Apigee アプリのクライアント ID（API キー）をサードパーティ トークンのクレーム内に含め、JWT 署名検証を介した認証の後に Apigee プロキシがクライアント アプリケーションを識別できるようにします。

#4 トークンの交換

Apigee では、ID プロバイダ（IdP）とサービス プロバイダ（SP）の間のトークンの交換に SAML（Security Assertion Markup Language）アサーションを使用できます。SAML は、異なるシステム間での認証データと認可データの交換を可能にする標準プロトコルです。トークンの交換という観点から見た SAML アサーションは、ID や所有している認可権限など、認証されたユーザーに関する情報が含まれた署名付きの XML ドキュメントです。

トークンの交換は、RFC8693 で説明されているように、前述した外部トークンのアプローチと同じように始まります。ただしこの場合、外部で発行されたトークンが Apigee 発行のトークンと交換されます。外部トークンまたは SAML アサーションを Apigee 発行のトークンと交換することで、信頼性がさらに高まります。これは、外部トークンの用途が、リソース API に直接アクセスするのではなく、認可されたアプリケーションを介して Apigee トークンを取得することに限られるためです。さらに、交換するクライアント アプリケーションのクライアント認証情報の確認によって Apigee アプリケーション、開発者、API プロダクトのコンテキストを取得できる場合、これらを自動的に使用可能にできます。

SAML アサーションを使用してこのようにトークンを交換することで、クライアント アプリケーションは既存の認証システムを利用しながら、サービス プロバイダを介して保護済みのリソースに引き続きアクセスできます。

#5 3 legged OAuth の ID ファサード

ID ファサードは、クライアント アプリケーションと OAuth 認可サーバーの間に配置されるレイヤです。その主な目的は、クライアントがユーザー認証の実装方法の細部を意識する必要がないように、クライアント アプリケーションの基盤となる認証メカニズムを抽象化することです。これにより、開発者は OAuth プロトコルの細部についてあまりよく知らなくても、OAuth をサポートするクライアント アプリケーションを簡単にビルドできるようになります。

ID ファサードは、認証および認可メカニズムの抽象化以外にも、ユーザー管理への対応や追加のセキュリティ対策の提供などのサービスも提供できます。しかし（前のセクションで説明した）トークン交換の主なデメリットは、外部 IdP トークンを Apigee トークンに交換する負担が API コンシューマにかかるという点です。コンシューマはトークンを交換するために明示的に追加の呼び出しを行う必要があり、外部トークンを一時的に所有します。

3 legged OAuth の ID ファサードにより、外部トークンにファサードを作成することでこの負担を回避できます。このファサード プロキシはトークンのエンドポイントを呼び出してから、外部トークンにリンクする Apigee 発行のトークンを作成します。こうして、Apigee のトークン検証によって外部トークンをフロー内で使用できるようになり、ダウンストリーム システムの呼び出しに使用できます。

トークンはファサードを介して遮断されるため、API クライアントは外部トークンに直接アクセスできません。つまり、クライアントはバックエンドを直接呼び出して外部トークンを使用することで API プロキシを回避できないということです。クライアント側からは、ファサードが透過的な性質を持ち、OAuth のフローがその他の認可コードフローと同一であるように見えます。

このパターンの実装を簡素化するために、あらゆる OIDC 互換の IdP の前で使用できる ID ファサードのリファレンス実装を用意しました。

Apigee で認証ポリシーの使用を開始する

数多くある他のセキュリティ ポリシーのうち、Apigee で使用できるものはそう多くありません。特殊なユースケース向けに API プロキシ機能を拡張するカスタム スクリプトを作成することもできます。Apigee で認証ポリシーやその他のセキュリティ ポリシーを実装するための実践的な情報については、Skills Boost ラボを確認するか、オンデマンドの API セキュリティに関するウェブセミナーをご覧ください。認証の詳細、リファレンス アーキテクチャ、広範なサンプルについては、GitHub で Google Cloud のリポジトリをご確認ください。

ぜひ Apigee をご検討ください。詳しい情報は、こちらのドキュメントをご覧ください。さらなる意見交換をお望みの方は、Google Cloud Innovators コミュニティにご参加ください。