日本語

api
セキュリティ
認証
PAT
API キー
マシンツーマシン

パーソナルアクセストークン、マシンツーマシン認証、および API キーの定義とその実際のシナリオ

パーソナルアクセストークン (PAT)、マシンツーマシン (M2M) 認証、および API キーの違い、それらの使用方法を学びます。

Guamian

Product & Design

7/26/2024

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

ソフトウェアや SaaS 製品を構築している場合、幅広いユースケースや機能要求に直面することがよくあります：API リクエスト。特に大規模な企業クライアントは、個人レベルまたは組織レベルでリソースへのプログラム的なアクセスを求めることがあります。

このような場合、API キー、パーソナルアクセストークン (PAT)、およびマシンツーマシン (M2M) 認証が必要になることがよくあります。この記事では、これらのメソッドの違いと、それらが開発者向けのB2B製品開発でどのように使用されるかを探ります。

共通点

まずはこれら三つの共通点について見てみましょう。

セキュリティ目的: これらの三つのメソッドはすべて、API、サービス、またはリソースへのアクセスを保護し、制御するために使用されます。すべて、認証および/または認可の手段として機能します。
トークンベースのアプローチ: 各メソッドは通常、一意の文字列またはトークンを使用して識別します。これらのトークンは通常、API リクエストと共に送信され、ヘッダーやクエリパラメータとして送られることが一般的です。
取り消し可能: これらの三つのメソッドで使用されるトークンやキーは、侵害された場合や不要になった場合に取り消し、無効化することができます。これにより、基盤となるシステムを変更することなく迅速なセキュリティ対応が可能になります。
プログラムによるアクセス: これらの三つのメソッドはすべて、APIやサービスへのプログラムによるアクセスを可能にします。これにより、異なるシステムやアプリケーション間での自動化と統合が可能になります。
監査可能: これらの認証メソッドの使用は記録され、監査されることがあります。これにより、API へのアクセスを追跡し、疑わしい活動を監視し、コンプライアンスレポートを作成することができます。
アクセス制御への適応性: これらの三つのメソッドは、さまざまなレベルのアクセス制御と許可を持つように実装することができます。これにより、異なるセキュリティモデルやアーキテクチャの要件に適応させることができます。
プロトコル独立性: REST API と共に使用されることが多いですが、これらのメソッドはさまざまな種類の API とプロトコルに適用することができます。

これらの共通点を理解することで、これらの認証メソッドの共通基盤を認識することができます。それぞれの違いを理解することで、特定のユースケースとセキュリティ要件に最適なソリューションを選択することができます。

さて、次にそれぞれの違いについて話しましょう。ユースケースと、それぞれのメソッドを使用するタイミングに焦点を当てます。

違い

API キー

API キーは、呼び出し元のアプリケーションまたはサービスを識別および認証するために使用されます。通常は長期間有効で、手動で回転させるまで静的であることが一般的で、決まった許可のセットを持つことが多いのが特徴です。主にサーバ間の通信や公開データへのアクセスに使用され、これらのトークンが特定のユーザーを表すことはありません。

API キーはどのように機能するのか？

API キーは API プロバイダーによって提供され、登録された API コンシューマー [1] に渡されます。API コンシューマーはリクエストごとに API キーを含め、API サーバーはそのキーをチェックして消費者の識別子を検証し、要求されたデータを返します。

API キーは、 OAuth や JWT などの他の形式の API 認証ほど効果的ではありませんが、それでも API プロデューサーが使用状況を監視しながら機密データを保護するのに重要な役割を果たします。

[1]: API コンシューマーは、API の機能やデータにアクセスするために API とやり取りするアプリケーション、サービス、またはユーザーのいずれかです。リソースを取得、作成、更新、または削除するためにリクエストを API に送信します。API コンシューマーには、ウェブアプリケーション、モバイルアプリ、その他のサーバーが含まれるほか、API を使用して他のサービスと統合したり、既存のプラットフォーム上に新機能を構築したりする個々の開発者も含まれます。

Postman: API キーとは？

ユースケース

API キーのユースケースについて議論するとき、よく言及されるのは、自動化、データ共有、テスト、開発、セキュリティ管理です。しかし、これらは非常に技術的な話です。実際のシナリオでは、製品を構築する際に最も一般的な目的は統合です。

例 1: Zapier との統合

Zapier: API キーで認証の追加

