※ 本記事は、Robert Wunderlichによる”Announcing request-based auth, dynamic auth, and dynamic routing in OCI API Gateway“を翻訳したものです。

2022年9月21日

API Gatewayの3つのエキサイティングな新機能を発表します。これにより、API開発チームはAPI Gateway内でより詳細な認可を実行し、マルチテナント・アーキテクチャ（動的認可、動的ルーティングおよびリクエストベースの認可）をサポートできます。

API認可の概要

次に進む前に、API Gatewayで使用される基本パターンを確認して、次のステップでクライアントの適切な認証および認可を実施します:

  1. クライアントは、Oracle Cloud Infrastructure（OCI）Identity and Access Management（IAM）、Microsoft Active Directory、Oktaなどのアイデンティティ・プロバイダを使用して認証します。認証に成功すると、クライアントは承認を提供するトークンを受け取ります。

  2. クライアントはトークンを使用してAPIを起動します。

  3. API Gatewayはトークンを検証して、クライアントがリクエストを行う権限を持っていることを確認します。

  4. クライアントが認可されている場合、ゲートウェイは適切なバックエンド・サービスにルーティングしてレスポンスを履行し、クライアントに返します。

A graphic depicting an example of a single-authentication deployment.

ステップ3では、API Gatewayは、IDPからの公開署名証明書を使用するか、IDPのイントロスペクション・エンドポイントを起動してトークンを検証することで、受信したトークンをアイデンティティ・プロバイダ（IDP）で検証します。このステップは、ゲートウェイとIDPの間の信頼関係を表します。OCI API Gatewayの場合、この信頼関係はAPIデプロイメントで構成されます。つまり、各APIデプロイメントは異なるIDPを持つことができます。

ほとんどの場合、このステップはうまく機能します。すべてのクライアントは、APIデプロイメントごとに1つのIDPでAPIプロバイダによってプロビジョニングされます。場合によっては、APIはマルチテナントである必要があり、各テナントは個別のIDPを持つことができます。

動的認証

動的認証を使用すると、ゲートウェイはクライアント・リクエストに基づいて実行時に適切なIDPを選択できます。APIは、テナントがクライアントを維持し、APIプロバイダが各IDPをサポートするように信頼関係を構成しているマルチテナントをサポートできます。このプロセスでは次のステップを使用します。

  1. クライアントは認証を行い、選択したアイデンティティ・プロバイダからトークンを受け取ります。

  2. クライアントがトークンを正常に取得した場合、そのトークンを使用してAPIを呼び出します。

  3. ゲートウェイはトークンを使用してリクエストを受信し、実行時にどのIDPを使用するかを決定するリクエストの要素に基づいてルックアップを実行します。オプションには、クライアントがAPIの起動に使用したリクエスト・ヘッダー（x-tenant-id、ホスト、サブドメインなど）、パス・パラメータ、さらには認可トークン内のクレームなどがあります。

  4. 認可が正常に検証されると、ゲートウェイはリクエストをバックエンドにルーティングし、レスポンスをクライアントに返します。

A graphic depicting an architecture where multiple tenants use a single API.

動的認証では、APIプロバイダがテナントごとにトークンの検証方法を選択することもできます。一部のテナントはJSON Webトークン（JWT）検証を使用でき、その他のテナントは認可ファンクションを使用できます。

この例ではマルチテナントAPIについて説明していますが、あるIDPに格納され、有料アカウントにアップグレードしたときに別のIDPに移動されるトライアル・ユーザーや開発者ユーザーなどの他のユースケースにも適用されます。動的認証を使用すると、API Gatewayは各コールで、実行時に認可を検証するために使用するIDPを決定できます。

動的ルーティング

API Gatewayの責任の一部は、APIクライアント・リクエストを適切なバックエンド・サービスにルーティングすることです。API Gatewayにはすでに堅牢なルーティング機能があり、API内の各パスは異なるバックエンドにルーティングできます。ただし、同じパス・ルートをクライアントに基づいて異なるバックエンドにルーティングする必要がある場合はどうでしょうか? 動的認証の構成と同様に、APIルートに複数のバックエンドを含めることができ、APIはクライアント・リクエストに基づいて実行時に適切なバックエンドを動的に選択できます。

APIゲートウェイで定義されるバックエンドは、HTTP/sのUniform Resource Identifier（URI）、Oracle関数または標準レスポンスです。ルートごとに、ゲートウェイは3つのバックエンド・タイプすべてをサポートできます。1つのクライアントの場合、バックエンドはHTTP/s URIになり、同じAPIおよびルートを起動する別のクライアントの場合、バックエンドは標準レスポンスです。

次の図では、ステップ1から3は同じです。ステップ4では、ゲートウェイはクライアント・リクエスト（”/pets”など）に基づいてルートを選択しますが、リクエストをさらに調査して、リクエストを受信するバックエンドを判断します。

A graphic depicting an architecture using dynamic routing.

動的認証と同様に、セレクタは、適切なバックエンドにルーティングするためのルックアップの実行にリクエストの一部をゲートウェイに指示するように構成されます。セレクタは、ヘッダー、問合せパラメータ、ホスト、サブドメイン、パス・パラメータ、認可要求または使用計画に基づいて定義できます。この機能を使用して、API開発者は、ヘッダーベースのルーティング、使用計画ベースのルーティング、テナントベースのルーティングなどを定義できます。

リクエストベースの認証

API Gatewayは、OAuth 2.0準拠のベアラー・トークンに対するJWT検証をサポートし、OCIファンクション・サービスの機能をAPI開発者に提供して、トークンに対するその他の認可要件を処理します。リクエストベースの承認では、この機能が拡張され、リクエストの複数の要素を使用できるようになります。パス、ヘッダー、問合せパラメータ、ホスト、本文、さらにはmTLSを使用している場合はクライアント証明書などのその他の要素を、認可プロバイダ・ファンクションに含めることができます。この機能を使用すると、複数のトークンを持つ認可関数で、より詳細な認可決定を実行できます。

A graphic depicting an architecture using request-based authorization.

まとめ

これらの新機能により、API開発者はマルチテナント・クライアントにより優れたサービスを提供できるAPIを構築し、動的認証で複数のアイデンティティ・プロバイダにわたる認可をサポートできます。API開発者は、動的ルーティングを使用してバックエンド間のクライアント・トラフィックをセグメント化できます。リクエストベースの認可を使用して、高度なファイングレイン認可およびアクセス管理を実行できます。

Oracle Cloud Infrastructureを使用したAPI管理の詳細は、API管理を参照してください。これらの機能をより深く理解するために、ドキュメントをご覧ください。