2026.07.28 セキュリティ

シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定を実装手順で解説

シングルサインオンは、1回の認証で複数サービスへ入れるようにする仕組みです。ただし製品を入れれば終わりという話ではなく、どの方式で連携するか、SP側で何を検証するか、セッションとアカウントをどう失効させるかまで設計して初めて狙った効果が出ます。この記事では仕組みの定義から、SAMLとOIDCの検証実装、手元で動かせる確認手順、内製とIDaaSの判断軸までを開発視点でまとめました。

まとめ｜シングルサインオンの仕組みと導入判断の要点

シングルサインオンは、各サービスが個別に持っていた認証機能を1か所のIdP（Identity Provider・認証を担う側）へ寄せ、各サービス（SP・Service Provider）はIdPが発行した認証結果を検証して信頼する、という構造で成り立ちます。パスワードを複数サービスへ同じ値で配る「パスワード同期」とは別物で、SSOではSP側がパスワードを持たない点が本質的な違いです。

実装で押さえる軸は4つあります。1つ目は実現方式の選択で、SaaSや自社Webが相手ならSAML 2.0とOIDCによるフェデレーション方式が標準形になり、非対応の既存システムには代理認証・エージェント・リバースプロキシを当てます。2つ目は署名とトークンの検証で、SAMLならXML署名とアサーションの妥当性、OIDCならIDトークンの検証項目と鍵のローテーション追随が要点。3つ目がセッション設計で、IdPとSPが二重にセッションを持つため、ログアウトが全サービスに届かない問題を運用の前提として織り込みます。4つ目がアカウント連携で、退職者の権限をSP側から確実に消せるかどうかがSSOの価値を左右する点。判断の分岐点は「連携先がSSO標準に対応しているか」と「ID情報を握る主体が誰か」で、SaaS中心ならIDaaSの標準機能で組み切れる一方、自社サービスの会員基盤を自前で持つ場合は設計から固める価値が出ます。

本文では仕様の記述ごとに出典へ当たれるようにしてあります。SAML 2.0はOASISのAssertions and Protocols for the OASIS SAML V2.0（OASIS Standard・2005年3月15日付）が原文で、OpenID ConnectはOpenID Connect Core 1.0 incorporating errata set 2（2023年12月15日付・2026年9月時点で最新のFinal）が原文です。全体像から整理したい場合は認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を先に読むと位置づけが掴めます。AWSアカウントへのSSOを具体化する実装はAWS IAM Identity Centerの権限セットとCLI認証で扱っています。

シングルサインオンとは｜IdPに認証を集約しSPが結果を信頼する構造

最初に言葉の定義と、混同されやすい仕組みとの違いを整理します。ここを曖昧にしたまま製品選定に入ると、要件と方式がずれたまま構築が進みます。

シングルサインオンの定義とパスワード同期・パスワード管理との違い

シングルサインオン（Single Sign-On・SSO）とは、利用者が1回認証を通せば、連携済みの複数サービスへ改めて資格情報を入力せずにアクセスできる仕組みを指します。核心は「認証の実行主体を1か所に集約する」ことにあり、各サービスは自分で本人確認をせず、集約先が出した認証結果を検証して受け入れます。

よく混同されるのがパスワード同期とパスワード管理ツールです。パスワード同期は複数システムへ同じパスワードを配って揃える運用、パスワード管理ツールは保管した資格情報を画面へ自動入力する仕組みで、どちらも各システム側の認証機能とパスワードはそのまま残ります。対してSSOでは連携先がパスワードを持たないため、退職時にIdPのアカウントを止めれば連携先すべてが同時に使えなくなる構造。この「止めれば全部止まる」という性質が、実装コストを払ってSSOにする最大の理由です。

認証と認可を分ける考え方とIdP・SP・アサーションの役割分担

SSOの設計では、認証（誰であるかの確認）と認可（何をしてよいかの決定）を分けて考えます。IdPが担うのは認証で、利用者のパスワードや多要素認証を検証し、その結果を署名付きのデータとして発行する役目です。SPは受け取った認証結果を検証して「確かにIdPが本人と認めた」と判断し、そこから先の権限判定は自分で行います。IdPが渡すのはあくまで本人性と属性であり、SP内部の細かい権限まではIdPが決めないのが原則的な役割分担です。

