IdPとは、ユーザーの本人確認を行い、その結果をSaaSなどのサービスへ伝える認証基盤です。サービスごとにログイン情報を管理する負担を減らし、SSOや多要素認証の運用をまとめる役割を担います。

IdPは認証する側、SPは認証結果を受け取ってサービスを提供する側です。IDaaSは、IdPを含むID管理機能をクラウドで提供するサービス形態を指します。この違いを押さえると、製品名と仕組みを混同せずに比較できます。

導入時には、連携するSaaS、認証方式、退職時の停止範囲を確認します。IdPが管理できる範囲と、SaaS側で別途確認する範囲を分けることが、認証基盤を刷新する情シス担当者の出発点になります。

IdPとは｜認証情報を管理し本人確認を担う基盤

IdPはIdentity Providerの略で、ユーザーの認証情報を管理し、SaaSなどの外部サービスへ本人確認の結果を伝える基盤です。社員のSaaSログインを横断的に支える役回りを担います。

社員がGoogle WorkspaceやMicrosoft 365、Salesforceにログインする際、IdPがその社員の身元を確認し、各サービスへこの人物は本人だと保証する役割を担います。サービスごとに個別のIDとパスワードを発行する従来型から、ひとつの認証で複数サービスを使える仕組みへ移る起点になります。

IdPが注目を集める背景には、3つの変化があります。1つ目はクラウドサービスの普及で、社内システムだけを守っていた時代から、数十のSaaSを同時に統制する時代へ移りました。2つ目はゼロトラストセキュリティの広がりで、ネットワーク境界ではなく誰がアクセスしているかを起点に認証を設計する考え方が主流になっています。3つ目はハイブリッドワークの定着で、オフィス内外を問わず安全に業務を回すための認証基盤が求められるようになりました。

SaaSが当たり前となった企業ITの根幹を支える存在として、IdPは情シス部門にとって避けて通れない領域へ広がっています。

IdP・SP・IDaaS・SSOを見分ける早見表

IdPとSPは認証連携の役割、IDaaSはサービスの提供形態、SSOはログインの仕組みを表す用語です。同じ製品の説明に並んでいても、比較している対象は異なります。稟議書や要件表では、役割と導入する製品を分けて記載すると整理できます。

クラウド型の製品選定を進める場合は、IDaaSとSSOの関係も合わせて整理してください。認証基盤に求める機能と、業務アプリ側に必要な設定を切り分けやすくなります。

IdPの仕組み｜SAMLアサーションで本人確認を共有する流れ

SAMLを使うIdP連携では、IdPが発行したアサーションをSPが検証し、本人確認の結果を共有します。アクセスの起点によってSP-initiatedとIdP-initiatedに分かれます。IdPのすべての連携がSAMLで動くわけではなく、OIDCを使う構成もあります。

利用者がIdPで本人確認に成功すると、IdPは身元情報をXML形式のアサーションにまとめ、サービス側へ受け渡します。サービスはアサーションの正当性を検証し、問題がなければユーザーをログイン状態に切り替えます。

SP-initiatedフロー｜サービス側からIdPへ誘導される流れ

SP-initiatedはユーザーがサービスプロバイダ（SP）にアクセスしてからIdPへ誘導されるパターンで、最も多く採用されている認証フローです。日常業務での導線になじみやすい構造を持ちます。

社員がブラウザでSalesforceのURLを開くと、SalesforceはまずIdPへ認証要求を送ります。IdPはユーザーにログイン画面を提示し、本人確認が完了したらSAMLアサーションを発行してSalesforceへ戻します。Salesforceはそのアサーションをチェックしてダッシュボードへユーザーを通します。

利用者から見れば、いつものSaaSのURLにアクセスするだけで自動的に認証が済むため、業務の流れを止めない自然な動線になります。

IdP-initiatedフロー｜IdPダッシュボードから各サービスへ遷移する流れ

IdP-initiatedはIdPの管理画面に並ぶアプリ一覧から、各SaaSへ直接遷移するパターンです。複数SaaSを連続して使う場面で運用しやすくなる特徴があります。

社員はまずIdPのポータルにログインし、そこからSlackやBox、Microsoft 365のアイコンをクリックして利用を開始します。アクセスのたびにIdPへ認証要求が走らないため、業務の合間に複数のSaaSを行き来する働き方に向いています。

ただし全てのSaaSがIdP-initiatedに対応しているわけではないため、導入前に各サービスの仕様を確認しておきましょう。

