「認証（Authentication）」と「認可（Authorization）」。似ているようで全く違うこの2つの概念は、システム設計やセキュリティを考える上で避けては通れない、いわば「IT世界の関所」のような存在です。
この記事では、認証と認可それぞれの仕組みについてわかりやす例で解説します。
認証と認可の決定的な違い
認証と認可
【例え話】「遊園地」を例に考えてみるとよくわかります。
- 認証（だれ？）： 入園ゲートでのチケット確認。
- 「あなたは有効なチケットを持っている本人ですね」と確認すること。
- 「あなたは有効なチケットを持っている本人ですね」と確認すること。
- 認可（なにができる？）： アトラクションごとの身長制限や優先パス。
- 「入園はしている（認証済み）けれど、このジェットコースターに乗る権限（認可）はあるか？」を確認すること。
入園ができても、すべての乗り物に乗れるわけじゃないのが認可のポイントです。
IdPとSPの決定的な違い
認証と認可の概念が整理できたところで、認証認可と関係の深い『IdP』と『SP』について解説します。
IdPとSPについて
- IdP（Identity Provider）： ユーザー情報を一括管理し、「この人は本人です」と証明書を出す役所のような存在。
- 遊園地の外にあり、あなたの身元を確認して、「入園証（パス）」を発行してくれる場所です。
- 遊園地の外にあり、あなたの身元を確認して、「入園証（パス）」を発行してくれる場所です。
- SP（Service Provider）：ユーザーが実際に使いたいアプリ（Slack、Salesforceなど）のこと。IdPからの証明書を信じてログインを許可します。
- 遊園地のことであり遊園地に入る時にIdPが発行した「パス」をチェックします。「チケット発行所（IdP）が認めたパスを持っているから、どうぞ遊園地に入ってください」と利用を許可、拒否します。
遊園地を例に出しましたが、あなたが「Slack」にログインしようとしたときの、裏の流れは以下のようになっています。
なぜIdPとSPが存在しているのか？
この「IdPとSPを分ける」という仕組みがなぜ重要なのか。先ほどの遊園地の例えに「SSO（シングルサインオン）」という概念を加えると、そのメリットが鮮明になります。
もし提携している遊園地（SP）ごとにいちいち本人確認（認証）をしていたら、私たちは遊園地に行くたびに免許証を提示し、厳重なチェックを受けなければなりません。これはユーザーにとっても、遊園地側にとっても手間になります。
もくもく太郎ここではよくいろんな遊園地に行く人をイメージしてください。
そこで登場するのが、このIdPの仕組みです。
- IdPのメリット（一元管理）： あなたは「IdP」という信頼できる窓口で一度だけ本人確認を済ませれば、あとはそこから発行された「パス（トークン）」を見せるだけで、提携しているどこの遊園地（SP）にも自由に入れるようになります。これがSSO（シングルサインオン）です。
- SPのメリット（サービスへの専念）： 遊園地側は、ユーザーの本人確認という面倒な業務を「信頼できるIdP」に丸投げできます。結果、遊園地は「どうやってお客さんを楽しませるか（本来の機能・認可）」というサービス作りに集中できるのです。
- Microsoft Entra ID (旧Azure AD)
- Okta
- OneLogin
認証認可の流れ
実際にどのような流れで認証認可が進んでいくのかをもう少し細かく解説します。
IdP：遊園地のチケット発行所
SP：遊園地
- なぜ事前の登録が必要なのか？
- 遊園地の「チケット発行所」が、誰にでもパスを渡していたらセキュリティになりませんよね。
- 登録の目的： 発行所が「あ、この人はうちの会員（社員・顧客）の『⚪︎⚪︎』さんだ」と判断するための照合データを持っておく必要があるからです。
- メリット： 一度ここに登録してしまえば、園内の100個のアトラクション（SP）それぞれに住所や名前を登録して回る必要がなくなります。これが「一元管理」の強みです。
| 区分 | 管理場所 | 保持している主な情報 |
| IdP | チケット発行所 | ・ユーザーID（会員番号） ・氏名 / 表示名 ・メールアドレス ・所属（部署・グループ） ・役職 / 権限レベル ・パスワード（本人確認用） |
| SP | 遊園地 | ・利用可能なグループリスト ・必要な役職ランク ・個別の利用制限（例：身長、年齢） ・サービス内での固有設定 |
ただし、IdPはあくまで『あなたであること』を証明する専門家です。 実際にその遊園地の中でどの乗り物に乗れるか、VIPエリアに入れるかといった『権限（認可）』の話は、遊園地（SP）側が独自に管理しています。IdPはそこまで口出しをしない、という役割分担になっています。
EIAMとCIAMの違いについて
さらにチケット発行所のIdPには２種類あります。
- EIAM(Enterprise IAM)
- Enterprise：企業
- CIAM(Consumer IAM)
- Consumer：顧客
EIAM（従業員向け）は、自社の社員や組織メンバーを対象とした社内システム用の仕組みです。アカウントは管理者が作成・付与した特定の人物に限定され、組織の統制を目的としています。
一方、CIAM（顧客向け）は一般消費者を対象としており、ユーザー自身が自由に会員登録を行える「セルフサインアップ」を前提とした、サービス利用の入り口となる仕組みです。
| EIAM (従業員向け) | AWS IAM Identity Center |
| CIAM (顧客向け) | Amazon Cognito |
遊園地の例では誰でも会員登録ができるので、CIAMのサービスを利用したものになります。
SAMLについて
IdP（チケット発行所）とSP（遊園地）は、それぞれ別の組織が作っていることがよくあります。例えば、IdPは「会社全体で使う認証システム」、SPは「外部のSaaSアプリ」といった具合です。
この時、「バラバラのシステム同士が、どうやって認証した情報を連携すればいいのか？」という課題が出てきます。そこで登場するのがSAMLです。
SAMLを使ったログインプロセスは、IdPとSPの間で以下のような「手紙のやり取り」が行われています。
SAML Assertion（SAMLアサーション）： IdPからSPに送られる「この人は認証済みですよ」という中身のデータそのもののこと（証明書そのもの）。ルール（SAML）に従って書かれた、中身の詰まったXMLファイル。つまりSAML規格で書かれたXML形式のファイルのことをSAML Assertionと読んでいる
SAML認証： SAML Assertionを使ってSPが認証すること。
まとめ
最後にもう一度、この記事で出た重要な用語について整理します。
- 認証： 「私は〇〇という本人です」と証明する行為。
- 認可： 「あなたはここに入っていいですよ」と許可される行為。
- IdP（認証プロバイダ）： 「本人確認」を行うシステムでユーザー情報の管理役。
- SP（サービスプロバイダ）： サービスを提供し、IdPから受け取った証明書をもとに利用を許可するシステム。
多くのエンジニアが最初は混同してしまうこれらの概念ですが、認証認可を理解することで、クラウド環境のセキュリティ設計やAPI連携の仕組みが驚くほど明確に見えてきます。
この役割分担があるからこそ、私たちは安全かつ快適に、一つのIDで複数のサービスを利用できるのです。認証・認可の仕組みで迷ったときは、ぜひこの記事を振り返って、その「役割の境界線」を確認してみてください。