この受け渡されるデータを、SAMLではアサーション、OIDCではIDトークンと呼びます。いずれも署名が付いており、SPは署名の検証で内容の改ざんと発行元のなりすましを防ぐ仕組み。認可の側の土台はRFC 6749（The OAuth 2.0 Authorization Framework）にあり、OIDCはこの上へ本人確認の層を重ねた仕様として定義されています。認証と認可の境界を整理したい場合はOAuth 2.0とは？仕組み・認可フローと認証・認可の違いを参照すると、SSOで扱う範囲がどこまでかを切り分けやすくなります。

SSOを実現する4方式｜フェデレーション・代理認証・エージェント・リバースプロキシ

SSOは単一の技術ではなく、連携先の性質に応じて実現方式を選びます。相手が標準プロトコルに対応しているかで、選べる方式が決まる構造です。

方式 実現手段 向く連携先
フェデレーション SAML 2.0・OIDC SaaS・自社Webアプリ
代理認証 資格情報の代行入力 SSO非対応の既存画面
エージェント サーバー常駐モジュール オンプレのWebアプリ
リバースプロキシ 通信経路上で認証を挟む 改修できない社内系

フェデレーション方式＝SAML・OIDCで認証結果を受け渡す標準形

フェデレーション方式は、IdPとSPが標準プロトコルで認証結果をやり取りする形で、現在のSSOの中心にある方式です。企業向けSaaSの多くはSAML 2.0に対応しており、OASISが標準化したXMLベースの仕様で、IdPが署名付きアサーションを発行しSPが検証します。ブラウザを介した受け渡しの型はProfiles for the OASIS SAML V2.0のWeb Browser SSO Profileに定義があり、SP-InitiatedとIdP-Initiatedの両方がここで規定されています。一方のOpenID Connectは、OAuth 2.0の認可フローの上に本人確認の層を重ねた仕様で、原文ではCore 1.0が errata set 2 を取り込んだ版として2023年12月15日付で示されています（2026年9月時点）。

2つの使い分けは、連携先の対応状況で決まる部分が大きいのが実情です。既存の企業向けSaaS連携ではSAMLが求められる場面が多く、自社で新規にモバイルアプリやSPAを含む認証基盤を組むならOIDCのほうが実装しやすい傾向にあります。どちらも「IdPへリダイレクトして認証し、署名付きの結果を持ち帰る」という骨格は共通しており、片方を理解すればもう片方の理解も進む構造。プロトコル単位の詳細はSAMLとは？認証フロー・IdP/SPの仕組みとOIDC（OpenID Connect）とは？仕組み・OAuthとの違いで確認できます。なお社内ネットワーク限定であれば、Windowsドメインの統合Windows認証が使うRFC 4120（The Kerberos Network Authentication Service V5）のチケットも、事実上のSSOとして機能します。

代理認証・エージェント・リバースプロキシ方式が向く既存システム

問題になるのは、SAMLにもOIDCにも対応していない既存システムです。ここで残り3方式が出てきます。代理認証方式は、利用者に代わってエージェントソフトやブラウザ拡張が保管済みの資格情報をログイン画面へ入力する方式です。対象システムを一切改修せずに済む反面、内部的にはパスワードが残るため「止めれば全部止まる」という利点は弱まります。

エージェント方式は、対象のWebサーバーへモジュールを常駐させ、それがSSOサーバーへ問い合わせて認証状態を判定します。対象サーバーへ手を入れられる社内システムで有効な一方、ミドルウェアのバージョンに依存するため、対象が増えるほど保守の負担が積み上がる方式。リバースプロキシ方式は対象システムの手前にプロキシを置いて通信経路上で認証を挟む構成で、アプリ側を改修できない場合に採れますが、全通信がプロキシを通るため性能と可用性の設計をプロキシ側で引き受けます。いずれも標準プロトコル対応への移行までの過渡的な選択と捉えておくと、判断を誤りません。

SAMLとOIDCの実装差｜アサーション検証とトークン検証の要点

フェデレーション方式を採ると決めたら、次はSP側の検証実装が焦点になります。組織をまたいで信頼を結ぶ側の設計はフェデレーション認証のIdPとSPの信頼設計と属性連携で個別に整理した内容です。SSOの事故の多くは、この検証の抜けから起きます。

SAMLの実装で外せない署名検証とIdP-Initiatedの注意点

