Google認証システムとセキュリティの設計メモ

この仕組みでやりたいことはシンプルで、Google で本人確認をした上で、許可された人だけが埋め込みアプリを使えるようにすることだ。

ただ、Google ログインを使えばそれで安全というわけではない。認証情報を URL に残してしまったり、ブラウザに長く保存してしまったりすると、扱い方によっては余計なリスクが増える。

そこでこの構成では、Google ログインそのものと、実際にアプリを使うための権限を分けている。Google でログインしたあと、その結果をもとに短時間だけ有効な専用の利用チケットを発行し、それを使ってアプリを開く形にしている。

フロー

1. まず利用者が Google でログインする
2. ログイン結果をサーバー側に渡して、本当に正しい Google ログインかを確認する
3. 問題がなければ、短時間だけ使える専用のセッショントークンを発行する
4. そのセッショントークンを使って、埋め込みアプリを起動する

つまり、Google の認証結果をそのまま使い回すのではなく、一度サーバー側で受け止めてから、このシステム専用の短期セッションに変換している。

防御として入れているもの

• Google の認証情報を URL に載せない
• 認証情報を localStorage のような長く残る場所に保存しない
• 埋め込みアプリに渡すセッション情報も URL ではなく POST で渡す
• サーバー側で「正しい Google から来たか」「有効期限が切れていないか」「メール確認済みか」を確認する
• 許可したメールアドレスだけが使えるように制限する
• アプリ内の処理は、毎回セッション確認を通ってから実行する

特に大事なのは、「Google にログインできた」ことと、「このアプリを操作できる」ことを同じにしていない点だ。ここを分けておくと、アクセス制御や失効処理を自分たちの側で管理しやすくなる。

なぜこうしているか

埋め込み型のアプリは、表示は簡単でも認証まわりの設計が雑だと、あとで管理しづらくなる。誰が使えるのか、いつ失効するのか、ログアウトしたあとどう扱うのかを最初から分けておいた方が、あとで機能を増やしても破綻しにくい。

この仕組みでは、ログアウト時にはセッションを明示的に無効化し、期限切れを検知した場合も利用者をログイン前の状態に戻すようにしている。認証を「入るときだけ見るもの」ではなく、「使っている間ずっと管理するもの」として扱うための構成だ。