要約

  • トークンは過去の委任を示し、現在の方針判断を自動的に繰り返さない。
  • 受理の根拠には、検証、現在状態、適用方針の識別子、鮮度境界を結び付ける必要がある。

管理者が権限を取り消した後も、API が先に発行されたベアラートークンを有効期限まで繰り返し受理し続ける場面を考えよう。署名とオーディエンスは正しく、期限もまだ切れていないかもしれない。それでも監査ログが受理のたびに「認可済み」と記録すれば、資格情報の検証と、その時点での認可判断を混同することになる。

RFC 6749 のアクセストークンは、範囲と期間を表す資格情報であり、不透明でも自己完結型でもよい。RFC 7009 は失効を定めるが、状態の反映に遅れが生じ得る。RFC 7662 のイントロスペクションは現在有効と判断されているかどうかを問い合わせられる。しかし肯定応答をキャッシュすれば、過去の判断が有効とみなされ続ける時間が生じる。

イントロスペクションはすべての構成で必須ではない。active は照会したリソースに対する認可サーバーの判断であり、利用者本人であること、端末の所有関係、あらゆる業務権限を証明しない。方針によっては失効が関連トークンや元の許可にも及ぶ。反映時間、キャッシュ、時計の許容差、認可サーバーへの依存を合わせて判断する必要がある。

ローカル検証と状態照会は別の問いに答える。前者は提示されたトークンを検証し、後者は認可サーバーに現在の状態を確認する。影響の大きい操作では、通常の読み取りより新しい判定材料が必要になる。ゲートウェイやアプリケーション内の認可キャッシュも対象に含め、発行、失効情報の反映、ローカル検証またはイントロスペクション、リソースサーバーの現在の認可判断までを一つの連鎖として測定する。

有効期間を短くすればリスクの上限は抑えられるが、アカウント、役割、端末、方針が変わらなかった証明にはならない。認可判断記録には、秘密でないトークン指紋、発行者、クライアント、対象主体、オーディエンス、権限範囲、発行時刻と有効期限、検証方法、失効状況または照会結果、適用した方針の識別子、リソースサーバーの判断時刻、キャッシュ保持期限を残す。これにより、当初の委任と現在の受理理由を区別できる。