SAMLのSP実装で最初に固めるのは、アサーションのXML署名検証です。IdPの公開鍵で署名を確かめ、宛先（Audience）が自分であること、有効期間内であること、同じアサーションを二度受け付けないことを、いずれも省かずに確認します。署名そのものの構造はW3CのXML Signature Syntax and Processing Version 1.1に定義があり、参照する要素と署名した要素が一致しているかを処理側が確かめる前提で設計されています。ここを自前で書くと踏みやすいのがXML Signature Wrapping、つまり署名が付いた要素と実際に読み取る要素をずらされる手口。署名検証は実績のあるライブラリやIdP製品側の実装に寄せるのが現実的な判断です。

もう1つの注意点がIdP-Initiated SSOです。SPからの要求に紐づかない形でアサーションが送り込まれるため、要求と応答を対応付ける検証が働かず、すり替えや再送の余地が生まれます。要件が許すならSP-Initiatedに寄せ、IdP-Initiatedを開ける場合は受信後の遷移先を限定するなどの補強が必要です。Okta developerのSAML解説でも、SP-Initiatedを既定にしてIdP-Initiatedは必要な場合に限る整理になっています。IdPの署名鍵そのものが漏れれば任意のアサーションを偽造できてしまう（いわゆるGolden SAML）ため、鍵の保護と定期的な入れ替えも設計に含める前提です。

OIDCの実装で確認するIDトークン検証とJWKSの鍵ローテーション

OIDCではIDトークン（JWT形式）の検証が中心になります。確認するのは、発行者（iss）が想定したIdPであること、宛先（aud）が自分のクライアントIDであること、有効期限（exp）が切れていないこと、認可要求時に渡したnonceが一致することです。検証項目の並びはCore 1.0の3.1.3.7節に列挙があり、Microsoft EntraのIDトークンのドキュメントでも同じ観点が実装者向けに整理されています。nonceの照合を省くとトークンの使い回しを見抜けなくなるため、実装を急ぐ場面でも落とせない項目になります。

運用で効いてくるのがJWKS（JSON Web Key Set）の扱いです。鍵の表現そのものはRFC 7517（JSON Web Key）で定義されており、IdPは署名鍵を定期的に入れ替えるため、SP側は鍵の一覧をキャッシュしつつ未知の鍵ID（kid）を見たら取り直す作りにしておきます。鍵一覧を起動時に一度だけ読んで固定する実装は、IdPの鍵交換のタイミングで全ログインが止まる典型的な事故に直結する構造。トークン検証の詳細はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いで確認できます。

SSO連携を手元で動かす手順｜Discovery取得からIDトークン検証まで

ここからは読みながら手を動かせる形にします。IdPのテナントを1つ用意すれば、以下はローカルから順に実行できます。設定値を推測で埋めるのをやめ、IdPが公開している値をそのまま取得するのが出発点です。

IdPのDiscovery文書とJWKSをcurlで取得して設定値を固める

OIDCのIdPは、エンドポイントの一覧を1つのJSONで公開します。この仕組みはOpenID Connect Discovery 1.0で定義され、発行者URLの末尾に .well-known/openid-configuration を付けたパスから取得する決まりです。まずここを取り、issuerとjwks_uriを控えます。

# 1) Discovery文書を取得し、SP側に設定すべき値だけを抜き出す
curl -s https://example.okta.com/.well-known/openid-configuration \
  | jq '.issuer, .jwks_uri, .authorization_endpoint, .token_endpoint, .end_session_endpoint'

# 2) 署名鍵の一覧を取得し、kid と alg を控える（IdPが鍵を複数持つ場合もある）
curl -s https://example.okta.com/oauth2/default/v1/keys \
  | jq '.keys[] | .kid, .alg, .kty'

ここで得たissuerの文字列は、後段の検証でそのまま突き合わせる値になります。末尾スラッシュの有無まで含めて一致させる必要があるため、ドキュメントに書かれた例ではなく実際に返ってきた値を使ってください。end_session_endpointが返らないIdPは、後述するRP-Initiated Logoutに対応していないと判断できます。

IDトークン検証をPyJWTで書くときに落とせない引数の指定方法

検証コードは、ライブラリ任せにしても引数の指定を誤ると素通りします。PythonではPyJWTの公式ドキュメントにJWKS取得込みの書き方があり、2026年9月時点の配布版は2.13系です。次の形で、algの固定・audとissの突き合わせ・nonceの照合までを1か所に閉じ込めます。

