SSOと認証設計

約5分

HTTPとWebアプリケーションの基礎を理解している方

シングルサインオン（SSO: Single Sign-On）とは、1回の認証で複数のサービスやアプリケーションにアクセスできる仕組みです。エンタープライズ環境では従業員が数十のシステムを使うため、SSOは運用コスト削減とセキュリティ強化の両面で不可欠な技術です。

なぜSSOが必要か

従業員がSlack・Salesforce・GitHub・Jiraなど10〜30のSaaSを使う環境では、それぞれに個別のパスワードを管理すると以下の問題が生じます。

パスワードの使い回し・脆弱なパスワードの増加
退職者アカウントの削除漏れによるセキュリティリスク
ヘルプデスクへの「パスワードを忘れた」問い合わせコスト

SSOでは1つのアイデンティティプロバイダー（IdP: Identity Provider）に認証を集約し、各サービス（SP: Service Provider）への認証をIdPが保証します。

主要な認証プロトコル

OAuth 2.0

OAuth 2.0とは、あるサービスが別のサービスのリソースにアクセスする際の「認可」フレームワークです。「認可（authorization）」は「何をしてよいか」を決める仕組みで、「認証（authentication）」の「誰であるか」とは異なります。

主なフロー:

フロー名	用途	特徴
認可コードフロー	Webアプリ	最も安全・推奨
クライアントクレデンシャルフロー	サーバー間通信	ユーザー不在のAPI連携
デバイスフロー	TVなどの入力制限デバイス	別デバイスで認証

OIDC（OpenID Connect）

OIDC（OpenID Connect）とは、OAuth 2.0の上に「認証」レイヤーを追加した仕様です。OAuth 2.0が認可のみを扱うのに対し、OIDCはIDトークン（JSON Web Token形式）を発行することで「誰が認証したか」を証明します。

現代のSSOシステムではOIDCが標準的に採用されています。

SAML 2.0

SAML（Security Assertion Markup Language）2.0は、XMLベースの認証・認可仕様です。2005年策定の古い規格ですが、大企業のオンプレミスシステムやレガシーSaaSで広く使われています。OktaやMicrosoft Entra ID（旧Azure AD）はSAMLを完全サポートしています。

OIDCの認証フロー

sequenceDiagram
    participant U as ユーザー
    participant App as アプリ（SP）
    participant IdP as アイデンティティプロバイダー

    U->>App: アクセス
    App->>U: IdPへリダイレクト
    U->>IdP: ログイン（ID/パスワード or MFA）
    IdP->>App: 認可コードを返却
    App->>IdP: 認可コード → アクセストークン + IDトークン交換
    IdP->>App: トークン発行
    App->>U: ログイン完了・セッション確立

OAuth 2.0 vs OIDC vs SAML 比較

比較項目	OAuth 2.0	OIDC	SAML 2.0
目的	認可（リソースアクセス）	認証＋認可	認証＋認可
データ形式	JSON	JWT（JSON）	XML
策定年	2012年	2014年	2005年
モバイル対応	良好	良好	困難
エンタープライズ普及	高い	高い（増加中）	非常に高い
実装の複雑さ	低〜中	低〜中	高い

JWTトークンの構造

JWT（JSON Web Token）は、OIDC・OAuthで使われるトークン形式です。3つの部分をドット（.）で結合したBase64URL文字列で構成されます。

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.signature
      ↑ ヘッダー           ↑ ペイロード         ↑ 署名

ペイロードには以下のようなクレームが含まれます。

{
  "sub": "user123",
  "email": "alice@example.com",
  "exp": 1747123456,
  "iat": 1747119856,
  "iss": "https://auth.example.com"
}

exp（有効期限）を必ず検証し、期限切れトークンを拒否する実装が必要です。

AIシステムへのSSO適用

Claude APIやOpenAI APIなどのLLMサービスをエンタープライズ環境に導入する場合、以下の設計が推奨されます。

APIゲートウェイにSSOを適用: ユーザーはSSOでゲートウェイにアクセスし、ゲートウェイがLLM APIを呼び出す
サービスアカウントのスコープ制限: AIサービス用のサービスアカウントには必要最小限の権限のみ付与
トークンの伝播: JWTのクレームをAIサービスに伝播させ、ユーザー属性に基づいたアクセス制御を実現

セッション管理

項目	推奨設定
アクセストークン有効期限	15〜60分
リフレッシュトークン有効期限	1〜30日
セッションタイムアウト（無操作）	30〜60分
ログアウト	IdP側でもセッションを無効化（Single Logout）

主要エンタープライズIdP

IdP	特徴	対応プロトコル
Okta	SaaS特化・豊富なインテグレーション	OIDC・SAML・OAuth 2.0
Microsoft Entra ID	Microsoft製品との親和性	OIDC・SAML・OAuth 2.0
Google Workspace	Google製品連携	OIDC・SAML
Auth0（Okta傘下）	開発者向け・カスタマイズ性高い	OIDC・SAML・OAuth 2.0

よくある実装ミス

トークンをlocalStorageに保存する: XSS攻撃でトークンが盗まれるリスクがある。httpOnly Cookieに保存する
トークンの有効期限を検証しない: 期限切れトークンを受け入れてしまう
IDトークンをAPIアクセストークンとして使う: IDトークンは認証用途のみ。APIアクセスにはアクセストークンを使う
Single Logoutを実装しない: IdPでログアウトしてもSP側のセッションが残る

よくある質問

Q: SAMLとOIDC、どちらを選ぶべきですか？

新規システムにはOIDCを推奨します。OIDCはJSON/JWTベースでモバイル・SPA対応が容易です。既存のSAMLをサポートするレガシーシステムとの連携が必要な場合はSAMLを選択します。両プロトコルをサポートするIdP（Okta・Microsoft Entra IDなど）を使うと、将来の移行が容易になります。

Q: SSOをローカル開発環境でテストするにはどうすればよいですか？

Keycloakをローカルで起動する方法が一般的です。Dockerで起動できます（docker run -p 8080:8080 quay.io/keycloak/keycloak:latest start-dev）。OktaやAuth0は無料のDeveloper Editionを提供しており、開発・テスト用途で利用できます。

Q: MFA（多要素認証）はSSOでどう組み合わせますか？

MFAはIdP側で実装します。SAMLやOIDCのフロー内でIdPがMFAを要求するため、各サービス（SP）に個別にMFAを実装する必要はありません。これがSSOとMFAを組み合わせる主要なメリットの一つです。

参考文献

GitHub, GitHub Docs
NIST, AI Risk Management Framework

クイズ

権限管理とRBAC

エンタープライズ統合とは