IdPとSPの違い｜役割を整理する

IdPは身元を証明する側、SPはサービスを提供する側であり、両者が連携することで初めてシングルサインオンが機能します。役割分担を押さえると認証連携の設計が見通せるようになります。

IdPはユーザーのID、パスワード、所属、役職などの認証情報を保管し、サービスに対してこの人物は本人だと保証する役目を担います。SP（サービスプロバイダ）はSaaSや業務アプリそのものを提供する側で、ユーザーが何を使うかに応える存在です。代表的なSPには、Google Workspace、Microsoft 365、Salesforce、Slack、Box、Dropbox、Zoomなどがあります。

両者の関係は、銀行ATMでの本人確認に当てはめると整理できます。利用者のキャッシュカードと暗証番号を確認して身元を保証する銀行がIdPに相当し、確認結果をもとに現金を提供するATMの仕組みがSPに相当します。銀行が確認しなければATMはサービスを提供できず、ATMがなければ銀行の確認も活きません。

このようにIdPとSPは独立した役割を持ちつつ相互に依存しており、認証連携プロトコルを介して情報をやりとりすることで、ユーザーへなめらかなSaaS利用環境を届けています。

IdPとIDaaSの違い｜概念とサービスの関係を理解する

IdPは認証機能の概念を指し、IDaaSはIdP機能をクラウドで提供するサービス形態を指します。両者を階層関係で捉えると、製品検討の議論が混線しません。

IdPは認証の役割を担う論理的な存在であり、自社オンプレミスのActive DirectoryやオープンソースのKeycloakなどでも実装できます。IDaaSはIdentity as a Serviceの略で、IdPの機能をクラウド型のサービスとして月額課金で利用できる形態です。

IDaaSはIdPを内包したサービス商品と捉えると関係性が明確になります。OktaやMicrosoft Entra IDはIDaaS製品であり、その内部にIdP機能を持つ構造です。

SaaSが普及した中堅から大企業の現場では、自社運用のIdPでは数十のSaaSへの対応が追いつかず、IDaaS型IdPへ移行する流れが主流となっています。クラウド型は対応SaaSの追加が継続的に行われ、認証ログの監査機能が標準で備わる点が運用の手応えにつながります。

IdPに関わる3つのプロトコル｜SAML・OAuth 2.0・OIDCの使い分け

SAMLとOIDCは、IdPからサービスへ認証結果を伝えるために使います。OAuth 2.0はアクセス権を委任する認可の仕組みであり、単体では本人確認のためのプロトコルではありません。自社のSaaSが対応する方式と、実現したい処理を分けて確認します。

3つはどれも似た役割を持ちますが、想定する利用シーンとデータ形式が違います。情シスとして製品を選ぶ際には、自社が使うSaaSがどのプロトコルに対応しているかを最初に確認することが選定の出発点になります。

SAML｜エンタープライズSSOで広く採用される標準

SAMLはSecurity Assertion Markup Languageの略で、XMLベースの認証連携プロトコルとして長年エンタープライズSSOの標準を担ってきました。企業向けSaaSが幅広く対応しています。

OASISという国際的な標準化団体によって策定された経緯から、Microsoft 365やSalesforce、Workdayといった業務向けSaaSが採用しています。XMLでアサーションを記述するため情報量が豊富で、属性ベースのアクセス制御を細かく組み立てやすい性質を持ちます。

業務アプリ中心のB2Bエンタープライズ環境で認証基盤を組む場合、SAML対応の有無はSaaS選定の基本要件として確認しておきたい項目です。

OAuth 2.0｜認可のためのプロトコルで認証ではない

OAuth 2.0は認可（Authorization）のプロトコルで、本来は認証（Authentication）を目的としていません。この区別を曖昧にすると認証設計が崩れる原因になります。

OAuth 2.0の本来の目的は、ユーザーが第三者アプリにリソースへのアクセス権限を委任する仕組みの提供です。あるアプリがユーザーのGoogleカレンダーを参照する許可を得る場面で使われるプロトコルが該当します。

ユーザーが誰かを確認する認証の役割を持たないため、OAuth 2.0単体でログイン処理を実装すると本人性の保証が不十分になるリスクが残ります。

OIDC｜OAuth 2.0上に認証層を追加した新しい標準