# pip install "pyjwt[crypto]" （2.13系・2026年9月時点）
import jwt
from jwt import PyJWKClient

ISSUER    = "https://example.okta.com"
CLIENT_ID = "0oa1example"
JWKS_URL  = ISSUER + "/oauth2/default/v1/keys"

# kid ごとの鍵をキャッシュし、未知の kid を見たら取り直す
jwk_client = PyJWKClient(JWKS_URL, cache_keys=True, lifespan=600)

def verify_id_token(id_token, expected_nonce):
    signing_key = jwk_client.get_signing_key_from_jwt(id_token)
    claims = jwt.decode(
        id_token,
        signing_key.key,
        algorithms=["RS256"],   # alg は固定する。none を許可しない
        audience=CLIENT_ID,     # aud が自分のクライアントIDか
        issuer=ISSUER,          # iss が Discovery で得た値と一致するか
        options={"require": ["exp", "iat", "aud", "iss"]},
    )
    if claims.get("nonce") != expected_nonce:
        raise ValueError("nonce mismatch")   # 照合失敗はログイン失敗として扱う
    return claims

algorithmsを指定しない書き方は、トークン側が申告したalgを信じる挙動につながり、署名なしトークンを通す事故の入口になります。audienceとissuerを渡さない書き方も同様で、他社テナント向けに発行されたトークンを受け入れてしまいます。nonceはライブラリの検証対象外なので、上のコードのようにアプリ側で必ず突き合わせてください。

SAML側の設定はstrictと署名要求のフラグから確認する

SAMLをPythonで実装する場合、SAML-Toolkits/python3-samlのように設定ファイルで検証の厳格さを切り替えるライブラリが一般的です。動作確認では、まず次のフラグが立っているかだけを見ます。ここが緩いまま本番へ出るのが、SSO実装で最も多い設定事故です。

