Jump links
アクセス トークンとは、API、ウェブ アプリケーション、クラウド サービスなど、さまざまなコンテキストにおけるリソースへのアクセス権限を付与する前に、ユーザーのアイデンティティ(ID)を検証および認証するデジタルキーです。従来のパスワードベースのシステムに代わるものとして使用されるアクセス トークンは、認可の証明として機能し、クライアントとサーバー間のセキュアな通信を可能にします。
アクセス トークンの主要な要素
アクセス トークンにはヘッダー、ペイロード、署名が含まれ、これはリソースに対するユーザーの特権アクセス権限を確認するために連携します。ヘッダーには、作成に使用されるトークン タイプとアルゴリズムに関する情報が含まれています。ユーザーに関する情報(たとえば、アクセス権許諾と有効期限)は、ペイロードに含まれています。署名には、受信者がトークンの真正性を確認するために必要なデータが含まれています。通常、アクセス トークンの署名は、悪用や複製を防止するためにエンコードされます(ハッシュ化など)。
アクセス トークンの取得方法
アクセス トークンは、明示的なリソース オーナーの付与トークンまたはリフレッシュ トークンによって発行されます。アクセス トークンを使用すると、ユーザーに再度アクセスを要求することなく、後日アクセスすることができますが、セキュリティ上の理由から、アクセス トークンの有効期間は限られています。アクセス トークンが期限切れになると、それ以降は使用できなくなります。
アクセス トークンはどこで取得できるか
システムまたはアプリケーションにログオンしたユーザーは、セッションを開始してサービスにログオンした際に作成されるアクセス トークンを持っています。ユーザーのセッションの一部として実行される各プロセスにはトークンのコピーが含まれており、それには現在のセッションを識別するためのログオン セキュア識別子(SID)が含まれています。
アクセス トークンとリフレッシュ トークンはサーバーサイドのセッションに保存することができ、サーバーサイドのコードから発行されたリクエストで利用可能になります。これは、フロントエンド用バックエンド(BFF)プロキシと呼ばれます。アプリケーションは、専用のAPIを使用してアクセス トークンを保存し、メモリ内に保持することや、クッキーに保存することができます。
アクセス トークンの使用
APIアクセス
- アプリケーションが認可サーバーにトークンを要求し、これらのトークンを使用してAPIにアクセスすることを許可
- 特定のAPI機能へのアクセスを、認証済みアプリケーション、サービス、またはユーザーのみに制限
- APIエンドポイントをセキュア化
クラウド サービス
- データベース、ストレージ コンテナ、仮想マシンなどのリソースへのアクセスを制御
- クラウド プラットフォームがサービスへのアクセスを管理するのを支援
- 機密性の高いクラウド リソースへのアクセスおよびそのリソースとのやりとりを、認証および認可されたエンティティに限定
連携アイデンティティ システム
- 異なるセキュリティ ドメインや組織にまたがるリソースへのアクセスをユーザーに許可
- さまざまなシステムにまたがるユーザーのIDとアクセス権許諾のマッピングを支援
- 複数組織間のコラボレーションにおけるアクセス権限管理を簡素化
モノのインターネット(IoT)
- IoT通信の完全性とプライバシーを維持
- アクセスとデータ送信機能を認証済みデバイスに制限
- IoTデバイスとクラウドや他のデバイス間のセキュアな通信
モバイル アプリケーション
- クレデンシャルを保存せずにユーザーを認証および認可
シングル サイン オン(SSO)システム
- 異なるアプリケーション間でユーザーの認証済みセッションを維持
- 1組のクレデンシャルで複数のアプリケーションやサービスへのシームレスなアクセスを実現
- ログインを繰り返すことの必要性を低減
ウェブ認証(Oauth2とOpenID Connectなど)
- ユーザー認証と認可のためOauth2およびOpenID Connectプロトコルと併用
アクセス トークンの重要性
アクセス トークンは、デジタル リソースを不正アクセスから保護する上で重要な役割を果たします。この重要性を示す利点には、以下などがあります。
セキュリティの向上
アクセス トークンは盗用や回避が困難であるため、パスワードよりも安全な代替手段となります。さらに、アクセス トークンは通常ステートレスであるため、サーバー側でユーザーのセッション情報を保存する必要がありません。
コンプライアンス
トークンは、同意および利用に関するメタデータを含めるように設定できます。この情報は、機密性の高いリソースへのアクセスを管理および制限するための明確かつ監査可能な方法を提供することで、組織が法規制遵守を満たすのに役立ちます。
委任アクセス
アクセス トークンは、ユーザーのクレデンシャルを公開することなく、サード パーティ アプリケーションがユーザーの代理としてアクションを実行できるようにするために使用できます。例としては、ソーシャル メディア アカウントを使用したログインの許可や、サード パーティ サービスとの統合などがあります。
効率性
アクセス トークンは、トークンを取得するために1つの署名のみを構築すればよいので、暗号化のオーバーヘッドを削減します。
詳細なアクセス制御
アクセス トークンは、クライアント アプリケーションに付与されるアクセス権許諾を制限するように設定でき、機密情報やリソースの未認証の露出を低減できます。
相互運用性
アクセス トークンは、異なるサービスやアプリケーション間の相互運用を可能にし、分散環境にわたる共有リソースへのシームレスな統合連携とアクセスを実現します。たとえば、あるAPIエコシステムで、あるサービスがアクセス トークンをリクエストすることで、ユーザーに代わって別のサービスとやりとりできますが、この際クレデンシャルを共有する必要はありません。
攻撃対象領域の縮小
アクセス トークンは、有効期間を短くするようにプログラムすることができ、悪用される可能性のある期間を短くすることで、セキュリティ侵害の可能性と影響(アタックサーフェス)を低減します。
取消可能性
アクセス トークンが侵害された場合や必要なくなった場合は、認可サーバーによって無効化または失効させることができ、リソースへのアクセスに対するセキュリティと制御が強化されます。
拡張性
アクセス トークンは、サーバーがセッション状態を維持する必要性を排除するため、システムの効率的な拡張を可能にします。これは、サービスが中央セッション ストアに頼らずにトークンを独自に検証できる、分散システムやマイクロサービス アーキテクチャにおいて特に有益です。
簡素化された開発
アクセス トークンは、アプリケーションのさまざまな部分にわたるユーザー セッションとアクセス権許諾の管理プロセスを簡素化します。ヘッダーやクエリ パラメータに簡単に渡すことができるため、開発者はさまざまなユース ケースでこれを使用し、最小限のオーバーヘッドでセキュアなアクセスを提供できます。
アクセス トークンの種類
上述のさまざまな状況で使用されるアクセス トークンには、さまざまな種類があります。アクセス トークンの種類の選択は、セキュリティ要件、相互運用性、アプリケーションやサービスの具体的なユース ケースなど、いくつかの基準によって決まります。
使用するアクセス トークンの種類に関わらず、それらは機密データへのアクセスを許可するため、他のアクセス方法と同様のセキュリティ制御が必要であることを忘れないことが大切です。 一般的に使用されるアクセス トークンの種類は以下の通りです。
APIキー
APIキーは、呼び出し元のプログラムまたはユーザーを識別するために使用され、アクセス制御や利用状況の追跡に使用することができます。
ベアラー トークン
アクセス トークンの一種であるベアラー トークンは、自己完結型であり、クライアント アプリケーションに付与された認可を表します。
ベアラー トークンには、ユーザーに関する情報は一切含まれていません。つまり、ベアラー(このトークンの所有者)であれば誰でも使用できるということです。これはHTTP認証でよく使用され、この場合、クライアントは保護されたリソースにアクセスするために、HTTPリクエストの認可ヘッダーにベアラー トークンを提示してリソース サーバーに送信します。
JSON ウェブ トークン(JWT)
JWTは自己完結型のアクセストークンの一種で、認証セッションと認証済みスコープに関する情報を符号化するために、JSON(JavaScript Object Notation)ベースのデータ構造を使用しています。これを使用することで、リソース サーバーは認可サーバーと通信することなく、その真正性と完全性を検証することができます。JWTは、OpenID Connectにおいて、IDトークンやアクセス トークンとしてよく使用されています。
Oauthアクセス トークン
Oauthアクセス トークンは、Oauth認証プロトコルで使用され、アプリケーションがユーザーのパスワードなしでユーザー データの特定の部分にアクセスできるようにします。これらのトークンは、さまざまなスコープと期間に対して柔軟に発行することができます。
参照トークン
JWTやベアラー トークンとは異なり、参照トークンは自己完結型ではありません。これらは認可サーバーに格納されているトークン データへの参照です。クライアントがリソース サーバーにリファレンス トークンを提示する際、リソース サーバーはトークンを検証し、関連するトークン データを取得するために、認可サーバーに対して別途リクエストを行う必要があります。
参照トークンは追加のセキュリティと制御を提供する一方で、リソース サーバーと認可サーバーの間でより多くのやり取りを必要とします。
リフレッシュ トークン
リフレッシュ トークンはOauthアクセス トークンと併用されます。クライアントは、他のトークンの期限が切れた場合に、再認証を必要とせずにユーザーにリフレッシュ トークンを提示することができます。リフレッシュ トークンは、ユーザーが長期間にわたってリソースへの継続的なアクセスを必要とする場合に使用されます。
アクセス トークンの内容
アクセス トークンには、リソース サーバーが保護されたリソースへのアクセスを検証および認可するために必要な情報が含まれています。アクセス トークンの正確な内容は、認証プロトコル(Oauth 2.0、OpenID Connectなど)と実装に基づいて異なりますが、一般的に以下の情報が含まれています。
アクセス トークンの仕組み
アクセス トークンは、ユーザーがシステムとやり取りする際に、ユーザーのクレデンシャルとユーザーのアクションを関連付けることで機能します。ユーザーがシステムにログインすると、アクセス トークンが発行されます。これにはユーザーのIDとアクセス権許諾に関する詳細情報が含まれ、システム内でのユーザーのすべての操作に添付されます。これにより、システムはユーザーが本人であること、およびユーザーが実行しようとしている操作の実行権限があることを確認できます。
一目でわかるアクセス トークンの流れ
- 認可クライアント クライアントは、クライアントID、リクエストされたスコープ、リダイレクトURIとともに、ユーザーを認可サーバーにリダイレクトします。
- 認証 ユーザーまたはクライアント アプリケーションは、認可サーバーまたはアイデンティティ プロバイダーに認証を行います。
- 認可 認可サーバーはユーザーのクレデンシャルを検証し、リクエストされたリソースへのアクセス権限を付与します。
- アクセス トークンの発行 アクセス・トークンは、認証済みユーザーまたはクライアント アプリケーションに対して認可サーバーから発行され、ユーザー情報、アクセス権許諾、および保護されたリソースへのアクセスに必要なその他のメタデータが含まれています。
- アクセス トークンの提示 アクセス トークンをリソース サーバーに提示します。
- アクセストークンの検証 リソース サーバーはアクセス トークンを検証し、その真正性、完全性、有効性を確認します。
- リソースへのアクセス リソース サーバーは、保護されたリソースへのアクセス権限を付与します。
- アクセストークンの有効期限と更新 アクセス トークンの有効期限が切れると、セッションが終了するか、保護されたリソースへのアクセスを継続するために、クライアント アプリケーションが新しいアクセス トークン(リフレッシュ トークンなど)を取得します。
アクセス トークンの取り消し
アクセス トークンの強力なセキュリティ機能として、有効期限が切れる前にトークンを失効させる能力があります。アクセス トークンを失効させる必要があるシナリオとしては、トークンが漏洩した場合、ユーザーがログアウトした場合、またはユーザーのアクセス権許諾やロール(役割)が変更された場合などがあります。
トークンはいくつかの方法で失効させることができます。Oauth 2.0では、クライアントが認可サーバーにトークンを無効化するよう通知するための失効エンドポイントが規定されています。一部のシステムではトークンのブラックリスト化を採用しており、失効したトークンはブラックリストに追加され、リクエストごとにチェックされます。
ユーザーは多くの場合、特にアクティブなセッションを表示および管理する方法を提供するアプリケーションでは、自分自身のトークンを失効させることができます。例えば、多くのウェブサービスでは、ユーザーがすべてのデバイスからログアウトすることを許可しており、これによりすべてのアクティブなトークンが失効します。APIゲートウェイを使用する環境では、ゲートウェイは認証サービスに確認するか、または失効リストを使用してトークンがまだ有効であることを確認することにより、トークンの失効を強制することができます。
アクセス トークンが失効された場合、その方法に関わらず、リソースへのアクセスは直ちに停止されます。一部のシステムでは、失効されたトークンの一元化リストを保持し、各リクエスト時にこのリストを確認します。このリストは、アクセス トークンが失効されたかどうかを判断し、アクセスを拒否すべきかを決定するために使用されます。
アクセス トークンのセキュリティ
アクセス トークンは、それがサポートする認証および認可プロセスの機密性、完全性、信頼性を確保するために適切に保護される必要があります。以下はアクセス トークンを保護するために一般的に使用されるセキュリティ対策です。
- アクセス トークンを特定のクライアント デバイスまたはユーザー セッションに紐づけます。
- アクセス トークンを、パスワード、生体認証、ハードウェア トークンなどの追加の認証要素と組み合わせます。
- 有効期限の短いアクセス トークンを設定し、長期間の使用にはリフレッシュ トークンを使用します。
- アクセス トークンを暗号化します。
- アクセス トークンを無効化する仕組みを確立します。
- ログ、監視、監査の仕組みを導入します。
- アクセス トークンのスコープを制限し、必要なタスクを完了するのに十分なアクセス権許諾のみ付与します。
- アクセス トークンをセキュアに保存します。
- セキュアなチャンネル(HTTPSなど)を介してアクセス トークンを送信します。
- 署名、発行者、視聴者、および有効期限をチェックしてトークンを検証します。
アクセス トークンの使用例
以下は、アクセス トークンの使用方法のいくつかの一般的な例です。
APIアクセス
RESTful APIとのやり取りにおいて、リクエストの認証には多くの場合アクセス トークンが使用されます。たとえば、モバイル アプリがバックエンド サービスからユーザー データを取得する必要がある場合などです。このアプリは、リクエストが認証済みユーザーからのものであることを証明するために、リクエスト ヘッダーにアクセス トークンを含んでいます。
クラウド サービス
クラウド環境(AWS、Azure、GCPなど)では、アクセス トークンを使用して、サービスやアプリケーションに一時的なクレデンシャルを付与することができます。たとえばAWSでは、EC2インスタンスはアクセス トークンを使用することで、S3バケットとやりとりすることができるようになります。
APIコールをセキュア化
セキュアなAPIコールの使用例としては、モバイル アプリでの使用が挙げられます。このようなアプリケーションでは、バックエンド サービスと安全に通信するためにアクセス トークンが頻繁に使用され、認証済みのユーザーのみがデータの取得や更新などの操作を実行できるようにしています。
セッション管理
JWT(JSON Web Token)は、ウェブ アプリケーションのセッション管理に使用できます。ログイン後、ユーザーにはJWTが送信されますが、これはクライアント側(ローカル ストレージやクッキーなど)にも保存され、ユーザーのIDを確認するために各リクエストとともに送信されます。
シングル サイン オン(SSO)
企業環境では、SSO (https://www.sailpoint.com/identity-library/what-is-user-provisioning-and-single-sign-on)システムがアクセス トークンを発行することで、ユーザーは一度ログインするだけで、各アプリケーションごとに個別に認証を行うことなく、複数のアプリケーションにアクセスできるようになります。
サード パーティ サービスへのアクセス
ソーシャル アカウントやその他のアカウント(GoogleやFacebookなど)を使用して、サード パーティのアプリケーションにログインすることができます。この場合、アプリケーションは、ユーザーがクレデンシャルを入力する必要がないように、ユーザーに代わってそれらのサービスとやりとりを行うためのアクセス トークンを受け取ります。
トランザクション認証
決済ゲートウェイでは、認証済みのトランザクションのみが実行されるように、支払い処理に関連するAPIリクエストの認証にアクセス トークンが使用されることがよくあります。
アクセストークンの種類を選択する際は形態が機能に従います
アクセス トークンを使用することで、摩擦の少ない認証が実現できます。アクセス トークンは分散環境における認可とリソース委譲のための実証済みのセキュリティ メカニズムです。どの種類のアクセス トークンを使用するか決定する際には、ユース ケースと要件を評価するための時間を取ってください。