プログラムによる認証：APIキー、パーソナルアクセス トークン、OAuth クライアント資格情報フロー

背景#

ソフトウェア開発において、CLIコマンドを通じてAPIリソースにプログラム的にアクセスしたり、バックエンドサービス間の通信を確立したりする必要がある場合、私たち開発者が広く使用する3つの認証メカニズムがあります。それは、APIキー、パーソナルアクセス トークン（PAT）、およびOAuth クライアント資格情報フロー（LogtoではMachine-to-Machineとしてブランド化）です。しかし、それらの違いは何でしょうか？これらの方法のうち、どのシナリオに最適なのでしょうか？このブログ記事では、類似点や相違点を掘り下げ、それぞれをどのシナリオで使用するかの洞察を提供します。

定義#

• APIキー：APIリソースへのリクエストを認証できるシンプルな文字列。
• パーソナルアクセス トークン（PAT）：こちらもシンプルな文字列ですが、APIリソースを認証する際に使用するユーザーを表します。ユーザーの委任です。
• Logto マシン間通信（Logto M2M）：標準OAuth クライアント資格情報フローであり、事前にクライアント登録が必要で、クライアントIDとシークレットを使用してアクセストークンを交換する必要があります。したがって、Logto M2M資格情報は信頼されたクライアントを表し、OAuth クライアント資格情報フローの性質上、使用する際は比較的複雑です。

類似点#

1. 認証目的#

• APIキー、PAT、Logto M2Mのすべてが、特定のサービスまたはリソースにアクセスするためのユーザーまたはアプリケーションの認証を目的としています。それらはリクエスタの身元を証明する資格情報として機能し、通常CLIコマンドやバックエンド間通信のシナリオで使用されます。

2. セキュリティ対策#

• これら3つの認証方法はすべてセキュリティを考慮して取り扱う必要があります。開発者は不正アクセスを防ぐために安全なストレージと送信を確保しなければなりません。

相違点#

1. ユーザーコンテキスト#

• APIキーはプリンシパルを識別せず、認可情報も提供しません。そのため、APIキーは通常、公開データやリソースに匿名でアクセスする場合に使用されます。すべてのサービスがAPIキーの使用をサポートしているわけではありません。
• PATはユーザーのIDを持ち、APIリソースへのリクエストに使用される際にあなたを代表します。一部のシステムでは、PATが特定のサービスにアクセスすることは許可されていません。例：Azure ArtifactsフィードへのNuGetパッケージの公開。
• Logto M2M資格情報は信頼されたクライアントのみが使用できます。クライアントは事前に登録されている必要があります。Logto M2M資格情報を使用する際は、使用するユーザーではなく信頼されたクライアントを表します。

2. 権限の細かさ#

• PATとLogto M2M資格情報は通常、APIキーと比べて権限に対するより詳細な制御を提供し、実行できるアクションを細かく制御します。

3. トークン形式#

• APIキーとPATは通常不透明な文字列で、シンプルです。
• Logto M2Mメカニズムによって発行されるアクセストークンは通常JWT形式です。

4. 認証フロー#

• APIキーとPATはシステム生成の不透明な文字列であり、プロセス中に認証フローは関与しません。例えば、Google Cloud自然言語APIを次のように呼び出すことができます：

• Logto M2Mは標準のOAuth 2.0クライアント資格情報フローを利用しています。各クライアントは事前にクライアントIDとクライアントシークレットを取得し、その後にアクセストークンを交換することができます。クライアントはそのアクセストークンを使用してAPIリソースにアクセスします。

各方法の使用時期#

APIキー#

• サービス間の通信：APIキーは、アプリケーションがCLIを通じてAPIと直接通信する必要があるシナリオに適しています。例：OpenAI APIの呼び出し。
• 公共API：APIを公開する際、APIキーが簡易なアクセス制御方法を提供します。
• 簡略化されたセットアップ：特に開発フェーズで迅速かつ簡単な認証ニーズに対して。Logto M2Mとは異なり、APIキーは事前のクライアント登録を必要とせず、アクセストークンへの交換も必要としません。リクエストにAPIキーをパラメータとして渡すだけで、単に機能します。

パーソナルアクセス トークン（PAT）#

• ユーザー特定のアクション：アプリケーションがユーザーの代わりにアクションを実行する必要がある場合。
• 厳密なアクセス制御（ユーザー）：ユーザーが実行できるアクションに対して詳細な制御が必要なとき。

Logto マシン間通信（Logto M2M）#

• セキュリティ：Logto M2Mは、信頼されたクライアントのみがバックエンドサービスにアクセスできるシナリオに理想的です。
• 厳密なアクセス制御（クライアント）：アプリケーションが実行できるアクションに対して詳細な制御が必要なとき。

結論#

まとめると、APIキー、PAT、Logto M2Mの選択は、ユーザー特定のアクション、マシン間の通信、または両方を含むアプリケーションの特定の要件に依存します。セキュリティと機能性のニーズを評価して、使用ケースに最も適した認証方法を決定してください。

Logto M2Mメカニズムは、RBAC（ロールベースアクセス制御）機能で詳細なアクセス制御を設定することができます。近い将来、APIキーとPATもサポートする予定です。機能の更新をお待ちください！