{
  "strict": true,
  "sp": {
    "entityId": "https://app.example.co.jp/metadata",
    "assertionConsumerService": {
      "url": "https://app.example.co.jp/acs",
      "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    }
  },
  "security": {
    "wantAssertionsSigned": true,
    "wantMessagesSigned": true,
    "wantNameIdEncrypted": false,
    "rejectUnsolicitedResponsesWithInResponseTo": true,
    "requestedAuthnContext": true
  }
}

strictがfalseだと有効期限や宛先の不一致を無視して通してしまうため、開発中も含めてtrueで動かします。rejectUnsolicitedResponsesWithInResponseToをtrueにすると、SPからの要求に紐づかないアサーション、つまりIdP-Initiatedの受け入れを閉じられます。IdP-Initiatedを使う要件がないなら、この時点で塞いでおくのが安全側の設計です。

SSOのセッション設計｜多重セッションとシングルログアウトの落とし穴

プロトコルの検証が正しく書けても、セッション設計を詰めていないとSSOは運用で崩れます。原因は、セッションが1つではなく複数存在する点にあります。

IdPとSPで二重に持つセッションの寿命と失効をどう設計するか

SSOでは、IdP側に「この利用者は認証済み」というセッションが立ち、各SP側にも「ログイン済み」というセッションが別々に立ちます。SPのセッションはSSO成立後は独立して生き続けるため、IdP側で状態が変わってもSP側は気づきません。結果として、IdPでアカウントを停止したのにSPのセッションが有効なまま残る、という状態が生じます。

設計では、SP側セッションの寿命をIdP側より短く取り、期限切れのたびにIdPへ確認を戻す形が基本になります。加えて、権限の変更や停止が即座に効いてほしい操作（決済、個人情報の閲覧、管理機能など）では、セッションに頼らずその都度IdPやディレクトリへ状態を問い合わせる設計にしてください。トークンの寿命と失効の考え方はRFC 9700（Best Current Practice for OAuth 2.0 Security・2025年1月）が現行のベストプラクティスを示しており、暗黙的フローの非推奨やリダイレクトURIの厳密一致など、SSOの土台にも効く指針が並びます。社内ディレクトリと連携する場合の仕組みはLDAPとは？ディレクトリサービスの仕組みとActive Directory・認証連携で整理できます。

シングルログアウトが機能しにくい理由と、現実的な失効設計の指針

「1回のログアウトで全サービスから抜ける」というシングルログアウトは、仕様としては存在します。SAMLにはSingle Logout（SLO）プロファイルがProfiles仕様に定義され、OIDC側にもRP-Initiated Logout 1.0、Front-Channel Logout 1.0、Back-Channel Logout 1.0といった仕様が用意されている状況です（RP-InitiatedとFront-Channelは2022年9月12日付、Back-Channelはerrata set 1を取り込んだ2023年12月15日付で、いずれも2026年9月時点のFinal）。それでも実運用で完全には効きません。理由は単純で、連携先のSPすべてが同じ仕様に対応していないと、対応していないSPのセッションだけが残るからです。Front-Channel方式は各SPへのログアウト通知を隠しフレーム経由で行うため、サードパーティCookie制限が絡む環境では通知そのものが届かない場合もあります。

現実的な指針は、シングルログアウトを唯一の失効手段にしないことです。退職や事故対応での即時遮断は、IdP側のアカウント停止とセッション取り消し、そしてSP側の短いセッション寿命という二段構えが必要です。Back-Channel Logoutに対応できるSPだけでも通知を受ける構成にしておくと、ブラウザの制限に左右されずに失効を届けられます。そのうえで、対応しないSPは「セッション寿命が切れるまでは残る」という前提を運用ルールとして明文化しておく形が実務に合います。

SSOのアカウント連携｜SCIMプロビジョニングとJIT作成の使い分け

SSOはログインの仕組みですが、価値を出すのはアカウントのライフサイクル管理と組み合わせたときです。ここが抜けると、入社時の手作業と退職者アカウントの残存という元の課題が解けません。

SCIM 2.0による自動プロビジョニングと退職時アカウントの即時失効

SCIM（System for Cross-domain Identity Management）は、IdP側のID情報をSP側へ自動反映するための仕様で、RFC 7643がコアスキーマを、RFC 7644がプロトコルを定めています。IdPで入社処理をすれば連携先SaaSにアカウントが作られ、退職処理をすれば停止される、という連動をAPI経由で成立させる仕組み。SSOだけを入れた状態ではSP側にアカウントが残るため、SP側へ直接ログインする経路や発行済みのAPIトークンが生き残る余地が残ります。

停止の実体は、Userリソースのactive属性をfalseへ書き換えるPATCH要求です。SP側にSCIMエンドポイントを実装するときも、IdP側の挙動を確かめるときも、まずこの1本が通るかを見ます。

# 退職者のアカウントをSP側で即時無効化する（RFC 7644 の PatchOp）
curl -s -X PATCH "https://api.example-saas.com/scim/v2/Users/2819c223-7f76-453a" \
  -H "Authorization: Bearer $SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
      { "op": "replace", "path": "active", "value": false }
    ]
  }'

退職時の即時失効を要件に掲げるなら、SSOとSCIMは組で導入すると考えたほうが設計を誤りません。連携先SaaSのSCIM対応は製品とプラン次第で差が出るため、対応範囲（作成・更新・停止・グループ同期のどこまでか）は選定段階での個別確認が必要です。IdP側の実装が仕様のどこまでを使うかはMicrosoft EntraのSCIMプロビジョニング解説に一覧があり、SP側で実装すべきエンドポイントの当たりを付けられます。SCIMの仕様そのものと、SP側にエンドポイントを実装する範囲はSCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説で整理しています。

JITプロビジョニングで足りる場面と、属性設計で詰まりやすい場面

SCIMに対応していないSPでは、JIT（Just-In-Time）プロビジョニングという選択肢があります。初回のSSOログイン時に、アサーションやIDトークンに載った属性を使ってSP側のアカウントをその場で作る方式で、事前の一括登録が不要になる利点。小規模な連携や、利用者が自分で使い始めるツールでは十分に回ります。

詰まりやすいのは属性設計と退職時の扱いです。JITは作成には効きますが停止や削除は原則として扱えないため、退職者アカウントはSP側に残ります。加えて、SP側が求める属性（メールアドレス、氏名、部署、ロール）の渡し方を決めておかないと、後からロール設計を変えたときに全連携先の属性マッピングを見直す羽目に。IdP側で「渡す属性の標準セット」を先に決め、SP追加のたびにその写像だけを定義する形にしておくと、連携先が増えても設計が破綻しません。

SSOがつながらないときの切り分け｜エラー別に見る確認箇所と対処

