API 認証メソッド

はじめに#

今日の世界では、API は現代のアプリケーションの中核を成しています。API は、バックエンドサービスからデータと機能にアクセスするための主要な方法です。異なるソフトウェアシステムが異なるパーティから通信し、データを共有することを可能にするため、API はビジネスにとって不可欠なものです。しかし、API は攻撃者の共通のターゲットでもあります。API 保護の必要性は以前よりもさらに強くなっています。

API 保護とは、API を不正なアクセス、誤用、および攻撃から保護するプロセスです。これは、任意の API 戦略の重要な要素です。この記事では、3つの一般的な API 保護メカニズム、API キー、基本認証、および OAuth JWT トークンを探ります。最後に、Logto が OAuth JWT トークンを使用して API を保護する方法も示します。

API キー#

API キーは、最もシンプルで広く使用されている API を保護する方法です。API キーは、API プロバイダーによって生成され、認可されたユーザーと共有される、長い文字列です。このキーは、API にアクセスする際にリクエスト ヘッダーに含める必要があります。API キーは、基本的なセキュリティ ニーズに対してシンプルで効果的です。例えば、Google Maps API や AWS などの有名なサービスは、API キーを提供してアクセスを制御し、使用状況を監視します。しかし、セキュリティの面では制限があります。多くの場合、マシン間の通信に使用されます。

e.g.

プロ:#

• 実装が簡単: API キーは実装と使用が簡単です。それは リクエスト ヘッダーにキーを付けることを伴い、開発者とクライアントが理解しやすく、採用しやすいシンプルな方法です。
• 監視が容易: API キーは監視が簡単です。各キーの使用を追跡し、必要に応じて取り消すことができます。
• 有効なレート制限: API キーはレート制限に効果的です。キーごとにリクエスト数の制限を設定して、不正使用を防ぐことができます。
• 非機密データに適している: API キーは機密データまたは公開されている API に適しており、セキュリティ 要件が低い場合に使用できます。

コンス:#

• セキュリティに限界がある: API キーはクライアントサイドのアプリケーション 特に機密データに対して安全ではありません。多くの場合、マシン間の通信に使用されます。
• ユーザ認証には適していない: API キーはアプリケーションまたはシステムに関連付けられており、個々のユーザーに関連しないため、特定のユーザーの識別や行動の追跡が困難です。
• トークンの有効期限がない: API キーは通常、静的で有効期限がありません。キーが漏洩した場合、手動で再生成しない限り無期限で悪用される可能性があります。

基本認証#

基本認証は、API を保護するためのもう1つの一般的な方法です。それは HTTPs プロトコルに組み込まれたシンプルな認証スキームです。ユーザー名とパスワードをリクエスト ヘッダーで送信します。サーバーはこれらの資格情報を検証し、それらが有効であれば要求されたリソースを返します。例えば、多くの Web アプリケーションや RESTful API は、迅速かつ簡単にユーザーを認証する方法として基本認証を採用しています。基本認証は API キーよりも安全です。なぜなら、静的なキーの代わりにユーザー名とパスワードを使用するからです。しかし、それでも機密データには十分ではありません。クライアントの資格情報が平文で送信されるため、傍受されやすいです。基本認証はネットワーク接続が安全な内部システム、例えばマシン間で使用するのに適しています。

e.g.

または

プロ:#

• より強力なセキュリティ: 基本認証は API キーよりも安全です。それは静的なキーの代わりにユーザー名とパスワードを使用します。
• 広くサポートされている: 基本認証は広く採用されており、ほとんどの Web サーバーとブラウザがサポートしています。
• シンプルさ: API キーのように、基本認証も設定と使用が比較的簡単です。

コンス:#

• 資格情報の露出: 基本認証は資格情報を平文で送信するため、安全な接続（HTTPS）の上で使用しない場合、傍受されやすいです。
• トークンの有効期限がない: 基本認証はトークンの有効期限をサポートしていません。トークンが漏洩した場合、手動で再生成しない限り無期限で悪用される可能性があります。

OAuth JWT トークン#

JSON Web Token (JWT) は、RFC 7519 によって定義されている、情報を JSON オブジェクトとして安全にパーティ間で送信するためのオープン標準です。これは Web アプリケーションや API での認証と認可に一般的に使用されます。

署名された JWT は次の形式を持ちます:

それは . で区切られた 3 つの部分、つまりヘッダー、ペイロード、署名で構成されています。

ここに JWT の例があります:

• ヘッダー: トークンの種類とそれを署名するために使用されたハッシュ アルゴリズムに関する情報を含みます。
• ペイロード: ユーザーに関するクレーム（主張）やその他のデータを含みます。
• 署名: ヘッダーとペイロードのハッシュで、秘密鍵で署名されています。

