メインコンテンツまでスキップ

OAuth 2.0のトークンの種類と用途

概要​

OAuth 2.0の認可フローで発行される主なトークンは「アクセストークン」と「リフレッシュトークン」です。
それぞれの用途に加え、トークンの形式（JWT型／不透明型）についても解説します。

1. アクセストークン（Access Token）​

用途​

  • APIやリソースサーバーへのアクセス権限を示すトークン
  • クライアントがリソースサーバーにリクエストする際に利用

特徴​

  • 通常は短い有効期限（例：数分～数十分）
  • 権限（スコープ）がトークンに紐付けられている

2. リフレッシュトークン（Refresh Token）​

用途​

  • アクセストークンの有効期限切れ後、新しいアクセストークンを取得するためのトークン
  • クライアントが認可サーバーに対し、再認証なしでトークンを更新

特徴​

  • クライアントに長期間保持される
  • 通常はバックエンドサーバーで安全に管理される
  • 取り消し（Revoke）が容易

3. トークンの形式​

JWT型（JSON Web Token）​

  • トークン自体が「署名付きのデータ構造」となっており、内容（payload）を確認可能
  • 発行元や有効期限、スコープ情報などをクライアント・リソースサーバーが検証できる
  • 多くのAPIサービスで標準的に採用（Google、AWS、LINEなど）

利点​

  • 発行元の確認や改ざん検知が容易
  • 分散システムでスケーラブル（状態管理不要）

注意点​

  • 一度発行すると、有効期間中は原則取り消し不可（リスト型リボークなどの工夫が必要）
  • トークンのサイズがやや大きくなる

不透明型（Opaque Token）​

  • ランダムな文字列で、トークン自体は中身がわからない
  • リソースサーバーは、認可サーバーと連携してトークンの有効性やスコープを確認する必要がある

利点​

  • 流出時も内容が推測されにくい
  • サーバー側で即時リボーク・権限変更がしやすい

注意点​

  • リソースサーバーが認可サーバーへ毎回照会する必要があり、パフォーマンスに影響する場合も

4. トークンのまとめ表​

トークン種類主な用途形式有効期限利用例
アクセストークンAPIアクセス・権限管理JWT型/不透明型短いサービス連携API
リフレッシュトークン更新不透明型長め自動ログイン・継続認証

5. セキュリティ上の注意点​

  • アクセストークンはできるだけ短期間のみ有効にし、漏洩時のリスクを最小化する
  • リフレッシュトークンはバックエンドで厳重に管理し、クライアントアプリには保存しない
  • JWT型は署名検証・発行元確認を必ず行う
  • 不透明型は認可サーバーとの連携設計が重要

仕様参照​

RFC・仕様文書​

idp-serverトークン管理機能​

トークンタイプサポート状況実装詳細
アクセストークン形式
不透明トークン✅ 完全対応ランダムストリング形式
JWTアクセストークン✅ 完全対応RFC 7519準拠
Bearer Token使用方法
Authorizationヘッダー✅ 完全対応RFC 6750準拠
Form Body Parameter✅ 完全対応RFC 6750準拠
Query Parameter⚠️ 非推奨セキュリティ上非推奨
リフレッシュトークン
Refresh Token✅ 完全対応RFC 6749 Section 6
Rotation✅ 完全対応セキュリティ向上
IDトークン
JWT ID Token✅ 完全対応IDトークン詳細
暗号化IDトークン✅ 完全対応RFC 7516 JWE対応
トークン管理
Introspection✅ 完全対応Introspection詳細
Revocation✅ 完全対応RFC 7009準拠
有効期限管理
TTL設定✅ 完全対応テナント単位設定可能
自動削除✅ 完全対応期限切れトークンの自動クリーンアップ

idp-server独自トークン拡張​

  • マルチテナント分離: テナント単位でのトークン完全分離
  • カスタムクレーム: プラガブルなトークンクレーム拡張
  • セキュリティ監視: トークン使用状況のリアルタイム監視
  • 監査証跡: トークン発行・使用・取り消しの詳細ログ
  • スケーラブル管理: Redis/PostgreSQLによる高性能トークン管理

OAuth 2.0のトークンは「用途」と「形式」に応じて使い分けるのがセキュア運用のコツです。 現場の要件・システム構成に合わせて最適な設計を心がけましょう！