社内ツールのログインを一元化する狙い
社内ツールが増えてくると、管理や利用における課題が浮上してきます。特に、ツールごとにログインが異なると、ユーザーはパスワードを頻繁に入力する手間が生じ、ツールの利用が敬遠されることも。さらに、情シスとしても管理が煩雑になりがちです。
そこで我々ACMEE情シスは、これらのバラバラなログインシステムを、Google SSO（シングルサインオン）で一元化することに挑戦しました。一度ログインすれば全ツールが利用可能な状態を作ることで、ユーザーの利便性を向上し、運用管理も効率化できるのです。
共通認証エンドポイントの設計
共通認証を実現するためには、共通のエンドポイントを設計する必要があります。具体的には、ログイン、コールバック、そして“今のユーザーは誰か”を返すブリッジを1セット用意しました。この設計により、各アプリケーションが共通エンドポイントに接続できるようになります。
セッションCookieを配下の全ツールに届くようにパスを設計し、ユーザーがどのツールにアクセスしても、同じセッションで認証が受けられる仕組みを構築しました。これにより、ユーザーエクスペリエンスの向上を目指しました。
Laravelアプリとの繋ぎ方
Laravelアプリケーションとの統合は、今回のプロジェクトの肝でした。セッションを直接読み込むのではなく、HTTPの“whoami”ブリッジを利用して現在のユーザー情報を取得する方法を採用しました。ミドルウェアでCookieを転送し、ユーザー情報を受け取ることで、アプリ側で適切なログイン状態を維持します。
また、共有サーバーの古いcURLでHTTPクライアントが500エラーになる問題に直面しました。この問題は、低レベルなcURLを用いることで回避し、無事にクリアしました。この部分は以前の記事「XserverでLaravel 11を動かす際のハマりどころ集」でも触れたミドルウェアの地雷に通じます。
ログアウトの罠と回避策
ログアウトを各アプリで自前に処理すると、共通Cookieが残り続け、“whoami”経由で再ログインしてしまうという問題が発生しました。この現象は、ユーザーがログアウトしたにも関わらず、全ツールに再度ログインされてしまう状況を生み出します。
この問題を解決するために、ログアウトは必ず共通ログアウトエンドポイントへ集約することとしました。これにより、共通Cookieも確実に削除され、完全なログアウトが実現できるようになりました。
OAuthの同意画面設定の落とし穴
Google SSOを利用する際のもう一つの罠は、OAuthの同意画面設定です。「組織内のみ」の設定にしてしまうと、許可したつもりの外部ドメインがGoogle側で弾かれてしまうという事態に陥りました。
この問題を回避するため、外部ドメインに対しても適切に許可を設定し、Googleの制約を理解した上での設定変更を行いました。これにより、外部からのアクセスもスムーズに行えるようになりました。
PWAとService Workerのキャッシュ問題
PWA（Progressive Web App）に関連する問題として、Service Workerによるキャッシュの罠がありました。特に古いリダイレクト先がキャッシュに残り続けることで、リダイレクトが期待通りに動作しないという問題が発生しました。
この問題に対する対策としては、Service Workerのキャッシュクリアを適切に行い、キャッシュ戦略を見直すことで、ユーザーが常に最新のリダイレクト先にアクセスできるようにしました。
認証要求オプションの設定ミス
最後に、認証要求のオプション指定のミスによるトラブルについてです。毎回アカウント選択を求めるオプションを誤って設定すると、未ログインやシークレットモードで即エラーになることがあります。
このミスは、オプション設定の見直しによって解決しました。ユーザーの状況に応じた認証フローを設計することで、エラーの発生を未然に防ぐことが可能です。