OAuth は、API のセキュア化およびアクセス委任用の包括的なオープンスタンダードで、Web サイトやアプリケーションが他の Web サイト上の情報にアクセスする際、ユーザーのパスワードを渡さずに認可を得るための一般的な方法として使用されます。

JWT と組み合わせると、OAuth JWT トークンは堅牢なセキュリティ ソリューションを提供します。ユーザー名やパスワードなどの機密情報をリクエストごとに送信する代わりに、OAuth JWT トークンは認証に成功したクライアントに発行されます。これらのトークンには、ユーザーとその許可に関する情報が含まれます。加えて、JWT トークンは改ざん防止のためにデジタル署名されることがあり、有効期限を設定することも可能です。これにより、追加のセキュリティ レイヤーが提供されます。

OAuth JWT トークンの重要な利点の1つは、その柔軟性です。これらは、Web アプリやモバイル アプリ、シングルサインオン ソリューションなど、さまざまな種類のアプリケーションで使用できます。例えば、Facebook、Twitter、LinkedIn などの主要なソーシャルメディア プラットフォームは、OAuth JWT トークンを使用してユーザーを認証し、ユーザー データへの安全なアクセスをサードパーティ アプリケーションに提供しています。

プロ:#

• 強化されたセキュリティ: OAuth JWT トークンは高度なセキュリティを提供します。それらはデジタル署名され、暗号化することができ、認可されていないアクセスやデータの改ざんのリスクを軽減します。
• ユーザの識別とアクセスコントロール: JWT トークンにはユーザー識別情報を含めることができ、特定の操作やリソースに対してユーザーがアクセスを許可されているかどうかを示すクレームを含むことができます。
• きめ細かいアクセス制御: JWT トークンはきめ細かいアクセス制御の実装に使用できます。例えば、ユーザーがどのリソースにアクセスできるか、どの操作をそれらのリソースに対して行うことができるかを指定できます。
• トークンの有効期限: OAuth JWT トークンは一定の期間後に失効するように設定することができ、悪用のリスクを軽減します。

コンス:#

• 複雑さ: OAuth JWT トークンは、API キーおよび基本認証よりも複雑です。設定と使用に追加の手順が必要となります。
• トークン管理: OAuth JWT トークンは必要に応じて管理および取り消す必要があります。多くのユーザーやクライアントを持つ大規模アプリケーションでは、これが課題になることがあります。
• リソース消費: トークンの生成および検証には、パフォーマンスのオーバーヘッドが発生する可能性があり、高トラフィックのシナリオでは問題となることがあります。

Logto API 保護#

認証メソッドの選択は、アプリケーションの特定の要件とセキュリティ考慮事項に依存します。API キーはシンプルですがセキュリティが低く、基本認証はよりセキュアですがユーザー識別機能が欠けています。一方で、OAuth JWT トークンは強力なセキュリティとユーザー識別機能を提供しますが、実装と管理の複雑さが増します。

Logto は OAuth JWT トークンを使用して API をシンプルで安全に保護する方法を提供します。OAuth 2.0 と OpenID Connect (OIDC) の両方の標準をサポートしており、ニーズに最も適した認証メソッドを選択できます。client_credentials フローを使用してマシン・ツー・マシン通信を行い、authorization_code フローを使用して Web アプリケーションを認証できます。

マシン・ツー・マシン通信#

Logto は マシン・ツー・マシン タイプのアプリケーションに client_credentials フローを使用します。このフローは、クライアントがクライアント資格情報を安全に保存できる機密クライアントであるバックエンド サーバー通信に適しています。これは「二者間の OAuth」とも呼ばれ、ユーザーを含みません。クライアント資格情報は、アクセス トークンを取得するための認可グラントとして直接使用されます。

統合フローはシンプルでわかりやすいです:

1. Logto Console で API リソースを作成します。
2. Logto Console で マシン・ツー・マシン クライアントを作成します。
3. Logto トークン エンドポイントにリクエストを送信して、アクセス トークンを取得します。

4. アクセス トークンで保護されたリソースにアクセスします。

詳細については、マシン・ツー・マシン統合ドキュメント をご確認ください。

Web アプリケーション#

Web アプリケーションのようなパブリッククライアントの場合、Logto はユーザーを認証するために authorization_code フローを使用します。このフローは、クライアントがクライアント資格情報を安全に保存できないパブリッククライアントである Web アプリケーション向けです。これは「三者間の OAuth」とも呼ばれ、ユーザーを含みます。ユーザーは認証およびクライアントを認可するために認証サーバーにリダイレクトされます。クライアントは次に認証コードを使用してアクセス トークンを取得します。

統合フローは、マシン・ツー・マシン フローよりも少し複雑です:

React を使用して Express.js APIを保護し、JWT トークンを使用して Express サーバー API へのアクセスを設定する総合的な例として、Protect your Express.js API with JWT and Logto 記事をご覧ください。