Zapier は異なるウェブアプリケーションを接続する人気のある自動化ツールです。Zapier とアプリケーションを統合する際には、API キーが使用され、アプリケーションの API へのアクセスが認証および認可されます。例えば、CRM システムとメールマーケティングツールの間でタスクを自動化したい場合、CRM システムから API キーを生成し、それを Zapier に提供します。このキーは Zapier が CRM の API にリクエストを送信する際に使用され、二つのシステム間でデータが安全に流れるようになります。

Zapier

例 2: Stripe との統合

Stripe は API キーを利用して、さまざまなプラットフォームやアプリケーションとの安全な統合を行います。開発者ダッシュボードを使用して、API キーの作成、表示、削除、回転を実行することができます。

Stripe

パーソナルアクセストークン (PATs)

パーソナルアクセストークンは、特定のユーザーの識別と権限を表し、成功した認証またはログイン時に動的に生成され、一般的に限定された有効期間を持ちますが、更新可能です。ユーザー固有のデータと機能への細かい制御を提供し、CLI ツール、スクリプト、または個人の API アクセスに一般的に使用されます。

PATsの仕組み

作成と管理: ユーザーは、それぞれのプラットフォームのアカウント設定から PATs を生成します。
- 例えば、GitHub では、ユーザーが特定の権限と有効期限を持つ細かい PATs または従来の PATs を作成できます。
- Jira や Confluence のような Atlassian 製品では、ユーザーはプロフィール設定から PATs を作成し、トークンの名前とオプションで有効期限を設定できます。
使用方法: PATs は API リクエストの Authorization ヘッダーでベアラートークンとして使用されます。これは、リクエストの認証のために HTTP ヘッダーに含まれるという意味です。
- 彼らは API リソースへの安全なアクセスを可能にし、トークンに付与された権限に基づいてリソースの作成、読み取り、更新、および削除を行うことができます。
- PATs はプラットフォーム内の複数のアプリケーションで使用することができ、アクセスと権限を統一管理を提供します。
取り消しと有効期限の設定:
- PATs は、アカウントのパスワードを変更する必要なく、トークンが侵害された場合にそのトークンを取り消すことができるため、セキュリティが向上し、プラットフォームは PATs の有効期限を設定することを推奨しています。これにより、長期間のトークンが悪用されるリスクが軽減されます。

ユースケース

一般的なシナリオは二つあります。

自動化とスクリプティング

これは、開発者が PAT を使用して、リポジトリから本番環境へのコードの展開を自動化し、手動の介入を減らし、一貫性を確保することを意味します。

例えば、GitHub ユーザーは HTTPS 経由で Git 操作を認証し、GitHub の REST API とやり取りするために PATs を作成することができます。これにより、リポジトリのクローン作成、コミットのプッシュ、問題やプルリクエストの管理など、タスクを自動化することができます。

外部アプリケーションとの統合

これは、異なるシステムやアプリケーション間での安全な通信を可能にすることを意味します。これにより、API キー統合のシナリオに似ているかもしれませんが、PAT はユーザーを表し、クライアントまたはアプリケーションではありません。

例えば、プロジェクトマネージャーが PAT を使用してプロジェクト管理ツールを外部の問題追跡システムと統合し、データのシームレスな交換と同期を実現します。例えば、Atlassian (Jira および Confluence) のように。

上記のシナリオはどちらかというと開発者向けのツールに似ていますが、PATs はこれらのような製品にのみ役立つのでしょうか？いいえ。以下のように、CMS システムと生産性ツールの二つの追加例を挙げることができます。

例 1: Contentful

Contentful: パーソナルアクセストークン

Contentful はヘッドレス CMS プラットフォームであり、Content Management API (CMA) へのアクセスのために OAuth トークンの代わりに PAT を提供します。

主な特徴は以下の通りです。

ユーザーは異なるスコープと権限を持つ複数のトークンを作成できます。
トークンはユーザーのアカウントに紐づいており、ユーザーの権限を継承します。
PATs は特に開発および自動化の目的で便利です。

Contentful

例 2: Airtable

Airtable サポート | パーソナルアクセストークンの作成

Airtable - クラウドコラボレーションプラットフォームが API アクセスで PATs を実装します。

彼らのシステムでは以下が可能です。

異なる範囲とアクセスレベルを持つ複数のトークンを作成することができます。
トークンは特定のベースやワークスペースに限定することができます。
エンタープライズ管理者は、組織全体でより広範なアクセスを持つトークンを作成できます。

Airtable

マシンツーマシン (M2M) 認証