OIDC（OpenID Connect）はOAuth 2.0の上に認証レイヤーを追加した比較的新しい標準で、JWTと呼ばれるJSON形式のトークンで身元情報をやりとりします。軽量で扱いやすい設計が特徴です。

JSON形式で軽量に動作するため、モバイルアプリやB2Cサービス、シングルページアプリケーションでの採用が広がっています。OAuth 2.0の認可機能と認証機能を組み合わせて使えるため、Googleアカウントでログインといったソーシャルログインにも向いています。

エンタープライズSSOではSAMLが先行する一方で、新規開発のWebサービスやモバイルアプリではOIDCが選ばれるケースが増えています。

IdPで実現できる4つのこと

IdPの導入で得られる代表的な価値は、業務効率化、セキュリティ強化、運用一元化、監査対応の4点に整理できます。1つの認証基盤を中心に複数の施策を同時に進められる点が、IdP導入の手応えにつながります。

それぞれの効果は独立して見えても、運用上は相互に作用します。SSOで業務効率を上げると同時にMFAで防御を固め、その記録が監査に役立つといった連鎖が起こります。

SSOによる業務効率化

シングルサインオンによって、ユーザーは1度のログインで複数のSaaSにスムーズにアクセスできます。日々のログイン操作にかかる時間を大きく削れます。

サービスごとにIDとパスワードを覚える負担がなくなり、ログイン作業に費やす時間が短縮されます。20種類のSaaSを使う社員の場合、1日のログイン回数が10回減るだけで、月間で数時間分の業務時間を取り戻せる計算です。

利用者のストレス軽減と生産性向上を同時に進められ、情シスへのパスワードリセット問い合わせも減るため、運用負荷の軽減にも直結します。

MFA（多要素認証）によるセキュリティ強化

IdPに連携したSaaSでは、多要素認証のポリシーをまとめて管理できます。ただし、IdPを通らないログイン経路や未連携のSaaSは別に確認が必要です。認証基盤を導入したことと、すべての利用経路に同じ設定が適用されたことを区別して点検します。

アカウント・アクセス権限の一元管理

社員の入社、異動、退職に応じたアカウント発行や権限変更を、IdPで一括して制御できます。SaaSが増えるほど一元管理の効果が積み重なります。

人事システムやSaaSと連携させれば、入退社に応じたアカウント処理を自動化できます。実際の発行・停止範囲は連携先と構成を確認し、IdP側の処理結果とSaaS側のアカウント状態を照合します。未連携のSaaSには、別の停止手順を用意してください。

アクセスログの監査と内部統制対応

誰がいつどのSaaSにログインしたかを一元的に記録し、監査ログとして取り出せる仕組みが標準で備わります。証跡管理の負担を一気に減らせる位置にあります。

SOX法対応や情報セキュリティ監査では、アクセス履歴の証跡提出が求められます。SaaS各社のログを個別に集める手間から解放されるため、監査対応の工数を大きく削減できます。

実機の動作を確認したい方は Josys導入相談の予約ページ で日程を選べます。

代表的なIdP製品8選｜連携と運用の比較ポイント

IdP製品はグローバル系と国産系に大別され、連携可能SaaS数、MFA対応方式、SCIM対応、国内サポートの4軸で比較するのが選定の基本線です。中堅から大企業の情シスで実績の多い代表8製品を取り上げます。

Microsoft 365中心の環境ならEntra ID、最大連携数を重視するならOkta、国内サポートを最優先するならHENNGE Oneといった選び方が現実的な議論の出発点となります。

Microsoft Entra ID｜Microsoft 365との親和性が強み

Microsoft Entra IDは旧Azure Active Directoryから名称変更されたMicrosoft社のIDaaS製品で、Microsoft 365との一体運用が大きな強みです。Microsoft環境を中核に据える組織で第一の候補に挙がります。

条件付きアクセス機能では、会社デバイスからのログインに限定したり、アクセス条件に応じて多要素認証を求めたりできます。導入前に、現在のMicrosoft 365契約で必要な機能が利用できるか、追加ライセンスが必要かを確認してください。

参考：Microsoft Entra ID 公式サイト

Okta｜対応SaaS数で業界トップクラス

Oktaは7,000以上のSaaSに対応する事前統合カタログを持ち、グローバルでのシェアが大きい代表的なIDaaS製品です。新興SaaSへの対応スピードが早い点が評価されています。

導入実績は世界で17,000社以上に及び、複数ベンダーのSaaSを横断して使う中堅から大企業では、対応SaaSの広さが意思決定の決め手になることが多くあります。

