https://infomation-sytem-security.hatenablog.com/entry/security-relying-party-idp-sp-token

皆さん、こんにちは！とある企業で情報システム部のセキュリティ担当をしている城咲子です。CISSPと登録セキスペの資格を持ち、日々、社内のセキュリティを守るために奮闘しています。

さて、最近「シングルサインオン（SSO）」という言葉をよく耳にしませんか？一度のログインで、複数のクラウドサービス（Microsoft 365, Salesforce, Slackなど）にアクセスできる、あの便利な仕組みです。

このSSOの裏側では、「アイデンティティプロバイダー（IdP）」や「サービスプロバイダー（SP）」といった登場人物が活躍しています。そして、これらの関係性を理解する上で非常に重要なキーワードが「リライングパーティ（Relying Party）」と「トークン」です。

「言葉は聞いたことあるけど、それぞれの役割がよく分からない…」「IdPとSPって、どっちがどっちだっけ？」

今回は、そんな疑問をお持ちの方のために、SSOの心臓部とも言えるこれらの用語を、どこよりも分かりやすく解説していきます！私が情シス担当としてSSO導入に携わった経験も交えながら、セキュリティのプロの視点で深掘りしていきますね。

登場人物紹介！SSOの世界を支える3つの役割

まずは、SSOという物語の主要な登場人物をご紹介します。ここでは、分かりやすく**「巨大テーマパーク」**に例えてみましょう。

あなた（ユーザー）: テーマパークで遊びたいお客さん
アイデンティティプロバイダー（IdP）: 入場ゲートで身分証（年間パスポート）を発行・確認する「チケットセンター」
サービスプロバイダー（SP）: パーク内の個別の「アトラクション」（ジェットコースター、お化け屋敷など）

この3者の関係性が、SSOの基本となります。

アイデンティティプロバイダー（IdP）とは？ - あなたの身元を保証する「チケットセンター」

**アイデンティティプロバイダー（Identity Provider、IdP）**は、その名の通り「身元（Identity）を提供する者（Provider）」です。ユーザーのIDやパスワードといった認証情報を一元管理し、ユーザーが「確かに本人である」ことを認証・証明する役割を担います。

テーマパークの例で言えば、**年間パスポートの発行や、入場時の本人確認を行う「チケットセンター」**のような存在です。一度ここで本人確認を済ませれば、パーク内の各アトラクションでいちいち身分証を見せる必要はありませんよね。

【主なIdPの例】

Microsoft Entra ID (旧 Azure Active Directory)
Okta
Google Workspace
HENNGE One

企業では、これらのIdPを導入し、社員のID情報を一元管理することで、セキュアで効率的なアクセス管理を実現しています。

サービスプロバイダー（SP）とは？ - あなたが利用したい「アトラクション」

**サービスプロバイダー（Service Provider、SP）**は、ユーザーが実際に利用したいサービスを提供する側です。

テーマパークの例えでは、**ジェットコースターやお化け屋敷といった個別の「アトラクション」**にあたります。これらのアトラクションは、自前でお客さん一人ひとりの身元確認をする代わりに、「チケットセンター（IdP）が発行した有効なパスポートを持っているか」だけを確認します。

【主なSPの例】

Microsoft 365
Salesforce
Slack
Google Workspace（※IdPにもSPにもなり得ます）

SPは、認証という面倒な作業を信頼できるIdPに任せることで、本来のサービス提供に専念できるのです。

全体像を理解する鍵「リライングパーティ（Relying Party）」

さて、ここで本日の主役とも言える「リライングパーティ（Relying Party）」の登場です。

実は、このリライングパーティは、サービスプロバイダー（SP）の別の呼び方だと考えてください。

リライングパーティ（Relying Party）＝サービスプロバイダー（SP）

では、なぜわざわざ別の呼び方があるのでしょうか？それは、IdPとSPの関係性に注目すると見えてきます。

Relying Partyを直訳すると「信頼する側」となります。つまり、SPは「IdPが行った認証結果を全面的に信頼して（Relying）、ユーザーにサービスを提供しますよ」という立場なのです。この「信頼関係」を強調した言葉が、リライングパーティです。

IdP: 認証を行い、身元を保証する側
SP (リライングパーティ): IdPの保証を信頼して、サービスへのアクセスを許可する側

この言葉を知っていると、SSOの仕組みをより本質的に理解できます。私がセキュリティ関連のドキュメント（特にNIST SP800シリーズなど）を読む際にも頻繁に登場する重要な用語です。

信頼の架け橋「トークン」とは？ - 入場許可証の役割

IdPとSP（リライングパーティ）が信頼関係を結んでいても、ユーザーが認証済みであることをSPに伝える「しるし」がなければ、SSOは成り立ちません。その信頼の架け橋となるのが「トークン（Token）」です。

トークンは、**IdPがユーザーの認証に成功した際に発行する、電子的な「身分証明書」や「入場許可証」**のようなものです。ここには、「誰が、いつ、どのサービスを利用しようとしているか」といった情報が、改ざんされないように電子署名付きで記録されています。

テーマパークの例えで言えば、チケットセンター（IdP）で本人確認を済ませた後に受け取る**「リストバンド型の一日パス」**をイメージしてください。アトラクション（SP）の係員は、そのリストバンドを見るだけで、「この人は正規の入場者だ」と判断し、中に入れてくれますよね。

このトークン（リストバンド）があるおかげで、ユーザーは何度もパスワードを入力することなく、様々なサービス（アトラクション）をスムーズに利用できるのです。

SSOの全体的な流れ（SP-Initiated Flow）

ここまでの登場人物と道具の関係を、実際のSSOの流れに沿って見てみましょう。今回は、ユーザーがSP（アトラクション）に直接アクセスする「SP-Initiated」と呼ばれる最も一般的なフローです。

SSO

【ユーザー → SP】: ユーザーがブラウザで特定のクラウドサービス（SP）にアクセスしようとします。（「ジェットコースターに乗りたい！」）
【SP → ユーザー → IdP】: SPはユーザーが未認証であると判断し、IdPへリダイレクト（転送）させます。このとき「このユーザーの認証をお願いします」というメッセージ（SAMLリクエスト）を一緒に送ります。（「チケットセンターでパスポートを確認してもらってください」）
【ユーザー ⇔ IdP】: IdPのログイン画面が表示され、ユーザーはIDとパスワードを入力します。IdPは認証情報を検証します。（チケットセンターで本人確認）
【IdP → ユーザー → SP】: 認証が成功すると、IdPは「この人は本人です」という証明情報が入ったトークン（SAMLアサーション）を生成し、ユーザーのブラウザ経由でSPに送ります。（「確認OKです。このリストバンドを係員に見せてください」）
【SP】: SPは、受け取ったトークンを検証します。事前にIdPと交換しておいた鍵を使って、トークンが信頼できるIdPから発行されたもので、改ざんされていないことを確認します。
【SP → ユーザー】: 検証に成功すれば、SPはユーザーにサービスの利用を許可します。（「どうぞ、お楽しみください！」）