SSOの不具合は、ブラウザ画面のメッセージだけでは原因が絞れません。IdP側のログ、SP側の検証コード、設定値の3か所を順に当たると短時間で切り分けられます。ここでは頻出のエラーごとに、どこを見るかを並べます。

SAMLでAudience不一致や署名エラーが出るときの確認順序

Audienceの不一致は、SP側のentityIdとIdP側に登録したAudience URIが文字列として一致していないときに出ます。末尾スラッシュ、httpとhttps、ホスト名の大文字小文字がよくある差分です。次に見るのは受信URL（Assertion Consumer Service URL）で、IdPの登録値とSPの実際の受け口が別のパスになっていると、宛先検証で弾かれます。

署名エラーが出る場合は、IdPのメタデータに含まれる証明書とSP側が保持している証明書が同じものかを確かめます。IdPが証明書を入れ替えた直後は、SP側が古い証明書のままになっているのが典型です。時刻ずれもここに入り、NotBeforeやNotOnOrAfterの判定はサーバー時刻に依存するため、NTP同期が切れている環境では有効期限内のアサーションが弾かれます。IdP製品側の設定項目の意味はKeycloakの管理者向けドキュメントのように、実装のあるIdPのdocsで用語ごとに確かめるのが早道です。

OIDCでnonce不一致やトークン期限切れが出るときの確認順序

nonceの不一致は、認可要求時にセッションへ保存したnonceと、IDトークンのnonceクレームが揃っていないときに起きます。ロードバランサ配下でセッションが別インスタンスに載ると再現するため、セッションストアが共有されているかを先に確認してください。stateについても同じ構造の不具合が出ます。

トークン期限切れが頻発する場合は、サーバー時刻とIdP側の時刻のずれを疑います。expの判定は秒単位なので、数十秒のずれでも発行直後のトークンが期限切れ扱いになります。鍵が見つからない旨のエラーは、JWKSのキャッシュが古く新しいkidを解決できていない状態で、キャッシュの生存時間と再取得の実装を確認する場面です。認可要求そのものが弾かれる場合は、リダイレクトURIの完全一致とスコープにopenidが含まれているかを見ます。

シングルサインオンを内製するかIDaaSで組むかの判断軸と外注が向く局面

ここからは判断を言い切る形です。SSOは、連携先が標準プロトコルに対応した社内向けSaaS群であればIDaaSの標準機能で組み切れますが、自社サービスの会員基盤や既存システムが絡むと設計の巧拙が結果を分けます。会員基盤の側から認証を設計する場合は、CIAMの定義と顧客ID正本の置き方を先に押さえると判断が早くなります。

IDaaSの標準機能で組み切れるSSO要件と、採用してよい条件

次の条件に収まるなら、IDaaSを採用して標準機能で組むのが速く、保守も軽く済みます。連携先が主に企業向けSaaSで、いずれもSAMLかOIDCに対応していること。利用者が自社の従業員に限られ、権限設計がSP側の標準ロールで足りることです。この範囲であれば、署名検証も鍵のローテーションもSCIM連携もIDaaS側の機能で賄え、自社で書くコードはほぼ設定作業に収まります。

製品選定では、既存の社内ディレクトリとの相性、連携したいSaaSのコネクタの有無、多要素認証の方式が要件を満たすかを見ます。IDaaSというサービス類型そのものの責務範囲と、自社アプリを寄せるときの改修範囲はIDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携で整理しました。オープンソースで自社運用したい場合はKeycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較が、商用IDaaSの機能と費用感を掴みたい場合はOkta（オクタ）とは？認証の仕組み・機能・料金・セキュリティが判断材料になります。適用イメージはGitHub SSOの設定手順｜SAML連携・PAT/SSH認可の落とし穴が具体的です。なおIdPの資格情報が奪われれば連携先すべてが同時に破られるため、多要素認証（MFA）とは？3つの認証要素と実装方式で扱う耐フィッシング性の高い方式との併用を前提条件に置いてください。

SSOの導入を見送る場面と、受託開発で設計を固めるべき認証要件

逆に、SSOを急いで入れないほうがよい場面もあります。連携したいシステムが1つか2つしかなく、いずれも標準プロトコルに非対応で代理認証しか採れない場合、パスワードが各システムに残るため「止めれば全部止まる」という本来の効果が出ません。この状態では、対象システムの標準対応やクラウド移行を先に検討したほうが投資が無駄になりません。IdPの冗長化と障害時の回避手段を用意できない体制も、導入を前倒しすべきではない条件です。

