Logo Logo
GitHub Designed by Logto
oauth 2.0oidc
GitHub で編集

アクセストークン (Access token)

アクセストークンは、アイデンティティ（例: ユーザーまたはサービス）に代わって保護されたリソースにアクセスするための資格情報です。トークンのスコープ（権限）に基づいて、リソースへのアクセスを許可するベアラートークンです。

アクセストークンとは何ですか？

アクセストークンは、通常文字列形式の資格情報で、保護されたリソースにアクセスするために使用されます。OAuth 2.0 と OpenID Connect (OIDC) のコンテキストでは、 認可サーバー は、クライアント（アプリケーション）に対して認証および認可が成功した後にアクセストークンを発行することがあります。

OAuth 2.0 と OIDC の RFC ではアクセストークンの実装詳細を指定していませんが、実際には次の2つの一般的なタイプのアクセストークンが使用されます：

  • 不透明トークン (Opaque token) : クライアントにとって意味を持たない（「不透明な」）ランダムな文字列。クライアントはトークンをリソースサーバーに提示し、トークンは認可サーバーで検証されます。
  • JSON Web Token (JWT) : クレーム （例: ユーザーID、有効期限）を含み、デジタル署名が付与された自己完結型トークン。リソースサーバーは追加の要求を認可サーバーに行わずにトークンを検証することができます。

アクセストークンはどう機能しますか？

アクセストークンのタイプに応じて、アクセストークンの使用フローは異なる場合があります。

以下は不透明なアクセストークンを使用するシンプルな例です：

以下は JWT を使用するシンプルな例です：

リソースサーバーがトークンを検証する方法の違いは次のようになります：

  • 不透明なトークンの場合、リソースサーバーはトークンを受け取るたびに認可サーバーに追加の要求を行ってトークンを検証する必要があります。
  • JWT の場合、トークンに必要なすべての情報が含まれているため、リソースサーバーは認可サーバーに追加の要求を行わずにトークンを検証することができ、また、リソースサーバーは認可サーバーの JSON Web Key Set (JWKS) から公開鍵をキャッシュすることができます。

アクセストークンは通常短命で、有効期限があります（例: 1時間）。クライアントは現在のトークンが期限切れになると新しいアクセストークンを要求する必要があります。

どのタイプのトークンを使用すべきですか？

不透明なトークンと JWT の選択は、アプリケーションのユースケースとセキュリティ要件に依存します。以下は2つのトークンタイプの比較です：

不透明なトークンJWT
フォーマットランダム文字列自己完結型 JSON オブジェクト
パフォーマンス追加の要求が必要検証が高速
自己完結型いいえはい
トークンサイズ小さい大きい
取り消し即時トークンの期限切れまたは認可サーバーとのインタラクションが必要
拡張性限定的カスタムクレーム
ステートレスいいえはい
セキュリティトークンの検証が必要署名の検証が必要
標準いいえはい (RFC 7519)

2つのトークンタイプのどちらを選択するかについて詳しく知りたい方は、 不透明なトークン vs JWT を参照してください。

認可サーバーとリソースサーバーの役割

ほとんどの場合、 認可サーバー (Authorization Server) には以下の責任があります：

認可サーバーがアクセストークンの意味を解釈しないことに注意する必要があります。たとえば、アクセストークンには read:orders というスコープが含まれているかもしれませんが、認可サーバーはそのスコープの意味を知りません。リソースサーバーがアクセストークンを解釈し、トークンのスコープに基づいて アクセス制御 (Access control) を施行する責任があります。つまり、 リソースサーバー (Resource server) には通常以下の責任があります：

  • アクセストークンの クレーム （例: 有効期限、リソースインジケーター、スコープ）を検証します。
  • トークンのクレーム（通常はスコープ）に基づいてアクセス制御を施行します。
  • アクセストークンが有効な場合、保護されたリソースを提供します。

アクセストークンのライフサイクル

アクセストークンのライフサイクルは通常、次のステージを含みます：

関連項目