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

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

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

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

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

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

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

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

地図を整える：認証が「誰か」、認可が「何していいか」。ログイン方式はパスワード・SSO（裏はOAuth）・マジックリンク・ホワイトリストから選ぶ。入った後はトークン。秘密の値はシークレットとして環境変数で扱う。AIから聞かれる権限はここの末端。

認証とセキュリティ