一方、次の要件が絡む場合は、初期の設計品質がその後の安全性と拡張性を決めるため、認証基盤の設計経験がある体制で固める価値が出ます。自社サービスの会員基盤にSSOを組み込み、外部IdPとの連携と自前の認証を併存させる構成。オンプレの基幹システムとクラウドをまたいでID情報を1つに束ねる構成。取引先や利用企業ごとにIdPを切り替えるマルチテナントの認証などです。顧客企業ごとのSSO接続とSCIM連携を製品側へ寄せる選択肢はWorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤で整理しています。これらはセッションと失効、属性設計、テナント分離が密に絡み、後から作り替えると全連携先の再設定を伴います。会員基盤と一体で認証を設計する開発は会員管理システムの受託開発で構想段階から相談でき、IDaaSの標準機能で走り出しつつ難所だけ外部の設計を挟む進め方も現実的です。

シングルサインオンでよくある質問｜仕組み・安全性・実装の疑問に回答

SSOの検討でよく挙がる質問に、仕組み・安全性・実装の観点から答えます。

シングルサインオンとパスワード管理ツールは何が違うのですか？

認証を行う場所が違います。パスワード管理ツールは、保管しておいた資格情報を各サービスのログイン画面へ自動入力する仕組みで、各サービス側の認証機能とパスワードはそのまま残ります。SSOでは連携先がパスワードを持たず、IdPが出した認証結果を検証して受け入れる構造です。この違いから、IdPのアカウントを停止すれば連携先すべてが同時に使えなくなります。

SSOはSAMLとOIDCのどちらを選べばよいですか？

連携先の対応状況で決まる部分が大きいのが実情です。既存の企業向けSaaSを束ねる用途ではSAML 2.0が求められる場面が多く、自社で新しく認証基盤を組むならOIDCのほうが実装しやすい傾向にあります。両方を扱えるIdPを選び、連携先ごとに使い分ける構成が無難です。

シングルサインオンのデメリットは何ですか？

最大の論点はIdPが単一障害点になることです。IdPが停止すれば連携先すべてにログインできなくなり、IdPの資格情報が奪われれば連携先すべてが同時に破られます。前者への備えはIdPの可用性設計と緊急時の代替経路、後者への備えは耐フィッシング性の高い多要素認証です。加えて、連携先が増えるほど属性とロールの写像を保守する手間が積み上がる点も、運用計画に織り込んでおく必要があります。

SSOを入れればログアウトも全サービスで同時に効きますか？

完全には効きません。SAMLのSingle LogoutやOIDCのログアウト関連仕様は存在しますが、連携先すべてが同じ仕様に対応していないと、対応していないサービスのセッションだけが残ります。実務では、シングルログアウトを唯一の手段にせず、IdP側でのアカウント停止とセッション取り消し、そしてSP側の短いセッション寿命を組み合わせて即時遮断を担保する設計にします。

SSOだけ導入すれば退職者のアカウントは消えますか？

消えません。SSOはログインの経路を止めるだけで、SP側のアカウント自体は残ります。SP側へ直接ログインする経路や発行済みのAPIトークンが生きていれば、アクセスが継続する余地も。退職時の確実な失効を要件にするなら、SCIM 2.0による自動プロビジョニングを組み合わせ、IdPの退職処理が連携先のアカウント停止まで届く形にしてください。

SSOの検証処理はライブラリに任せて自前で書かなくてよいですか？

署名やトークンの検証そのものはライブラリに寄せてください。自前実装はXML Signature Wrappingやalg差し替えなど既知の攻撃を踏みやすく、割に合いません。ただし呼び出し側の引数は自分の責任範囲です。algの固定、audとissの突き合わせ、nonceとstateの照合、strictの有効化は、ライブラリを使っていても指定を落とせば検証が素通りします。

SSOの導入で最初に用意しておく情報は何ですか？

IdP側のissuerとJWKSのURL（SAMLならメタデータと証明書）、SP側のentityIdと受信URL、連携先へ渡す属性の一覧の3点です。この記事のcurl手順でIdPから実値を取れば、推測で埋めた設定に起因する不一致エラーはほぼ避けられます。属性一覧は後から変えると全連携先の見直しになるため、最初に標準セットを決めておくと後工程が軽くなります。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る