シングルサインオン（SSO）の仕組みSAML・OIDC・リバースプロキシまで

1. SSOの前に、認証・認可・セッションを理解する

認証（Authentication）は本人であることの確認、認可（Authorization）はアクセス可能な操作の決定です。SSOによって複数サービスにログインできても、各サービスで同じ権限を持つとは限りません。

ログイン後、ブラウザはCookieなどに保持されたセッション識別子を使い、毎回パスワードを送らずに操作を続けます。共通ログイン状態と各アプリ自身のセッションは別々に管理されることがあります。例えばGoogleアカウントにログイン済みでも、Googleでログインした外部サービス側では別のCookieを発行・維持します。

まず身近なサービスで区別する：どれがSSOで、どれが自動入力？

SSOを理解する近道は、普段目にするログイン画面を「誰が本人確認するか」「アプリに何が渡るか」で分類することです。ボタンの見た目が似ていても、裏側は別の仕組みです。

2. SSOの4方式を一枚で比較する

四つの方式は呼び方が似ています。特にサーバーに導入するエージェントと端末でパスワードを代理入力するエージェントは別物です。

3. 通信ラボ：5つのノードでSSOの違いを追う

同じ「ログイン後の業務アプリ利用」でも、ネットワーク上を流れる通信は変わります。各方式を切り替え、ブラウザ・代理入力エージェント・リバースプロキシ・IdP・対象アプリのどこを通信が通るか確かめてください。

プロキシとは？ 「リバース」の意味を図で理解する

「proxy（プロキシ）」は「代理」を意味します。プロキシサーバーは、クライアントと目的のサーバーの間でHTTPリクエストなどを中継する仕組みです。フォワード（forward）とリバース（reverse）は、通信の矢印が逆向きだからではなく、誰の代理として動くかが違うと覚えると整理できます。

4. リバースプロキシ方式でアクセスが集中する理由

リバースプロキシは、利用者とバックエンドの間にある入口サーバーです。利用者が portal.example.test にアクセスすると、プロキシが裏側のアプリA・アプリBにリクエストを転送します。認証も入口側で処理・確認できます。

GET /app-a/reports HTTP/1.1
Host: portal.example.test
Cookie: gateway_session=abc123

# リバースプロキシで認証状態を確認
# 内部アプリへ転送
GET /reports HTTP/1.1
Host: app-a.internal
X-Authenticated-User: alice  # 信頼境界内でのみ使用する例

HTTP/1.1 200 OK
Content-Type: application/json
{"items":[...]}

たとえばアプリAへの毎秒200リクエストとアプリBへの毎秒300リクエストがあり、すべてがプロキシを経由するなら、入口は合計で毎秒500リクエストを処理します。TLS終端、認証確認、ログ記録などの負荷も重なります。障害や帯域不足が複数アプリへ波及するため、複数台構成、ロードバランサー、ヘルスチェック、冗長ネットワーク、監視を検討します。

実務で見る4つの場面：ログイン画面の裏側

SAMLという名前を分解する：何の略で、何を表す？

SAML = Security Assertion Markup Language（セキュリティに関する主張を記述するマークアップ言語）。頭文字を順番に読むと、何を交換する技術なのかが見えてきます。

例えば「会社のMicrosoft Entra IDにログイン済み」という情報を、別会社が運営する経費精算SaaSへ伝えるとき、IdPがSAMLアサーションを発行し、SPが信頼関係・署名・宛先・期限などを検証します。アサーションはパスワードそのものでも、URL形式の利用者IDを新規発行することでもありません。

5. SAMLの基本：IdPとSPが署名付きアサーションで連携する

IdP（Identity Provider）は利用者を認証する側、SP（Service Provider）は業務アプリを提供する側です。SAML 2.0ではIdPが認証に関する主張をSAMLアサーションというXMLで表現します。例えば会社のMicrosoft Entra IDと、SAMLに対応した勤怠・経費精算などのSaaSを連携するケースを想像してください。企業IdPのログインが済むと、SaaSはIdPの署名付き証明を検証して自分のセッションを作ります。

