Saltar al contenido principal

Proveedores de identidad - Servicios de autenticación centralizados

Lectura de 2 min aprox.

アイデンティティプロバイダー (Identity Provider, IdP) とは、ユーザーの認証情報を 一元的に管理し、他のサービスに対して「このユーザーは本人である」と証明する役割を 担うサービスです。企業が導入する Okta や Microsoft Entra ID (旧 Azure AD)、 個人向けの Google アカウントや Apple ID など、規模を問わず現代の認証基盤の 中核を成しています。IdP がなければ、ユーザーはサービスごとに個別のアカウントを 作成・管理する必要があり、パスワード疲れや セキュリティリスクの増大を招きます。

IdP と SP の関係

IdP は認証を提供する側、SP (Service Provider) は認証を受け取る側です。 ユーザーが SP にアクセスすると、SP は IdP に認証を委任し、IdP が本人確認を 行った結果 (アサーション) を SP に返します。この仕組みにより、ユーザーは IdP に一度ログインするだけで複数の SP を利用できるシングルサインオン (SSO) が 実現します。

IdP と SP の認証フロー
ユーザー
🧑‍💻
① アクセス
SP
Slack, Salesforce 等
② 認証委任
IdP
Okta, Entra ID 等
③ IdP がユーザーを認証 → ④ アサーション (認証結果) を SP に返却 → ⑤ SP がアクセスを許可

主要な IdP サービス

IdP主な対象特徴
Oktaエンタープライズ7,000 以上のアプリ連携。ゼロトラスト対応
Microsoft Entra IDMicrosoft 365 利用企業AD との統合。条件付きアクセス
Google Workspace中小〜大企業Google サービスとのシームレスな統合
Auth0 (Okta)開発者・スタートアップ柔軟な API。カスタマイズ性が高い

SAML と OIDC での IdP の役割

IdP が認証結果を SP に伝える方法として、主にSAMLOpenID Connect (OIDC) の 2 つのプロトコルが使われます。SAML は XML ベースでエンタープライズ向け、 OIDC は JSON/JWT ベースでモダンな Web・モバイルアプリ向けという棲み分けがあります。 どちらのプロトコルでも IdP の役割は「ユーザーの本人確認と認証結果の発行」ですが、 データ形式と通信方式が異なります。

SAML での IdP

XML 形式の SAML アサーションを発行。ブラウザリダイレクトで SP に送信。 エンタープライズの既存システムとの互換性が高い。

OIDC での IdP

JWT 形式の ID トークンを発行。 REST API で SP に送信。モバイルアプリや SPA との親和性が高い。

IdP が単一障害点になるリスク

IdP に認証を集約することは利便性とセキュリティの向上に寄与しますが、 IdP 自体がダウンすると全ての連携サービスにログインできなくなるという 単一障害点 (SPOF) のリスクを伴います。2023 年の Okta への不正アクセス事件では、 サポートシステム経由で顧客のセッショントークンが窃取され、多数の企業に影響が 及びました。IdP の選定時には、可用性 SLA、インシデント対応体制、 バックアップ認証手段の有無を慎重に評価する必要があります。スタートアップのセキュリティチェックリストでも IdP 選定のポイントを解説しています。

フェデレーションとディレクトリサービス

フェデレーション (Federation) とは、異なる組織間で認証情報を信頼し合う仕組みです。 例えば、取引先企業の IdP で認証されたユーザーが自社の SP にアクセスできるようにする ケースがこれに該当します。ディレクトリサービス (Active Directory、LDAP など) は 組織内のユーザー情報を格納するデータベースであり、IdP はこのディレクトリを 参照して認証を行います。IAM (Identity and Access Management) は 認証だけでなく認可 (アクセス権限の管理) も含む、より広い概念です。

よくある誤解

「IdP を導入すればセキュリティは万全」という誤解がありますが、IdP はあくまで 認証の入口を一元化するものです。IdP 自体のアカウントが多要素認証 (MFA) で 保護されていなければ、一度突破されると全サービスが危険にさらされます。 IdP の導入と同時に MFA の必須化、条件付きアクセスポリシーの設定、 ログ監視の整備を行うことが不可欠です。OAuth 権限リスクの記事で IdP 連携時の注意点も確認してください。認証セキュリティの関連書籍 (Amazon)も参考になります。

現場での使用例

「従業員 500 名の当社では、SaaS が 40 種類を超えた時点で Okta を IdP として 導入しました。各サービスへの個別ログインが不要になり、入退社時のアカウント 管理工数が 8 割削減されました。退職者のアクセス権を IdP 側で即座に無効化 できるため、企業のパスワードポリシーの 運用も格段に楽になっています。」

Términos relacionados

¿Te resultó útil este artículo?

XHatena