「認証」と「認可」、似ていて混ざりやすい二人組。認証（Authentication）は「あなたが本当にあなたか」を確かめる側。認可（Authorization）は「その人にこの操作をしていいか」を判断する側。ログインは認証の入口、と捉えるとすっきりする。

ログインの方式にも種類がある。一番古典がパスワード認証。シンプルだが運用が重い。最近よく使われるのがSSO——「Googleでログイン」「Appleでログイン」のあれだ。新しくパスワードを覚えなくていいし、サービス側もパスワードを預からなくて済む、両得な方式。

SSOを実現している裏側の標準ルールがOAuth。ユーザーがGoogleに「このサービスにメアドと名前だけ伝えていい」と一度許可すると、その許可情報を使ってサービス側に渡る、という仕組み。複雑そうに見えて、よくあるパターンに名前がついているだけ。

もうひとつ気軽な方式がマジックリンク。「メールアドレスを入れるとリンクが届くので、そのリンクを押すとログイン完了」というやつ。パスワードを覚えなくていいので、気軽にログインしてほしい一般公開アプリには合う。

これらと別ルートで「許す相手を最初から列挙する」のがホワイトリスト方式。メンバー全員のメアドを事前登録するので、知らない人には使えない。社内ツールや家族用ツール向き。逆に一般公開したいアプリなら、ホワイトリストではなくマジックリンクかSSOを選ぶことになる。

ログインに成功すると、サービス側は「ログイン済みの印」としてトークンを発行する。これ以降は毎回パスワードを送る代わりに、このトークンで本人と見なす。期限を切ることが多いが、GitHubの「No expiration」のように無期限のものもある。漏れた時のリスクが大きいので無期限は基本おすすめしない、という判断軸を持つ。

トークンもAPIキーもパスワードも、コードに直接書くのは絶対NG。それらはシークレットと呼ばれる「漏らしてはいけない値」で、必ず環境変数として外側から渡す。Cloudflareなら Secrets という設定欄、GitHubなら Secrets タブがある。.envというファイルに書く場合も、GitHubには絶対上げない。

そして実際に作業をする時、AIエージェントから「これしていい？」と聞かれる権限（Permission）のダイアログは、要するに認可の小さな実装だ。「誰が・何を・していいか」のルールに従って、その都度確認される。

ところで、なぜここまで一つずつ確かめる必要があるのか。昔はここまでしていなかった。会社のサーバーはオフィスの中にあり、社員もオフィスの中で仕事をしていたので、「社内ネットワークの中にいる人＝信頼していい人」という前提が置けたからだ。入口だけを固く守り、中に入れた人はもう疑わない——城壁と堀の守り方で、これを境界型防御という。社外から使いたい人にはVPNを渡して、「中にいることにする」で解決していた。

その前提が崩れた。データはクラウドに移ってオフィスの中から消え、人は自宅から、カフェから、自分のスマホから繋ぐようになった。中と外を分ける線が、もうどこにも引けない。しかも境界型防御は一度突破されると弱い。VPNで中に入れた人は中のほぼ全部に手が届くので、アカウントを一つ乗っ取られただけで被害が一気に広がる。

そこで前提を入れ替えたのがゼロトラストだ。名前のとおり「最初から信頼する相手をゼロにする」。どこから繋いでいるかで判断するのをやめて、アクセスのたびに「あなたは誰か」（認証）「それを見ていい人か」（認可）を確かめる。ここまで読んできたSSOもホワイトリストもトークンも、全部この考え方を支えるための部品だった。

そして一番混ざりやすいのがここ。ゼロトラストは製品の名前ではなく、考え方の名前だ。Cloudflareのダッシュボードにある「Zero Trust」は、その考え方を実現する道具をまとめた棚のこと。Cloudflare Accessは、その棚に入っている道具の一つで、アプリの入口に立って本人確認をする係だ。設定するとき必ず「Zero Trust → Access」と辿るのは、そういう関係だから。メニューの階層が、そのまま「考え方 → その中の道具」の構造になっている。棚の名前だと分かってしまえば、もう迷わない。

地図を整える：認証が「誰か」、認可が「何していいか」。ログイン方式はパスワード・SSO（裏はOAuth）・マジックリンク・ホワイトリストから選ぶ。入った後はトークン。秘密の値はシークレットとして環境変数で扱う。AIから聞かれる権限はここの末端。そして全体を貫く今の前提がゼロトラスト——場所で信用せず、毎回確かめる。

認証とセキュリティ