概要
ファントムトークンはOauthで使用できるデザインパターンの一つです
複数種類のトークンを組み合わせることでセキュリティ、パフォーマンスに配慮しながら認可処理を行うことができます
前提知識
この記事には前提としてOauth, OIDCの知識が必要です
この部分についてはこの記事の範囲外のため別の記事を閲覧してください
アクセストークンの種類について
Oauthで使用されるアクセストークンには以下2つの種類があります
- Opaque Token
- 不透明化トークン
- Structured token
- 構造化トークン
Opaque Token
こちらは無意味な文字列をアクセストークンとして使用します
トークン単体では意味を持たず、使用するには認可サーバに問い合わせを行う必要があります
仕組み上漏洩してもトークンを無効化するだけでよいためセキュリティ的に有利です
ですが、必ず認可サーバの呼び出しをする必要があるためリソース的には不利です
gtoeQ2d8vkTDprVK
Structured Token
これはJWTのように情報が埋め込まれているtokenです
問い合わせを行わなくても情報を取得することが可能のためサービス単体で認可処理を行うことができます
ですが、トークンそのものに情報が埋め込まれているため流失のリスクがあります
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
それぞれ有利不利があるため要件に応じて選択する必要があります
ファントムトークンとは何か
ファントムトークンとはOpaque TokenとStructure Tokenの利点を組み合わせた方法です
マイクロサービスで構築されたサービスで利用されます
- 認証サーバはOpaque TokenとStructure Tokenのペアを作成します
- クライントに対してはOpaque Tokenを渡します
- リクエストを送る際にはプロキシサーバーを経由し、ここでOpaque TokenとStructure Tokenの交換を行います
- プロキシサーバはStructure Tokenとともにマイクロサービスにリクエストを転送します
この方法を使用するとセキュリティ、パフォーマンスを両立することが可能です
- クライアントにはOpaque Tokenを渡すためセキュリティ的に有利です
- マイクロサービスに対してはStructure Tokenを渡すためパフォーマンス的に有利です
実例
擬似的なコードで交換のイメージを掲載します
前提条件
ここではtokenはすでに取得済みと想定します
構成図は以下です
リクエスト詳細
リクエスト開始
クライアントは通常の方法でリクエストを送付します
POST https://demo.com/api/resource/create
Authorization: Bearer opaque-token
Content-Type: application/json
{
"book": "demo"
}
受け取ったProxy Server
Proxy ServerではStructured Tokenとの交換を行い、Authorization Headerを書き換え各APIに転送します
方法としては特に決められていないため例を挙げておきます
- Token introspectionを使用して確認を行い、取得したIDTokenをアクセストークンをして代用
- Token Exchangeを使用してJWTトークンと交換
Micro Service
受け取ったMicro Serviceは公開されているJWKセットを元に署名検証を行います
POST https://demo.com/api/resource/create
Authorization: Bear structured-token
Content-Type: application/json
{
"book": "demo"
}
所管
認証認可関連の開発を行うときはRFCの仕様書を主に読むことが多いため、それ以外の設計手法を知ることができて勉強になりました
公式発表以外の情報を知るためにも勉強会やイベントに積極的に参加をしたいと思います