bearer tokenとは何か? 持つ者がアクセスできる
bearer tokenは、単に所持するだけでアクセスが付与される認証情報で、HTTPのAuthorizationヘッダーで提示され、サーバーはそれを持つ者を信頼します。
名前がすべてを物語っています。トークンを持つ者はそれを使えます。追加の身元証明はないため、トークン自体を転送中も保存中も秘密に保つ必要があります。pipelineは常にAPI呼び出しにbearer tokenを付与するため、漏洩の防止と短い有効期限が重要になります。
所持がアクセスである
bearer tokenは追加の認証情報を必要としません。提示できれば、サーバーはそれが表すアクセスを付与します。これは便利ですが、漏洩したトークンは誰でもすぐに使えることを意味します。
どう提示されるか
トークンはAuthorizationヘッダーに "Bearer <token>" として入ります。サーバーはそれを検証し、トークンが表すものに基づいてリクエストを認可します。
なぜ秘匿性が重要か
- bearer tokenは常にHTTPS上でのみ送信してください。
- 決してlogに記録したり、CIの出力に表示したりしないでください。
- 漏洩の被害を限定するため、短い有効期限を優先してください。
CI/CDにおけるbearer token
pipelineはトークンをマスクされたsecretとして保存し、deployやAPIの呼び出しに付与します。CIプラットフォームは既知のsecret値をlog内でマスクしますが、誤って表示されたトークンは依然として漏洩しうるため、扱いは慎重に行います。
短命の方が安全
長命のトークンを再利用するのではなく、実行ごとに新しい短命のトークンを発行することで、露出したトークンが有効な期間が限定されます。OIDCベースのフローはこれをCIで実用的にします。
認証エラーは揺らぎではない
期限切れまたは誤ったbearer tokenによる401は、毎回同じように失敗するため、retry可能ではありません。Latchkeyのrunnerは、一般的なendpointへの一時的な転送障害をretryしますが、真の401を表面化させ、あなたがトークンを更新できるようにします。
重要なポイント
- bearer tokenは、追加の証明なしに、それを提示する者にアクセスを付与します。
- HTTPS上のみを通過させ、logには決して現れてはなりません。
- 短命のトークンは漏洩時の被害を限定します。401はretry可能ではありません。