参考：OneLogin 公式サイト（SSO製品ページ）

OneLogin｜中堅企業向けのシンプルな管理画面

OneLoginは管理画面の見やすさと設定のシンプルさで評価される、中堅企業向けの選択肢です。情シスのリソースが限られた組織でも運用を回しやすい設計になっています。

機能を絞り込みつつSSOとMFAを必要十分に提供しており、OktaやEntra IDほどの機能は不要だが自社運用ADから脱却したい場合の現実解として選ばれます。

参考：OneLogin 公式サイト（SSO製品ページ）

Auth0｜開発者向けで自社サービスへの組み込みに強い

Auth0は2021年にOktaグループへ参画した開発者フレンドリーなIDaaSで、自社サービスへのログイン機能組み込みに強みを持ちます。B2C向けの認証基盤として採用例が多い製品です。

ソーシャルログインやパスワードレス認証、カスタム認証フローの実装が容易で、社内SSOというより顧客向けサービスのログイン基盤として位置づけられます。

参考：Auth0 公式サイト（機能ページ）

Google Cloud Identity｜Google Workspaceと一体運用

Google Cloud IdentityはGoogle Workspaceと統合された無料・有料プランがあり、Googleエコシステム中心の組織で第一の選択肢になります。追加の管理コストが発生しない構成が特徴です。

Google WorkspaceのアカウントをそのままIdPとして他のSaaSへ展開でき、ChromebookやGmailを業務の中心に据える企業との親和性が高い構成です。

参考：Google Cloud Identity 公式サイト

Ping Identity｜エンタープライズ向けでハイブリッド対応

Ping Identityはエンタープライズ向けのハイブリッド環境（クラウドとオンプレミスの併用）に強い製品で、大規模組織での採用が目立ちます。柔軟なポリシー設計が評価されています。

複雑な既存ADやオンプレ業務システムを抱えながら、徐々にクラウド認証へ移行したい大企業に向いています。リスクベース認証のきめ細かさが競合との差別化ポイントです。

参考：Ping Identity 公式サイト

HENNGE One｜国内導入実績が豊富な国産IDaaS

HENNGE Oneは国内シェアの高い国産IDaaSで、日本語サポートと日本企業の運用文化への適合度が選定理由として挙がります。導入支援を日本語で受けられる安心感が評価されています。

シングルサインオン、アクセス制御、メールセキュリティを一体で提供するため、認証基盤の整備とメール周りの統制を同時に進めたい企業に向いています。

参考：HENNGE One 公式サイト

GMOトラスト・ログイン｜累計1万社以上の中堅・SMB向け

GMOトラスト・ログインは累計導入社数が1万社を超える国産IDaaSで、中堅から中小規模の組織で導入しやすい価格帯と機能構成が特徴です。コストを抑えつつ国産で安心したい情シスに支持されています。

多要素認証、アクセス制御、AD連携、パスワードレスログインを必要十分に備えながら、月額料金を抑えた構成で提供されています。

参考：GMOトラスト・ログイン 公式サイト（サービスページ）

IdP導入だけでは解決しないSaaS管理の課題

IdPは認証基盤の中核ですが、SaaS利用の実態把握やライセンス最適化はIdP単独では完結しません。SaaS管理プラットフォーム（SMP）と組み合わせることで、初めて運用が一気通貫になります。

IdPが記録できるのは認証された経路だけです。IdPを通さずに利用されているSaaSや、契約はあるが使われていないライセンスを把握する役割は持ちません。情シス部門が直面する次の4つの課題は、SaaS管理プラットフォームと組み合わせて初めて解決できる領域です。

孤立アカウントの検出

IdPで発行されたアカウントが、退職や異動の後に削除されないまま残り続ける状態を孤立アカウントと呼びます。IdP単独では各SaaS内部の残存状況まで掴めません。

IdPは認証時のログを残しますが、各SaaS内部のアカウント残存状況までは可視化しません。SaaS管理プラットフォームを併用すれば、SaaS側のアカウント一覧とIdPの権限状況を突き合わせ、不要アカウントを洗い出す運用ができます。

シャドーITの可視化

IdPを経由せずに社員が個人で契約しているSaaSは、認証基盤の管理対象外となり、利用実態が見えなくなります。IdPだけでは死角ができてしまいます。

