IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説

SaaSが増えるたびにアカウント発行の依頼が届き、退職者の削除漏れが監査で指摘される。IDaaS（Identity as a Service）は、利用者IDと認証をクラウド側へ集約して提供するサービス類型です。ただし「SSOができるサービス」という説明では、自社アプリを寄せるときにどこまで作らずに済むかを判断できません。本記事では、IdPやSSOとの用語の境界、SAML 2.0とOpenID Connectによる認証の仲介、SCIM 2.0が自動化する範囲、既存システムを寄せる際の改修範囲と移行設計を実装の解像度で整理します。

まとめ：IDaaSの位置づけと採用判断の結論

先に結論を置きます。IDaaSは認証機能の詰め合わせではなく、利用者IDの正本（Source of Truth）をクラウド側へ移す構造の変更です。SSOやMFAは、その構造変更に付いてくる機能の一部にすぎません。導入効果が出るかどうかは、機能の数ではなくID正本をどこへ置き切れるかで決まります。

アプリ側から見た守備範囲は3つです。認証（誰であるか）はIDaaSへ全面的に預ける。認可（何をしてよいか）はロールの受け渡しまでがIDaaSで、資源ごとの判定はアプリに残る。アカウントのライフサイクルはSCIM 2.0で自動化できますが、業務データとの紐づけはアプリの責務として残り続けます。

見送るのは、認証要件が単一アプリに閉じている場合、認証画面まで自社ブランドで作り込む場合、外部依存を許容できない可用性要件がある場合の3つでした。従業員向け（IAM）と顧客向け（CIAM）で選定基準が割れる理由と併せ、独自章で条件つきに整理します。

IDaaSの定義とIdP・SSO・ADとの用語の境界線を役割別に整理

まず言葉の階層を固めます。IDaaS・IdP・SSOは並列の選択肢ではなく、それぞれ提供形態・役割・機能という別のレイヤーを指す言葉でした。

IDaaSが担う4つの責務とサービス類型として扱う機能の範囲

IDaaSはIdentity as a Serviceの略で、ID管理と認証をクラウドサービスとして提供する類型を指します。自社でサーバーを立てて認証基盤を構築・運用する代わりに、利用者ディレクトリと認証処理を事業者側へ寄せる形です。担う責務は大きく4つ。第一に利用者ディレクトリの保持、第二に認証の実行（パスワード・MFA・パスワードレス）、第三に連携先アプリへの認証結果の受け渡し、第四にアカウントのライフサイクル管理と監査ログの保全。この4つが揃うものをIDaaSと呼びます。

注意したいのは、IDaaSが「認可基盤」ではない点です。誰であるかを保証し、所属やロールという属性を渡すところまでが仕事で、その属性で個々の資源へのアクセス可否を決めるのは各アプリに残ります。ここを取り違えると、導入後に「権限の細かい制御ができない」という不満が出る。属性をどう解釈するかは、最初からアプリ側の設計事項として置いておく必要があります。

IdPという役割名とIDaaSの対応をSP・RPとの関係から確認

IdP（Identity Provider）は製品の分類ではなく、認証連携における役割の名前です。認証を実行して結果を発行する側がIdP、結果を受け取って利用者を認めるアプリ側がSP（SAMLでの呼称）またはRP（OpenID Connectでの呼称）になります。

したがって「IDaaSかIdPか」という比較は成立しません。IDaaSはIdPの役割をクラウドサービスとして提供する形態で、ADFSやKeycloakを自前で立てた場合も同じくIdPです。役割は同じで、運用主体と提供形態が違う。

SSOとIDaaSの違いを機能名とサービス類型という階層から比較

SSO（シングルサインオン）は1回の認証で複数サービスへ入れる仕組みの名前で、IDaaSが提供する機能の1つでした。IDaaSを導入すればSSOは付いてきますが、SSOの実現手段はIDaaSだけではありません。リバースプロキシ型や代理認証型など、IdPを立てずに実現する方式も存在します。

方式の違いが選定に効くのは、連携先が標準プロトコルに対応していない場合です。SAMLもOIDCも話せない社内システムが残るなら、代理認証やエージェント導入の併用を検討することになります。方式ごとの向き不向きはSSOの4つの実現方式とIdP選定の考え方で整理しました。