<saml:Assertion>
  <saml:Issuer>https://idp.example.test</saml:Issuer>
  <saml:Subject>
    <saml:NameID>alice@example.test</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.test/saml</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="..."/>
</saml:Assertion>
# 形を示すための簡略例。実際には署名・宛先などの要素を検証。

SPは信頼するIdPの署名を検証し、送信先、発行者、対象受信者（Audience）、有効期間、リプレイ、InResponseToなどを確認します。単にXML内に「alice」と書いてあるからログインさせるわけではありません。

認証情報を含むSAMLアサーションは、ブラウザを経由するHTTP POSTバインディングなどでSPに渡されます。認証後の業務操作のたびにIdPへ通信する必要は通常ありません。

6. OpenID Connect（OIDC）：OAuth 2.0を土台にした本人認証

OIDCはOAuth 2.0に認証のための仕組みを加えた規格です。OAuth 2.0は主にアクセスの委任（認可）を扱い、OIDCはユーザーが誰かを示すIDトークンなどを定義します。身近な例が「Googleでログイン」です。一方、「外部アプリにGoogleドライブの閲覧権限を与える」はOAuth 2.0の委任の例です。同じGoogleの認可画面が使われても、最終的な目的を分けて考えます。

GET https://idp.example.test/authorize?
  response_type=code
  &client_id=app-client
  &redirect_uri=https%3A%2F%2Fapp.example.test%2Fcallback
  &scope=openid
  &state=random-state
  &nonce=random-nonce
  &code_challenge=...
  &code_challenge_method=S256

# 認証完了後、ブラウザがアプリへ戻る
GET /callback?code=abc123&state=random-state

# アプリのバックエンド → IdP（バックチャネル）
POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=abc123&code_verifier=...

実装ではHTTPS、登録済みredirect URI、stateによるCSRF対策、nonce、PKCEなどを利用し、IDトークンの署名・発行者・受信者・期限を正しく検証します。アプリはトークンの検証後、自身のログインセッションを発行するのが一般的です。

OAuth 2.0の具体例：写真・カレンダー・GitHub連携

OAuth 2.0は「別サービスのパスワードを渡さずに、限定された操作を許可する」仕組みです。例えばカレンダー連携アプリがGoogleカレンダーの予定を読み取る、開発ツールがGitHubのリポジトリへアクセスする、といった連携を考えると理解しやすくなります。実際の許可内容は同意画面のスコープと、サービス側の権限設定で決まります。

# OAuth 2.0：APIアクセスの例（概念図）
GET /calendar/v3/calendars/primary/events HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ACCESS_TOKEN

# OIDC：ログイン時にアプリが受け取るIDトークンとは役割が違う
# access_token → API側が利用権限を判定
# id_token     → ログイン先アプリがユーザー認証の情報を検証

7. SAML・OIDC・SSO実装方式を混同しないための整理

プロキシ型とSAML/OIDCは必ずしも排他的ではありません。例えばリバースプロキシがOIDCクライアントとしてIdPへ認証を委任し、その後のアプリ通信を中継する構成も作れます。「どこで認証を判断するか」と「どの規格でIdPと連携するか」は異なる設計軸です。

8. 実際のシステムで注意したい攻撃と運用課題

9. ありがちな説明を検証する

10. よくある質問

一次資料・公式仕様

実装時は採用製品の資料に加えて、認証連携規格の原文とセキュリティガイドを確認してください。

• Google Developers — OpenID Connect / Sign in with Google
• Okta — Secure Web Authentication integrations
• Cloudflare — Access for web applications
• Microsoft Learn — Microsoft Entra application proxy
• OASIS — SAML V2.0 Technical Overview
• OpenID Connect Core 1.0
• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7636 — Proof Key for Code Exchange
• OWASP — Authentication Cheat Sheet
• OWASP — SAML Security Cheat Sheet