M2M は、人間の介入なしにサービス間での通信を行うために設計されています。それは、ユーザー名とパスワードがサービスの保護に不十分であり、効果的な自動化に不向きであるという考えに基づいています。

現在、マシンツーマシン (M2M) アプリケーションは、 OAuth 2.0 RFC 6749 認可プロトコル に定義されたクライアント資格認証フローを採用しています。これに加え、同様の標準プロトコルにも対応しています。そうです、M2M 認証は PATs や API キーと比べて、オープンスタンダードに対する厳しさが増します。

それは、ユーザーではなくアプリケーションまたはサービス自体を認証し、しばしばステートレス認証のために JWT (JSON Web Tokens) を導入します。これにより、分散システム内でサービス同士が安全に相互作用するための安全な方法が提供されます。

マシンツーマシン認証の仕組み

これは以下のプロセスに従います。

クライアント資格証明: 各マシン (またはサービス) には、一意のクライアント ID とシークレットが割り当てられます。
トークンリクエスト: サービスはこれらの資格証明を認可サーバーに送信します。
アクセストークン: 検証が成功すると、認可サーバーはアクセストークンを発行します。これはしばしば JWT (JSON Web トークン) です。
API リクエスト: サービスはこのトークンを使用して、他のサービスに対する API リクエストを認証および許可します。
検証: 受信サービスはトークンを検証し、そのリソースへのアクセスを付与します。

ユースケース

マシンツーマシン (M2M) 認証を使用したバックエンド間通信の簡潔な例を以下に示します。

シナリオ: サービス A はサービス B の API からデータを取得する必要があります。

セットアップ:
- サービス A は認可サーバーにクライアントとして登録されています。
- サービス A にはクライアント ID とクライアントシークレットが付与されています。
認証:
- サービス A は認可サーバーにアクセストークンを要求します:
トークン発行:
- 認可サーバーは資格証明を検証し、JWT アクセストークンを発行します。
API リクエスト:
- サービス A はそのトークンを使用して、サービス B からのデータをリクエストします:
検証:
- サービス B は認可サーバーでトークンを検証します。
レスポンス:
- 有効であれば、サービス B は要求されたデータをサービス A に返します。

このプロセスにより、ユーザーの介入なしで、OAuth 2.0 クライアント資格認証フローを使用してサービス A とサービス B の間での安全で自動化された通信が可能になります。

デバイス間通信

デバイス間通信、特に IoT (モノのインターネット) の文脈では、デバイス間通信 (M2M) 認証に大きく依存し、安全で効率的なデータ交換を確保します。

例えば、スマートホームデバイスでは、スマートサーモスタットが中央のホームオートメーションハブと通信し、ユーザーの好みに基づいて温度設定を調整します。サーモスタットは M2M 認証を使用してハブにデータを安全に送信し、コマンドを受け取り、許可されたデバイスのみが家庭の暖房システムと対話できるようにしています。

主要なまとめ

はい、この記事の最後まで読みました。では、簡単な要約をしていただけますか？もちろん！以下が主要なポイントです。

スコープ: API キーは広範囲、PATs (パーソナルアクセストークン) はユーザー固有、M2M (マシンツーマシン) トークンはサービス固有。
寿命: API キーは長期間、PATs は短期間、M2M トークンは可変です。
表現形式: API キーは不透明な文字列、PATs は不透明または構造化されたもの、M2M トークンはしばしば JWT (JSON Web トークン) を使用します。
ユースケース: API キーはシンプルな API アクセス用、PATs はユーザー中心の操作用、M2M トークンはサービス間通信用です。

Logto Cloud を無料で試す

共通点#

違い#

API キー#

API キーはどのように機能するのか？#

ユースケース#

例 1: Zapier との統合#

例 2: Stripe との統合#

パーソナルアクセストークン (PATs)#

PATsの仕組み#

ユースケース#

例 1: Contentful#

例 2: Airtable#

マシンツーマシン (M2M) 認証#

マシンツーマシン認証の仕組み#

ユースケース#

主要なまとめ#

共通点#

違い#

API キー#

API キーはどのように機能するのか？#

ユースケース#

例 1: Zapier との統合#

例 2: Stripe との統合#

パーソナルアクセストークン (PATs)#

PATsの仕組み#

ユースケース#

例 1: Contentful#

例 2: Airtable#

マシンツーマシン (M2M) 認証#

マシンツーマシン認証の仕組み#

ユースケース#

主要なまとめ#

共通点