オンプレミスのAD／LDAPとIDaaSの守備範囲が重なる部分

Active DirectoryやLDAPも利用者ディレクトリと認証を担うため、守備範囲は重なります。違いは想定する接続先です。ADはドメイン参加端末やファイルサーバーの統制に強く、KerberosやGPOによる端末管理まで含む。一方IDaaSは、社外のSaaSへHTTPSで認証結果を渡す前提で設計されています。

実務では片方に寄せ切らず、ADを人事情報の入り口として残し、同期ツールでIDaaSへ利用者を流す構成が多い。この場合の正本はADで、IDaaSは配布役です。

IDaaSが認証を仲介する仕組みを通信プロトコルと処理単位で分解する

IDaaSの中身は、標準プロトコルの実装の集合です。何が標準で決まっていて何が製品独自かを分けておくと、乗り換え可能性の評価がしやすくなります。

SAML 2.0のアサーション交換とブラウザリダイレクトの流れ

SAML 2.0はOASISが標準化したXMLベースの認証連携仕様で、2005年に承認されて以降、企業向けSaaSの連携方式として広く使われてきました。認証結果は「アサーション」というXML文書で表現され、IdPの秘密鍵で署名されます。

SP-Initiatedと呼ばれる典型的な流れは4段階です。利用者がSPへアクセスすると、SPは認証要求を付けてブラウザをIdPへリダイレクトする。IdPは自分のセッションを確認し、無ければ認証画面を出す。認証が済むとアサーションをブラウザ経由でSPのAssertion Consumer Serviceへ送る。SPは署名を検証し、NameIDと属性から自システムの利用者を特定してセッションを張ります。

詰まりやすいのは、この最後の「自システムの利用者を特定する」段です。アサーションが正しく届いても、NameIDに何を入れるか（メールアドレスか不変IDか）を決めていなければ、アプリ側のユーザーテーブルと結びつきません。ここは標準では決まっておらず、IdPとSPの取り決めになります。

OpenID ConnectのIDトークンと認可コードフローの対応

OpenID Connect（OIDC）はOAuth 2.0（RFC 6749）の上に認証を載せた仕様で、Core 1.0が2014年に公開されました。SAMLとの違いは、XMLではなくJSON Web Token形式のIDトークンを使う点と、モバイルアプリやSPAを想定した設計になっている点です。

認可コードフローでは、RPがIdPの認可エンドポイントへ利用者を送り、発行された認可コードをトークンエンドポイントでIDトークンとアクセストークンに交換します。IDトークンには発行者（iss）、対象者（aud）、主体の識別子（sub）、認証時刻（auth_time）などのクレームが入る。RPは署名検証に加えissとaudの一致、有効期限、nonceの照合まで確認して初めて認証成立と扱います。

公開クライアント（モバイルアプリやSPA）では、認可コードの横取りを防ぐPKCE（RFC 7636）の併用が前提になりました。OAuth 2.1のドラフトでは全クライアントでのPKCE必須化とインプリシットフロー廃止が方向づけられており、2026年8月時点の新規実装は認可コードフロー＋PKCEが基本形になります。

SCIM 2.0によるアカウント自動プロビジョニングが担う範囲

認証が繋がっても、アカウントの作成と削除が手作業のままなら管理工数は減りません。ここを埋めるのがSCIM 2.0（RFC 7643／7644、2015年公開）で、利用者とグループをJSONで表現し、REST APIで作成・更新・無効化を行う仕様です。IDaaS側で利用者を作れば連携先にも自動で作られ、退職処理をすればアプリ側も無効化される。

ただし自動化されるのはアカウントとグループ所属までです。そのアカウントが業務データ上のどの担当者に当たるか、過去の申請履歴を誰へ引き継ぐかといった紐づけはアプリの責務として残る。属性のマッピング設計まで含めた進め方はSCIMのスキーマとプロビジョニング実装にまとめました。

認証とID連携のプロトコル別の使い分けを目的と対応範囲で整理

