0 ビットのエントロピー
キー長
エンコード
URL やシェルで安全な文字だけを使うランダムな API キーをブラウザ内で生成。通信なし、記録なし、送信なし。
スペース キーで再生成、C キーでコピー。キーは端末上の crypto.getRandomValues で生成し、このページは外部リソースを一切読み込みません。
API キーは、このサイトの他のジェネレーターが作るような暗号鍵ではありません。これで署名も復号も行わないからです。サーバーが認識する長いランダム文字列にすぎず、したがって重要な性質はただ一つ、誰にも推測できず、サーバーが受け付ける別のキーも作れないことです。128ビットのランダム性ですでに手の届かない領域にあり、多くのサービスが落ち着く先は 256 ビットです。
バイト列はブラウザの暗号論的擬似乱数生成器である crypto.getRandomValues から取得し、Base64URL または16進数として出力しています。どちらの文字集合も URL、HTTP ヘッダー、環境変数、シェルコマンドをエスケープなしで通過できます。ここで通常の Base64 を用意していないのはそのためで、+ と / と = が含まれるからです。タイムスタンプもカウンターも Math.random も経路上にありません。
すべてお使いの端末内で完結します。読み込み後に通信は行わないため、このキーはこれまでどこにも存在せず、どこにも送られません。再読み込みすれば消えます。つまりタブを閉じる前に、鍵の保管先へ貼り付けておく必要があります。
128ビットのランダム性 —— Base64URL で 22 文字 —— ですでに総当たりの範囲外であり、レート制限を通り抜けてこれを当てられる者はいません。256ビットが一般的な既定値なのは、コストがほぼゼロで、レビューでこの議論を蒸し返さずに済むからです。それ以上に伸ばしても安全性は一切上がりません。貼り付けにくくなり、途中のログ行やデータベースの列で切り詰められる可能性が増えるだけです。
使えますが、見た目ほど堅牢ではありません。ランダムな UUIDv4 が持つのは 128 ではなく 122 ビットです。6 ビットがバージョンとバリアントの固定値だからです。それでも十分ではありますが、背後が暗号論的乱数生成器である場合に限られ、実装によっては通常の乱数を使っていることが少なくありません。UUIDv1 と v7 はタイムスタンプを埋め込むため、設計上一部が予測可能です。さらに UUID は見た目で識別子とわかるため、下流のあらゆる仕組みがそれを識別子として扱い、ログに残そうとします。
キーを発行する側なら付けるべきです。sk_live_ や myapp_ のような接頭辞があれば、流出したキーが一目で判別でき、さらに実利として GitHub や GitLab のシークレットスキャンに照合パターンを与えられます。誤ってコミットされたキーが放置されず通報されるわけです。データベースに触れる前に接頭辞で振り分けたり拒否したりもできます。このページの値の前に付けてください。接頭辞は秘密ではなくエントロピーも増やさないため、ランダム部分を置き換えるものではありません。
パスワードと同じくハッシュで保存します。データベースから読み出せるキーは、いつでも持ち出せる状態の漏洩そのものです。ただしパスワードと違い、ここでは素の SHA-256 で十分で、bcrypt のような低速ハッシュは不要です。キーはすでに 128 ビットの一様なランダム値であり、辞書攻撃の対象にならず、リクエストごとにその負荷を払う理由もありません。一覧で見分けられるよう接頭辞か末尾 4 文字だけ平文で保持し、完全な値は作成時に一度だけ表示してください。
API キーは不透明です。発行したシステム以外にとっては何の意味も持たず、そのシステムも照合するには検索が必要です。JWT はその逆で、クレームと有効期限を自身の内部に署名付きで抱えているため、サービスは検索なしに検証できます。OAuth でいうトークンは JWT 寄りで、短命かつスコープ付きで、別の認証を経て発行されます。機械が設定ファイルに置いて長期間使うアクセスにはキーを、アクセス自体が自動的に失効すべき場合にはトークンを使ってください。
中身は同じバイト列で、違うのは長さと、エスケープなしで通用する場所です。Base64URL は短く、256ビットなら16進数の 64 文字に対して 43 文字です。文字集合は A-Z、a-z、0-9、ハイフン、アンダースコアで、いずれも URL、ヘッダー、シェルをそのまま通ります。16進数は長い代わりに、読み上げ、口頭伝達、目視での照合がしやすく、大文字小文字の扱いが雑な相手でも事故が起きません。避けるべきは通常の Base64 です。+ と / は URL でエスケープが要り、= のパディングは転送の途中で削られがちです。
避けてください。クエリ文字列はサーバーのアクセスログ、プロキシのログ、ブラウザの履歴に書き込まれ、さらに Referer ヘッダー経由でページのリンク先へ漏れます。リクエストが手を離れた後、そのどれも制御できません。代わりに Authorization ヘッダーで、Authorization: Bearer に続けてキーを送ってください。通常のログは既定でこれを記録しません。ここで URL 安全な文字集合を使っているのは、たまに現れるパスセグメントや webhook のコールバックのためであって、クエリ文字列を秘密の置き場所として推奨するためではありません。
暗号鍵よりはるかに手軽です。API キーのローテーションは何も再暗号化しないため、コストはクライアントとの調整だけです。一つのアカウントが同時に二本の有効なキーを持てるようにすれば、作成、配布、失効の三手順で済み、連携が止まる時間帯は生まれません。定期実施なら、多くのシステムでは年に一、二回で十分です。それよりはるかに重要なのは、失効が即座に、かつ利用者自身の操作で行えることです。本当に効くローテーションは常に計画外のものだからです。
そのページがキーを送信できない場合に限り安全で、それは信じる対象ではなく確認できる事柄です。開発者ツールの「ネットワーク」タブを開いたまま何度でも生成してみてください。読み込み後は何もリクエストされません。受け取るサーバーは存在せず、漏らしうる解析ツールも外部スクリプトもありません。キーはどこかに貼り付けるまでこのタブのメモリ内にのみ存在し、再読み込みで消えます。