読む前にこの記事のポイントを音声で確認できます。この音声は本記事をもとにAIツール（NotebookLM）で自動生成したもので、発音や言い回しが不自然な箇所や、内容の誤りが含まれる可能性があります。理解の補助としてご利用ください。
アプリケーションのクラウド化やリモートワークの広がりにともない、セキュリティの考え方も、社内と社外を境界で分ける境界型から、ゼロトラストへ移ってきています。ゼロトラストでは、ID、デバイス、アプリケーションなどに対して、アクセスのたびにセキュリティのチェックをするのが原則です。その中でも、まず土台になるのが ID の管理と認証です。
Okta や Microsoft Entra ID に代表される IAM（Identity and Access Management）や IDaaS（Identity as a Service）という言葉はよく聞きますが、クラウドでどのように ID を認証・管理するのかは、イメージしにくいかもしれません。この記事では、Web アプリケーションの ID 認証が、従来の方式から IDaaS へどのように移り変わってきたのかを、仕組みのイメージがつかめるように整理します。細かいプロトコルの仕様よりも、全体の流れを優先しています。
- Web アプリごとの認証と、共通の認証サーバを使う認証の課題
- 認証を IdP に任せる方式（フェデレーション）と、SAML の認証の流れ
- アプリとユーザがインターネットに出たことで IDaaS が必要になる理由と、シングルサインオンの仕組み
初期のID認証
初期の Web アプリケーションでは、ユーザ ID やパスワードなどのユーザ情報を、Web アプリケーションごとにデータベースで管理していました。
認証フロー
ユーザが Web アプリにアクセスすると、Web アプリはログイン画面（認証フォーム）を表示します。ユーザはクレデンシャル（ユーザ ID とパスワード）を Web アプリに送り、Web アプリはユーザ情報を持つ DB に問い合わせて照合し、認証結果をユーザに返します。
課題①：ID管理がシステム個別
まず大きな問題は、ユーザ DB（ユーザ ID とパスワード）がシステム（Web アプリ）ごとに管理されていることです。Web アプリが複数あると、この問題がはっきり表れます。
ユーザは、システムごとにユーザ名とパスワードを覚えなければならず、シングルサインオンもできません。管理者も、ユーザの追加や削除をシステムごとに行う必要があります。
課題②：クレデンシャルの扱い
ユーザは、クレデンシャル（ユーザ ID とパスワード）を Web アプリにそのまま渡しています。これはセキュリティ上、好ましくありません。Web アプリ側に何らかの仕掛けをされると、クレデンシャルを盗まれるおそれがあります。
課題③：認証処理
クレデンシャルを受け取った Web アプリは、ログイン画面の表示やユーザ DB への問い合わせなど、認証処理を自分で行っています。Web アプリの役割はサービスを提供することなので、認証処理は Web アプリから切り離すのが望ましい形です。
共通ID認証
次に、システムごとに管理していたユーザ DB を、共通の認証サーバで一元管理する形が考えられました。Web アプリは、受け取ったクレデンシャルを共通の認証サーバに問い合わせて確認します。
オンプレミスの企業環境では、共通の認証サーバとして LDAP サーバや Active Directory がよく使われます。オンプレミスでは、今もよく見かける構成です。システムごとに ID を管理する必要はなくなりましたが、まだ課題が残っています。
課題①：パスワード入力
ユーザは基本的に、Web アプリにアクセスするたびに、同じユーザ名とパスワードを Web アプリごとに入力する必要があります。シングルサインオンの環境ではありません。
課題②：クレデンシャルの扱い
初期の ID 認証と同じく、クレデンシャルは Web アプリに送られます。
課題③：認証処理
初期の ID 認証と同じく、Web アプリが認証処理を行います。
環境の変化（Webアプリがクラウドへ）
共通 ID 認証は、Web アプリがオンプレミスにある場合によく見かける構成です。ところが、Web アプリはどんどんクラウドへ移っています。
この構成のまま Web アプリがクラウドに移ると、クラウドの Web アプリが、オンプレミスの認証サーバ（LDAP や Active Directory）に認証の問い合わせをすることになります。社内の認証サーバをインターネット側から直接使えるようにすることになり、セキュリティ上は避けたい構成です。共通 ID 認証は、Web アプリと認証サーバが同じネットワーク（同じセキュリティレベル）にあることを前提にした仕組みだといえます。
Web アプリと認証サーバが直接やり取りしないようにするために使われるのが、次の「認証を IdP に任せる方式」です。
認証をIdPに任せる方式（フェデレーション）
この方式では、サービスを提供する側（Web アプリ）が自分で認証サーバに問い合わせるのではなく、利用者（ブラウザ）を経由して、認証を専門のサーバに任せます。認証を任された側が認証し、その結果を Web アプリが信頼して受け入れる仕組みで、ID 連携（フェデレーション）と呼ばれます。
たとえで考える
お父さん、お母さん、子どもの3人がいるとします。子どもがお父さんにお菓子を買ってほしいとお願いしますが、買ってよいかどうかの判断はお母さんに任せます。お父さんが Web アプリ、お母さんが認証サーバ、子どもがユーザの役です。
共通 ID 認証の方式では、次のようになります。お父さんがお母さんに確認しに行き、買うかどうかはお父さんが決めます。お母さんは、確認を受けて答えるだけです。
認証を任せる方式では、お父さんはお母さんに聞きに行きません。子どもにお母さんのところへ聞きに行かせ、お父さんは、お母さんが許可したかどうかだけを子どもから聞きます。お父さんは、お母さんの判断に従います。
SAML（Security Assertion Markup Language）
この方式でよく使われるのが、SAML（Security Assertion Markup Language）による認証です。SAML では、サービスを提供するアプリ側を SP（Service Provider）、ユーザ ID を持ち認証を行う側を IdP（Identity Provider）と呼びます。上のたとえでは、お父さんが SP、お母さんが IdP です。
Web アプリを SP とし、LDAP や Active Directory のユーザ ID を使って認証する IdP を別に置きます。Active Directory の環境では、代表的な IdP として AD FS（Active Directory フェデレーション サービス）が使われます。次の流れは、ユーザが SP（Web アプリ）にアクセスするところから始まる SP-Initiated の場合です。
| 手順 | 内容 |
|---|---|
| ① アクセス | ユーザが Web アプリ（SP）にアクセスする |
| ② リダイレクト | SP は、認証を IdP で行うよう、ブラウザを IdP へリダイレクトする（認証要求を持たせる） |
| ③〜⑤ ログイン | ユーザが IdP に接続すると、IdP がログイン画面を表示する。ユーザは ID とパスワードを IdP に入力する |
| ⑥ 照合 | IdP が LDAP や Active Directory と連携して、ID とパスワードを確認する |
| ⑦〜⑧ 結果を渡す | IdP は認証結果を持たせてブラウザを SP へリダイレクトし、ユーザはその認証結果を SP に渡す。SP は認証結果を確認して、サービスの提供を始める |
この流れでは、SP と IdP が直接やり取りしていません。認証要求と認証結果は、必ずブラウザ（ユーザ）を経由して受け渡されます。認証は IdP で行うので、クレデンシャルは SP（Web アプリ）に送られません。SP は、IdP で認証した結果だけを受け取ります。
- SAML でよく使われる受け渡し方法（バインディング）では、SP から IdP への認証要求を HTTP リダイレクトで、IdP から SP への認証結果を HTTP POST で、どちらもブラウザ経由で送ります。
- 認証結果（アサーション）には IdP の署名が付いていて、SP は事前に受け取った IdP の証明書で、それが正しい IdP から届いたものかを確かめます。
- IDaaS では、SAML のほかに OpenID Connect もよく使われます。
環境の変化（ユーザがインターネットへ）
リモートワークの普及などにより、ユーザはオンプレミスを経由せず、インターネットから直接、クラウド上の Web アプリ（SaaS）に接続するようになりました。
今までの構成のままユーザがインターネットに出ると、認証のためにインターネットからオンプレミスの IdP へ接続することになります。インターネットからオンプレミスへの接続になるので、セキュリティ上は基本的に好ましくありません。Active Directory の環境では、DMZ に AD FS のプロキシである WAP（Web アプリケーション プロキシ）を置き、WAP を経由させることで、インターネットからオンプレミスの AD FS で認証できるようにする構成もあります。
そこで、IdP の機能そのものもクラウドへ移す必要が出てきます。これが IDaaS（Identity as a Service）で、Okta や Microsoft Entra ID（旧 Azure Active Directory）がよく知られています。
IdP の機能はクラウドに移っても、ユーザ ID そのものは、人事システムなどの情報をオンプレミスの LDAP や Active Directory に連携して管理していることが一般的です。この場合は、オンプレミスの LDAP や Active Directory のユーザ ID 情報を、IDaaS に同期します。
Active Directory から Microsoft Entra ID へは Microsoft Entra Connect（旧 Azure AD Connect）や Microsoft Entra Cloud Sync で、Okta へは Okta AD エージェントで、ユーザやグループを同期（取り込み）します。同期できる認証ソースや同期の手順は、IDaaS によって異なります。
Azure AD Connect は Microsoft Entra Connect に名前が変わっています。Microsoft は、クラウドから管理する Microsoft Entra Cloud Sync を今後の同期の方式として位置づけ、Microsoft Entra Connect からの移行を案内しています（2026年10月時点）。
シングルサインオン（SSO）
IdP と SP は別の組織（別のシステム）なので、あらかじめ信頼関係を結んでおき、IdP が認証 OK とした結果を SP が信頼できるようにしておく必要があります。SAML では、IdP と SP がお互いの情報（メタデータ：エンドポイントの URL や署名の証明書など）を事前に交換します。SAML の動作は、次の記事も参考にしてください。
複数の SP（WebAPP-1 と WebAPP-2）が IdP と信頼関係を結んでいる場合、ユーザが一度 WebAPP-1 の利用時に IdP で認証されていれば、信頼関係のあるほかの SP（WebAPP-2）にアクセスしたときも、IdP はクレデンシャルを入力させずに認証成功として扱います。ユーザはクレデンシャルを入力せずに SP にアクセスできるので、シングルサインオンが実現します。
まとめ
| 方式 | ID の管理と認証 | 課題・特徴 |
|---|---|---|
| 初期の ID 認証 | Web アプリごとのユーザ DB。Web アプリが認証 | ID がシステムごと。クレデンシャルを Web アプリに渡す |
| 共通 ID 認証 | LDAP／AD で一元管理。Web アプリが問い合わせて認証 | アプリごとに入力。アプリがクラウドに出ると、認証サーバへの問い合わせが難しい |
| フェデレーション（SAML） | IdP（AD FS など）が認証し、SP は結果だけを受け取る | クレデンシャルは SP に渡らない。ユーザがインターネットに出ると、オンプレの IdP に接続することになる |
| IDaaS | IdP をクラウドに置く。ID はオンプレから同期 | インターネット上のユーザとクラウドのアプリで認証が完結し、SSO もできる |
コメント