新規に自社アプリを繋ぐならOIDC、既存の業務SaaS側がSAMLしか対応していないならSAML、という判断が基本になります。

IDaaSの主要機能と自前実装との開発・運用工数差が出る境界

どこまでを作らずに済むのかを、機能ごとに見ていきます。工数差が大きい順に並べると導入判断の材料になります。

MFAとパスワードレス認証で自前実装とのコスト差が開く要因を整理する

差が開くのはMFAとパスワードレスでした。TOTPの実装だけならライブラリで済みますが、実運用ではデバイス紛失時の再登録、バックアップコードの発行と失効、管理者による一時解除、試行回数制限とロックアウトの解除フローまで要ります。認証本体より周辺の運用機能のほうが分量が多い。

FIDO2／WebAuthnによるパスワードレスはさらに差が開きます。認証器の登録・複数端末での鍵管理・ブラウザごとの挙動差の吸収まで含めると、自前実装は現実的な選択肢になりにくい。IDaaSはこの層を製品機能として持つため、アプリ側は結果を受け取るだけで済みます。

条件付きアクセスとリスクベース認証が不正ログイン対策に効く場面

接続元IP、端末の管理状態、地理的な位置、直近の失敗回数といった条件でMFAの要否を切り替える機能を、多くのIDaaSが備えています。全アクセスにMFAを課すと利用者の負担が大きく、無条件で省けば守れない。自前で作る場合は判定材料の収集（端末情報・IPの評判・行動履歴）が壁になり、継続的な更新が要る領域のため製品側の資産を借りる判断が合理的です。

監査ログとアクセスレビューが統制要件になる場面を見極める基準

ISMSやSOC 2、Pマークの審査では「誰がいつ何にアクセスできる状態だったか」の証跡を求められます。IDaaSは認証ログとアカウント変更履歴を一元的に残すため、アプリごとにログ形式が違う状態から抜けられる。権限棚卸し（アクセスレビュー）機能を持つ製品もあり、上長へ確認依頼を配信して承認結果を記録するところまで自動化できます。監査対応がボトルネックの組織では、SSOよりこちらが導入理由になる場合がありました。

アプリカタログの事前連携が導入工数を抑える範囲と対象外の範囲

主要なIDaaSは、著名SaaSとの接続設定を事前に用意したアプリカタログを持ちます。カタログにある製品なら、証明書の交換やエンドポイントURLの設定を手作業で行う必要がありません。

効かないのは自社開発アプリと、カタログ未収載の国内向けSaaSです。前者はSAMLまたはOIDCのクライアント実装を自分で書く。後者は標準プロトコルに未対応なら接続できません。繋ぎたいアプリの一覧を作り、対応可否を1つずつ確かめる作業を導入前に省略しないことです。

自社アプリをIDaaSへ移行するときの改修範囲と段階的な移行設計

ここからは受託開発の現場で実際に手を動かす部分です。既存アプリを繋ぐ工数は、認証処理そのものより周辺の作り替えに出ます。

既存のID体系とIDaaS側の主キーを移行時に対応づける方法

最初に決めるのは突合キーです。IDaaSから届くsubやNameIDと、既存ユーザーテーブルのどの列を突き合わせるかを決めないと先へ進めません。

メールアドレスを使う設計は分かりやすい反面、姓の変更や部署異動でアドレスが変わると同一人物と認識できなくなります。安全なのは、IDaaS側の不変IDを格納する列を新設し、初回ログイン時にメールアドレスで突合して不変IDを保存する二段構えです。以降は不変IDだけで照合するため、アドレス変更の影響を受けません。既存アカウントが重複しているなら、寄せる前にアプリ側で名寄せを済ませておくこと。連携開始後の名寄せは権限や履歴の移送まで巻き込み、コストが跳ね上がります。

セッション管理の責務分界と各アプリへのログアウト伝播の設計方針

IDaaS導入後もアプリ側のセッションは残ります。IdPのセッションとアプリのセッションが二重に存在する構造になり、この2つの有効期限をどう揃えるかが設計事項になりました。

