スケーラブルな認証システム-セントラル認証について-

# ポートフォリオサイトにセントラル認証を導入した

最近、複数のWebアプリケーションを開発する中で、避けて通れないのが「認証」の管理です。今回は、自身のポートフォリオサイトにおいて**「セントラル認証方式」**を採用した背景と、その仕組みについて解説します。

## なぜセントラル認証なのか？

結論から言うと、**「今後作るであろう複数のアプリケーションの認証を一元管理したいから」**です。

アプリごとに認証機能を作り込み、ユーザーテーブルをバラバラに管理するのは保守面で非効率です。将来的に「ブログ」「ポートフォリオ」「ツール」といった複数のプロダクトを展開した際、どのサービスにアクセスしても一度のログインで済む体験（SSO：シングルサインオン）を提供したいと考えました。

## セントラル認証の仕組み

セントラル認証とは、認証専用のアプリケーション（認証サーバー）を一つ立て、他のアプリはそこに認証を委譲する仕組みです。

1. ユーザーがアプリAにアクセス

2. ログイン状態を確認：認証されていない場合、認証サーバーのログイン画面へリダイレクト

3. 認証実行：認証サーバーでユーザーがログイン

4. セッション確立：認証済みトークンを発行し、元のアプリAへリダイレクト

5. 完了：アプリA側でセッションが有効になり、利用可能に

この構成により、アプリBにアクセスした際も、既に認証サーバーでセッションが有効であれば再ログインなしで利用可能になります。

## サブドメイン戦略：クッキー共有の偉大さ

この構成を実現する上で鍵となるのが「サブドメイン」の活用です。

通常、Cookieはドメインが異なると共有できません。しかし、同じルートドメインを持つサブドメイン同士であれば、Cookieのスコープをルートドメインに設定することで、値を共有することができます。

*auth.matsuda-tech.com**（認証ページ）

この仕組みのおかげで、認証サーバーでセットした認証Cookieを各アプリから直接参照・検証できるため、複雑なトークン受け渡しを最小限に抑えることができています。

---

## 運用とセキュリティにおける課題

最後に、この構成を運用する上で意識している点を紹介します。

*セキュリティ対策**：Cookieには`HttpOnly`、`Secure`属性を必須とし、`SameSite`属性を適切に設定してCSRF攻撃を防いでいます。

*トークン検証の徹底**：Cookieの共有だけでなく、サーバーサイドで署名付きのJWT（JSON Web Token）を検証することで、データの改ざんを防ぐ設計にしています。

*ログアウトの同期**：Cookieを共有しているため、一箇所のログアウトですべてのサービスから無効化させる仕組み（または認証サーバー側のセッション破棄）を徹底する必要があります。

今後も、この認証基盤をベースに新しいアプリケーションを快適に追加していこうと思います。