法人カードの請求や個人クレジットカードでの契約は、IdPの外側で行われるため情シスから見えにくい領域です。SaaS管理プラットフォームはブラウザ拡張機能や経費データとの連携で、IdP管理外のSaaSを発見し、シャドーITを可視化します。

ライセンスの過剰契約と棚卸し

SaaSの契約ライセンス数と実際の利用状況にギャップが生じ、未使用ライセンスが膨らんで予算を圧迫する課題は、IdPの守備範囲外です。IdPだけでは余剰の判定材料が揃いません。

IdPでログイン回数は把握できても、誰が機能を実際に使っているか、どのライセンスが余剰かまでは見えません。SaaS管理プラットフォームは利用ログと契約数を突き合わせ、ライセンス削減や統合の判断材料を提供します。

IdPとSaaS管理プラットフォームの組み合わせ

Josysは、ITデバイスとSaaSの統合管理を出発点とするAI駆動のアイデンティティセキュリティ基盤です。IdPと組み合わせ、退職者IDの放置、シャドーIT、余剰ライセンスの是正につなげます。IdPでの認証と各SaaSでの利用状況を、異なる確認対象として扱います。

IdPが入口の管理を担い、SaaS管理プラットフォームが中身の管理を担う構成です。両者を併用することで、情シス2〜3名の体制でも数十のSaaSを統制できる運用体制が現実味を帯びてきます。

参考：IDaaSとSaaS管理の連携｜Entra ID・OktaをJosysでシームレス管理

IdP導入前に確認する運用チェックリスト

IdPを選ぶ際は、製品の機能一覧だけでなく、自社が利用するSaaSと入退社時の運用を照合します。すでに説明した連携方式、MFA、アカウント管理、監査ログを一つの確認表にまとめ、どの項目をIdPで担い、どの項目を別の手順で補うかを決めます。

認証連携とアカウント管理を分けて確認する

ログインできることの確認と、退職後にアカウントが残っていないことの確認は別の作業です。SaaSごとに認証の経路とアカウント管理の担当を整理し、連携の対象外になっているサービスを残さないようにします。申請から停止後の照合までを同じ台帳で追跡してください。

試験では、通常のログインだけでなく、利用を終了した後の状態も確認します。残存アカウントの照合は、アクセス権限の棚卸しと組み合わせると、日常の運用に落とし込めます。

自社の管理範囲に合わせて比較する

製品の連携数が多くても、自社に必要なSaaSや運用が対象に含まれているかは別に確認します。Microsoft 365などの既存環境との親和性、日本語での支援、アカウント処理の分担を比較表に記入し、未対応の項目には代替手順と担当者を置いてください。

導入後は、IdPで認証した記録とSaaSで実際に使われているアカウントを突き合わせます。IDaaSとSaaS管理の連携を設計する際も、ログインの一元化と利用状況の把握を別々に確認することが、管理漏れを見つける手掛かりになります。

まとめ｜IdPは認証の中核、SaaS管理と組み合わせて完結させる

IdPはSaaS時代の認証基盤として欠かせない存在ですが、それ単独で全ての課題が片付くわけではありません。本記事のポイントを整理します。

• IdPは認証情報を管理しSPに身元を証明する基盤であり、SaaS利用の起点となる役割を担います。
• IDaaSとの違いは概念とサービス形態の関係であり、IdPはIDaaSの中核機能として位置づけられます。
• 認証連携プロトコルはSAML、OAuth 2.0、OIDCを用途に応じて使い分けます。
• 代表8製品は連携SaaS数、MFA対応、SCIM対応、国内サポートの軸で比較しましょう。
• IdPだけではSaaS利用の実態把握やライセンス最適化は完結せず、SaaS管理プラットフォームと併用してこそ運用が成立します。

認証基盤の刷新を検討中の方は、IdP単独の導入で終わらせず、SaaS管理体制全体を視野に入れた設計から始めましょう。

資料の確認は 5分でわかるJosys、デモのご予約は Josys導入相談ページ からどうぞ。

-------

関連記事：IDaaSとは｜SSO・SCIM・ゼロトラストとの関係をIT管理者向けに解説

関連記事：SSO（シングルサインオン）とは｜仕組み・4つの認証方式・13製品比較

関連記事：IDaaSとSaaS管理の連携｜Entra ID・OktaをJosysでシームレス管理

関連記事：IGAとは｜IAM・IDaaSとの違いと導入判断基準

関連記事：SaaS入退社アカウント自動化ガイド｜仕組みと13ツール比較