問題が出やすいのはログアウトです。アプリ側でログアウトしてもIdPのセッションが生きていれば、ログイン画面へ戻った瞬間に再認証なしで入り直せます。利用者からは「ログアウトできていない」と見える。SAMLのSingle Logout（SLO）やOIDCのRP-Initiated Logoutを実装するか、少なくとも共用端末での挙動を仕様として明示しておくこと。アプリ側の有効期限はIdP側より短くするのが扱いやすく、期限切れ後もIdPのセッションが生きていれば再認証は利用者に見えません。

段階移行を並行稼働で進める手順と障害発生時の切り戻し条件の決め方

全社一斉の切り替えは避けます。認証は落ちた瞬間に全員が業務を止められる経路のため、戻せる形で進めることが前提になります。

1. 既存のパスワード認証を残したまま、IDaaS経由のログイン導線を追加する（並行稼働の開始）
2. 情シスなど少人数の部署でIDaaS経由へ切り替え、ログアウト・パスワード変更・端末変更まで一巡させる
3. SCIM連携を有効にし、入社と退社を1サイクル通してアカウントの作成と無効化を確認する
4. 全社をIDaaS経由へ寄せ、既存ログイン導線を管理者限定の緊急経路として残す
5. 一定期間の安定稼働を確認したうえで、既存のパスワード認証を停止する

切り戻し条件は事前に数値で決めておきます。ログイン成功率が閾値を下回る、問い合わせ件数が想定を超える、SCIMの同期エラーが継続する。この3つのいずれかで並行稼働へ戻す取り決めがあれば判断で迷いません。4番目の緊急経路を消すのを急がない点も実務上の要点でした。

会員向けサービスへIDaaSを組み込む場合に追加で必要になる設計

顧客向けサービスでは登録・退会・同意管理・属性の自己編集といった機能が必要になります。顧客向けという用途区分そのものの設計は、CIAMの責務分界と会員データベースからの移行手順で扱っています。IDaaSのCIAM機能でまかなえる範囲と、業務データ側に持つべき範囲を切り分ける設計が要る。会員データの正本をどちらへ置くかで、その後の機能追加のしやすさが変わります。会員基盤の設計と既存システムとの接続方針は会員管理システム開発でも相談を受け付けています。

IDaaSを採用しないと判断する条件と用途別の製品選定の見極め方

ここは判断を言い切ります。相談の場で見送りを勧める条件と、その理由です。

IDaaSを見送る3つの条件と自前認証基盤を継続して残す判断基準

見送りを勧めるのは3つの場合でした。第一に、認証要件が単一アプリに閉じていて連携先が増える見込みがないとき。IDaaSの価値は複数アプリへの配布にあるため、連携先が1つならライセンス費に見合いません。第二に、認証画面のUIまで自社ブランドで作り込む要件があるとき。ホストされたログイン画面のカスタマイズ範囲には制限があり、API経由の実装へ寄せると自前実装に近い工数がかかります。

第三に、外部サービスの停止を受け入れられない可用性要件があるとき。この場合はOAuth／OIDCの認可サーバーを自社で運用する選択肢が残り、構成はOry Hydraによる認可サーバー構築が参考になります。ただし鍵のローテーション、脆弱性対応、仕様追随を自分たちで担う覚悟は要ります。

従業員向けと顧客向けのIDaaSで製品選定基準が分かれる理由

同じIDaaSでも、従業員向け（Workforce IAM）と顧客向け（CIAM）では評価軸が違います。従業員向けで効くのは人事システムとの連携、SCIMによる入退社の反映、条件付きアクセス、監査ログ。利用者数は組織規模で決まり、増減も緩やかです。

顧客向けでは、突発的なアクセス増への耐性、ソーシャルログイン対応、登録フォームの自由度、利用者数に比例する課金体系が効きます。月間アクティブユーザー課金の製品では会員数が伸びるほど費用が線形に増える。従業員向けの感覚で単価を見積もると、成長後にコストが問題化します。2用途を1製品でまかなうとどちらかの要件が犠牲になるため、テナントか製品を分ける判断を最初に置くほうが後の作り替えを避けられます。

単一障害点になるIDaaSの停止時設計と運用で受け入れる前提条件

