はじめに

OAuth 2.0 には、さまざまなユースケースに対応する複数の認可フローが定義されています。

それぞれのフローが担保するセキュリティレベルや技術的詳細に基づいて、採用するフローを選択することは重要ですが、社外APIの公開目的を達成するためには、それだけでは不十分です。

社外APIの公開目的を達成するためには、APIを利用する企業を効果的に巻き込むことが重要です。そのためには、公開APIのビジネス要件を適切に考慮することが不可欠となります。

本記事では、OAuth 2.0 の適切な認可フローを採用する際に考慮すべきビジネス要件について解説します。

OAuth 2.0の主要な認可フロー

OAuth 2.0 で定義されている主要なフローは以下の通りです。

• Client Credentials Flow

• Authorization Code Flow

• Resource Owner Password Credentials Flow

• Implicit Flow

各フローの技術的な詳細については、すでに様々な記事や書籍で解説されていますので、そちらをご覧ください。

Client Credentials Flow と Authorization Code Flow

公開APIで OAuth 2.0 を採用する場合、認可フローの主要な選択肢は Client Credentials Flow と Authorization Code Flow に絞られます。

一般的にはエンドユーザーの認可プロセスを挟む Authorization Code Flow が選択されるシーンが多くありますが、プロダクトの特性やAPIのユースケースなどのビジネス要件を踏まえると、より実装コストの低い Client Credentials Flow で事足りるシーンも実は多くあります。

まずはそれぞれの認可フローの選定基準を見ていきましょう。

リソースオーナーは誰か

API経由でAPIクライアントが参照・書き込みを行うデータをリソースオーナー（所有者）が誰かが、フローの選択において重要な観点になります。

リソースオーナーは大きく以下の２種類に分類されます。

• 組織（＝テナント、企業、部署、など）

• エンドユーザー

リソースオーナーが組織の場合

組織が所有するデータに対して、APIクライアントが参照・書き込みを行うケースです。例えば、組織間で行う決済情報や、組織が保有している在庫などのデータを扱うAPIを、APIクライアントから利用する状況が挙げられます。

このケースでは、APIクライアント自体（システム）を認証・認可すれば良いため、Machine to Machine認証を実現することができる、Client Credentials Flowを採用します。

リソースオーナーがエンドユーザーの場合

エンドユーザーが所有するデータに対して、APIクライアントがAPI経由で参照・書き込みを行うケースです。例えば、エンドユーザーがAPIクライアントを利用して、エンドユーザー自身が所有するファイルやデータ（例：カレンダーやメールなど）に対して参照・書き込みを行うケースがこれに該当します。

このケースでは、APIクライアントを利用する個々のエンドユーザーの認証・認可を行う必要があるため、Authorization Code Flow を採用します。

APIクライアント開発に投資できる開発リソース

公開APIを利用する企業が、APIクライアントの開発やメンテナンスにどれくらいの工数と人材を投資できるかについても、フロー選択における重要な観点になります。選択するフローによって、APIクライアント開発や継続的なメンテナンスに必要な開発リソースの量に差があるからです。

エンドユーザーをリソースオーナーとしてみなす場合、Authorization Code Flow が第一の選択肢になるかと思います。一方で、 Authorization Code Flow は 組織をリソースオーナーとしてみなす Client Credentials Flowと比較して構成物が多く複雑です。そのためAuthorization Code Flow は、公開APIを提供する企業だけでなく、利用する企業にとっても、そのフローを実現するための開発リソースが相対的に多く必要になります。

たとえば、ある「ファイル」を保存・取得できる公開APIを開発する場合を考えましょう。このとき、エンドユーザーをファイルのリソースオーナーとしてみなすべきでしょうか。それとも、組織をファイルのリソースオーナーとしてみなすべきでしょうか。

もしかすると、公開APIに「どの人のファイルなのか」を特定するユースケースが存在しておらず、より粗い粒度で「どの組織のファイルなのか」を特定できれば良いかもしれません。その場合は Authorization Code Flow を選択するのではなく、Client Credentials Flow を選択することで、公開APIを利用する企業が投資する必要のある開発リソースを圧縮できる可能性があります。結果として、公開APIを利用するかどうかの導入検討や、オンボーディングがスムーズに進み、公開APIの本来の目的の早期達成につながるかもしれません。

企業の性質や規模、置かれている業界や資金状況、内製エンジニアの在籍有無など、さまざまな要因によって、企業ごとに投資できる開発リソースは異なります。最終的には不特定多数の企業に公開APIを提供することを計画している場合でも、初期に提供するターゲットとなる企業のイメージやペルソナを明確にした上で、ビジネス要件を明らかにしていきましょう。

おわりに

公開APIのユースケースや提供するプロダクトの性質に基づいて、利用企業のイメージを明確にし、そこからビジネス要件をさらに正確に導き出すことができます。それらのビジネス要件も観点の一つとして正しく考慮しながら、適切なOAuth 2.0 の認可フローに選択できるようにしましょう。

参考記事

• Which OAuth 2.0 Flow Should I Use?