社内ツールのログイン認証を実装してから、もっといい方法があったことを知りました。
社内ツールに認証が必要になった
Cloudflareにデプロイした社内ツールを作っていて、認証をつける必要が出てきました。社内ネットワークだけで使うならVPN的な制限でもいいんですが、外から見えた方が便利なWebアプリとして置きたかったので、ちゃんとログイン機能が要る。
幸い社内ではGoogle Workspaceを使っていて、全員が同じドメインのGoogleアカウントを持っていました。なのでGoogle OAuth認証を設定して「このドメインのアカウントだけログインできる」という形にすれば、パスワードを別途管理するよりセキュリティ上もマシだろうと考えました。
GCPのGoogle Cloud ConsoleからOAuth認証情報を取得して、クライアントIDとシークレットを設定して、コールバックの処理を書いて——という感じで実装を進めました。AIに書かせながら進めていたので手は動いたんですが、途中からじわじわ不安になってきました。
「ちゃんと確認するのめんどいな」という感覚
AIに書かせたコードは、パッと見た感じは動いていて、試してみたら一応ちゃんと認証が通る。ざっと見た感じ大丈夫そうではある。
ただ「ざっと見て大丈夫そう」と「ちゃんと確認して問題ない」は別の話で、後者をやろうとするとそれなりに時間がかかります。しかもこのツール、顧客情報を扱うものだったので、社外への漏洩は絶対にあってはならない。「まあいけてるやろ」で済む話でもなくて、ちゃんとやらなあかんな、でもめんどいな……という感じで、確認作業に向き合う前に他に楽な方法ないかなと調べ始めていました。
Zero Trustの存在を知る
調べていたら、Cloudflare Zero Trustというものが出てきました。
仕組みを読んでいると、アプリのドメインに到達する前にCloudflare側でアクセス制御をしてくれる、ということらしい。つまり、ユーザーがURLを叩いた時点でまずCloudflareの認証を通過しないとアプリにすらたどり着けない。コードベースで認証を実装しなくていい。
Googleアカウントでの認証も設定できる。
「あ、これ最初からこっちでよかったやん」と思いました。
AIが書いたコードの認証ロジックを一個一個確認するより、Zero Trustを設定してしまう方が早い。Cloudflareのインフラ側がやってくれているならそこはもう大丈夫に決まっているので、心配するだけ無駄です。
実装した認証が無駄になった
Zero Trustに切り替えた結果、それまで書いていたOAuth認証の実装はほぼ丸ごと不要になりました。
GCPで認証情報を取得する作業も、コールバック処理も、ログイン画面のUIも、ログイン後に他の画面へ遷移する処理も——全部です。Zero Trustはドメインに到達する前にCloudflare側で認証するので、アプリ内にログイン画面が存在しない。ユーザーはCloudflareの認証を通過したら直接アプリの中にいます。
返してほしい。その時間。
まあGCPのOAuth認証情報の取り方とかコールバックの流れとか、知識としては残っているので完全にゼロではないんですが。実装コードは削除しました。
D1を選んでいたのは結果的に正解だった
今回SupabaseではなくD1を選んだのも、後から考えると良かったと思っています。
vibe codingでAIに書かせながら開発していると、データベースのRLS（行レベルセキュリティ）設定とかが抜けがちになる、という話を最近ちらほら聞きます。SupabaseはデフォルトだとRLSを有効にしても設定を間違えるとデータが全部見えてしまう、みたいな事故が起きやすいらしくて、特にAI生成コードで雑に実装するとそのリスクが上がる。
D1はCloudflare Workers内から直接触る構成にしていたので、外からデータベースに直アクセスできるような経路が最初からない。Zero Trustと組み合わせると、インフラ側でアクセス制御して、アプリのコードは本来のロジックだけ書けばいい、という状態になりました。
最初からこの構成で考えていたわけではなくて、気づいたらそうなっていた、という感じではあるんですが。