IDaaSへ寄せるということは、認証の単一障害点を1つ作ることでもあります。IDaaSが停止すれば、連携する全アプリへ誰も入れません。これは設計上の欠陥ではなく、集約と引き換えに受け入れる前提です。

打てる手は3つです。管理者用の緊急アクセス（Break-glass）アカウントをIDaaS外に用意すること、SLAと過去の稼働実績を契約前に確認すること、認証済みセッションの有効期限を極端に短くしすぎないこと。3つ目は見落とされやすく、有効期限が短いとIDaaS停止と同時にログイン中の利用者まで締め出されます。

クラウド事業者の認証基盤でも同じ整理が要ります。AWS環境の権限集約はAWS IAM Identity Centerの構成と適用範囲、ベンダー製品での導入進め方はOktaの導入支援プランと従業員ID管理の課題が具体例です。上流の設計判断は認証・ID管理の全体像とMFA・SSO・OIDCの選定で整理しました。

よくある質問

IDaaSの検討と実装でよく受ける質問をまとめました。

IDaaSとSSOは何が違うのですか？

階層が違います。SSOは1回の認証で複数サービスへ入れる仕組みという機能名で、IDaaSはその機能を含むサービス類型の名前です。IDaaSを導入すればSSOは使えますが、SSOはIDaaS以外の方式でも実現できます。リバースプロキシ型や代理認証型がその例でした。

IDaaSを入れれば認可（権限管理）も任せられますか？

部分的にのみ任せられます。IDaaSが担うのは、利用者の所属やロールといった属性を認証結果と一緒に渡すところまでで、個々のデータや操作の可否を判定する処理は各アプリ側に残ります。「営業部のロールを渡す」のはIDaaSの仕事ですが、「営業部の担当者は自分が作成した見積だけ編集できる」という判定はアプリの実装です。役割ベースの粗い制御をIDaaSへ寄せ、資源単位の判定をアプリに置く分担が現実的でした。

SAMLとOpenID Connectのどちらを選ぶべきですか？

新規に自社アプリを繋ぐならOpenID Connectを推奨します。JSONベースで実装しやすく、モバイルアプリやSPAを想定した設計になっているためです。既存の企業向けSaaS側がSAML 2.0にしか対応していないなら選択の余地はありません。多くのIDaaSは両方に対応するため、アプリごとに使い分けても管理は分かれない。判断はIDaaS側ではなく、繋ぎたいアプリ側の対応状況で決まります。

SCIM連携は必ず必要ですか？

連携先アプリの数と利用者数によります。アプリが数個、利用者が数十人なら手作業でも回りますが、入退社の頻度が高い組織や連携アプリが十数個を超える規模では、削除漏れが監査指摘の常連になります。SCIM連携があれば退職処理と同時に全アプリのアカウントが無効化され、棚卸し工数と漏えいリスクの両方が下がる。判断は「SSOの利便性」より「棚卸しにかかっている工数」を基準に見るほうが実態に合います。

IDaaSが停止したら業務は止まりますか？

連携している全アプリへの新規ログインが止まります。ただし既にセッションが確立している利用者は、その有効期限までは作業を続けられる。対策は、IDaaS外に管理者用の緊急アクセスアカウントを用意すること、既存のパスワード認証を管理者限定の緊急経路として残すこと、アプリ側セッションの有効期限を短くしすぎないことの3つです。契約前のSLAと稼働実績の確認も併せて必要になります。

関連記事

• シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説：IDaaS以外の方式も含め、SSOの実装手段を比較したい場合はこちらから。
• SCIMとは？スキーマとRESTの仕様・プロビジョニング実装を解説：入退社の反映を自動化する仕組みを、実装レベルで確認できます。
• AWS IAM Identity Centerとは？構成と権限セットの設計を解説：AWS環境の権限集約をIDaaSと併用する場合の接続点になります。
• IDaaS「Okta」導入支援｜スターターパック3プラン比較と従業員ID管理の課題解決：製品を絞った後の導入プランと進め方を具体的に確認できます。
• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説：発注側の判断材料として、認証まわりの全体像を俯瞰したい場合に。