認証と認可の違いとは｜OAuth・SAML・SSOを発注者向けに整理

「SAML で認証、OAuth で認可、SSO 対応可能」──ベンダーの提案書にこう書かれていて、これが必要十分なのか、重複していないのか、追加見積の妥当性が評価できず困っている。そんな発注者の方は少なくないはずです。

認証・認可・OAuth・SAML・SSO は、いずれもログインや権限管理にまつわる言葉ですが、それぞれ指しているレイヤーが異なります。この違いを整理しないまま議論を進めると、ベンダーの説明を鵜呑みにするしかなくなり、RFP に何を書けばよいのか、提案書のどこを見て評価すればよいのかが分からなくなります。

本記事では、システム開発の発注を担当する情シス・DX 推進部の方に向けて、認証と認可の違いから始めて、OAuth・SAML・SSO・OIDC の守備範囲、発注ユースケース別の選定基準、RFP・ベンダー提案の評価ポイント、発注前に潰しておくべき典型的な誤解まで、意思決定に必要な粒度で整理します。

技術者向けの実装詳細（トークン形式・エンドポイント URI・HTTP リダイレクトの流れ）にはあえて踏み込みません。発注者がベンダーに主導権を渡さず、自分の言葉で要件を語り、提案を評価できる状態になることをゴールにしています。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

認証と認可の違いとは（発注者が最初に押さえる区別）

認証と認可は、しばしば同じ意味で使われがちですが、実際には別々の仕組みを指す言葉です。この2つを区別できないと、以降で扱う OAuth・SAML・SSO の話がすべて曖昧になります。まずはここを一度で固定してしまいましょう。

認証（Authentication）とは — 「誰であるか」を確認する

認証とは、ログインしようとしている人が本当にその本人であるかを確認する仕組みです。英語では Authentication（略記 AuthN）と表記されます。

身近な例で言えば、ホテルのフロントで身分証明書を提示してチェックインする場面が認証にあたります。フロントスタッフは身分証と予約情報を照合し、「この人は確かに予約者本人だ」と確認します。IT システムでは、この身分証明書に相当するのが ID とパスワードであり、多要素認証（MFA）を組み合わせる場合はスマートフォンへのワンタイムコードや指紋・顔認証が追加されます。

発注者として押さえるべきポイントは、認証は「入口の本人確認」であり、ログインした後に何ができるかまでは規定しないということです。

認可（Authorization）とは — 「何をしてよいか」を許可する

認可とは、認証によって身元が確認された利用者に対して、どのリソース（データ・機能・API）にどこまでアクセスしてよいかを決める仕組みです。英語では Authorization（略記 AuthZ）と表記されます。

同じホテルの比喩を続けると、チェックイン後に配られるルームキーが認可に相当します。ルームキーは「予約した部屋」だけを開けられ、他の宿泊客の部屋やスタッフ用エリアには入れません。IT システムでは、この「開けられる範囲」が権限（ロール／スコープ／アクセス許可）として管理されます。

たとえば同じ社内ポータルにログインしても、営業部の社員は取引先データベースを閲覧できるが、経理部の社員は閲覧できない──こうした「ログイン後の権限制御」が認可です。

両者を混同すると発注時に何が起きるか

認証と認可を混同したまま発注を進めると、実務上いくつかの典型的な問題が発生します。

1. 見積の過大化・過小化を評価できない: ベンダーが「認証基盤を構築します」と提案してきたときに、それが本人確認の仕組みだけなのか、権限管理まで含むのかが判別できず、追加見積の妥当性を判断できません
2. セキュリティ事故のリスク: 後述しますが、認可プロトコルである OAuth を認証に流用した設計を提案されると、利用者情報の漏洩リスクが生じます。認証と認可の区別ができないと、この誤設計を発注段階で見抜けません
3. 要件の抜け漏れ: 「ログインを実装してください」とだけ RFP に書いてしまい、権限管理が要件から抜け落ちる。ローンチ直前に「営業部と経理部で見える範囲を分けたい」と言い出して、追加開発が発生する

この2つの区別を持っておくだけで、以降のベンダー説明が格段に整理して聞けるようになります。

OAuth・SAML・SSO の守備範囲を1枚のマップで整理する

認証と認可の区別ができたところで、次に扱うのが OAuth・SAML・SSO の3語です。この3つは同じレイヤーの言葉ではありません。それぞれ「体験」「認証」「認可」という異なる層に属します。まずは各語の位置づけを整理し、そのうえで比較表で全体像を掴んでいきましょう。

SSO（シングルサインオン）— ユーザーが得る「体験」

SSO（Single Sign-On、シングルサインオン）は、1回のログインで複数のサービスを利用できるユーザー体験を指す言葉です。プロトコル名ではなく、実現される状態を表しています。

例えば、朝会社に着いて社内 ID で1回ログインすれば、Microsoft 365・Salesforce・Slack・自社の勤怠システムがすべて追加のログインなしで使える──これが SSO です。

ここで重要なのは、SSO は「体験」を指す言葉であり、それを実現するための技術的な仕組みは別途必要ということです。SSO を実現するためのプロトコルとして、後述する SAML や OIDC が使われます。ベンダーが「SSO 対応可能です」と言ったときに、必ずどのプロトコルで実現するのかを確認する必要があります。

SAML — 認証結果を IdP と SP で受け渡すための「認証プロトコル」

SAML（Security Assertion Markup Language、サムル）は、認証結果を安全に受け渡すためのプロトコルです。2005年に SAML 2.0 が標準化され、現在も主にエンタープライズ用途の SSO で広く使われています（OASIS SAML 2.0 標準）。

登場人物は主に2つです。

• IdP（Identity Provider）: 認証を担当するサービス（例: Microsoft Entra ID、Okta、Google Workspace）
• SP（Service Provider）: 認証結果を受け取ってサービスを提供する側（例: Salesforce、Slack、自社の業務システム）

利用者が SP にアクセスすると、SP は IdP に「この人が誰かを確認してください」と依頼します。IdP はログイン処理を行い、「この人は確かに本人です」というアサーション（署名付きの XML 文書）を SP に返します。SP はこのアサーションを検証してログインを許可します。

発注者視点で押さえるべきポイントは、SAML はエンタープライズ SaaS の SSO で事実上の標準であり、Microsoft・Google・Okta 等の主要 IdP が対応していることです。

OAuth 2.0 — 認可を委譲するための「認可プロトコル」

OAuth 2.0 は、あるサービスが持つデータへのアクセス権限を、別のサービスに安全に委譲するためのプロトコルです。2012年に RFC 6749 として標準化されました（RFC 6749: The OAuth 2.0 Authorization Framework）。

具体例で説明しましょう。あるスケジュール管理サービスに「Google カレンダーの予定を読み書きさせたい」という要件があるとします。このとき、利用者の Google パスワードをスケジュール管理サービスに渡してしまうと、そのサービスは Google アカウントの何でもできてしまい危険です。

OAuth 2.0 では、利用者は Google にログインし、「このスケジュール管理サービスに、カレンダーの読み書きだけを許可する」と同意します。すると Google はスケジュール管理サービスにアクセストークンを発行し、そのトークンで許可された範囲のみアクセスできる状態になります。

ここで重要なのは、OAuth 2.0 の主目的は認可（アクセス権限の委譲）であり、認証（本人確認）ではないということです。この点は発注時に必ず理解しておく必要があります。後ほど詳しく扱いますが、OAuth を認証に流用した設計はセキュリティリスクの温床になります。

OpenID Connect（OIDC）— OAuth の上に認証を乗せた「認証プロトコル」

OIDC（OpenID Connect）は、OAuth 2.0 の仕組みを土台にして、認証機能を追加した規格です。2014年に OpenID Foundation が仕様化しました（OpenID Connect Core 1.0）。

OAuth 2.0 だけでは「誰がログインしたのか」を安全に伝える仕組みがないため、多くのサービスが独自に OAuth を認証代わりに使ってしまう問題がありました。OIDC はこの問題を解決するため、ID トークンという利用者情報を含む署名付きトークンを OAuth の枠組みに追加しています。

Google・Microsoft・Facebook 等の「〇〇でログイン」（ソーシャルログイン）は、多くが OIDC で実装されています。エンタープライズ SSO でも、近年は SAML から OIDC への移行が進んでいます。

発注者視点では、「OAuth 対応です」と「OIDC 対応です」はまったく別の話であることを押さえておく必要があります。

3つの守備範囲マップ（比較表）

ここまでの整理を1枚の表にまとめます。

この表の重要な示唆: SSO は「実現したい状態」であり、SAML と OIDC は「それを実現する手段」です。OAuth は認可の話であり、認証や SSO とは別の目的で使われます。この分離ができれば、ベンダー提案の記述を正確に読み解けるようになります。

OAuth・SAML・OIDC の使い分け早見表（発注者視点の比較）

各プロトコルの位置づけを押さえたところで、次は発注者が意思決定に使う軸で比較していきます。技術仕様の詳細（トークン形式・エンドポイント URI・署名アルゴリズム）ではなく、「どのプロトコルを RFP に書くべきか」の判断に直結する粒度で整理します。

用途・利用者・連携相手で見る比較表

どのプロトコルが「どの発注要件」で必要になるか

比較表を発注要件から逆引きすると、以下の対応関係になります。

• 社員が複数の SaaS を1回のログインで使いたい → SSO（実装は SAML または OIDC）
• 既存の Microsoft Entra ID／Okta 等の IdP と SaaS を連携させたい → SAML が第一候補（OIDC でも可）
• モバイルアプリや SPA（シングルページアプリ）でログインさせたい → OIDC が有利
• 自社サービスから外部 SaaS の API にアクセスしたい → OAuth 2.0
• エンドユーザーに「〇〇でログイン」を提供したい → OIDC（ソーシャルログイン）

この対応関係を押さえておけば、RFP に書くべき要件と、ベンダー提案書に書かれているプロトコル名の妥当性を評価できます。

OAuth を「認証」に流用してはいけない理由（発注時に潰すべき誤解）

発注段階で最も潰しておくべき誤解が、「OAuth で認証している」設計です。

OAuth 2.0 は認可のためのプロトコルであり、認証の仕組みは含みません。それにも関わらず、「アクセストークンを取得できた＝ログイン成功」と扱ってしまうサービス設計が過去に多数存在し、実際にセキュリティ事故が報告されてきました。

問題の本質は、OAuth のアクセストークンは「本人であること」を保証していないという点にあります。トークンは他のアプリに払い出されている可能性があり、それをそのまま「ログインした人の身元」として扱うと、他人になりすます経路を提供してしまいます。

この誤解を防ぐために生まれたのが OIDC です。OIDC の ID トークンは署名付きで発行され、「誰がログインしたか」を検証可能な形で伝える役割を持っています。

発注時のチェックポイント: ベンダー提案書に「OAuth 2.0 で認証」と書かれていたら、「認証は OIDC で実装しますか？」と必ず確認してください。「OAuth だけで認証を実装している」と回答された場合は、設計の見直しを要求すべきです。

発注ユースケース別のプロトコル選定（要件から逆引き）

ここまでは「プロトコルとは何か」を整理してきました。ここからは視点を反転させ、発注者が持ち込む典型的な要件を起点に、必要なプロトコルを逆引きで示します。RFP 作成時にそのまま参照できる形にまとめます。

ユースケース1: 社内 SaaS のログインを統合したい → SSO（SAML / OIDC）

要件: 社員が Microsoft 365・Salesforce・Slack・Zoom 等の複数 SaaS を、1回のログインで使えるようにしたい。

必要なプロトコル: SSO を実現する SAML または OIDC。多くのエンタープライズ SaaS は SAML 2.0 に対応しており、Microsoft Entra ID・Okta・Google Workspace 等の IdP を中心に構築するのが一般的です。

追加検討事項:

• 既に社内で稼働している IdP（Active Directory、Entra ID 等）があるか
• 連携対象の各 SaaS が SAML と OIDC のどちらに対応しているか
• MFA（多要素認証）を IdP 側で一括制御するか
• 監査ログの一元化はどこまで必要か

ユースケース2: 取引先・顧客ユーザーが自社サービスにログインする仕組みを作りたい → OIDC or ソーシャルログイン（OAuth+OIDC）

要件: BtoB SaaS や会員制サービスで、外部ユーザー（取引先担当者や一般消費者）にログインしてもらう仕組みを構築したい。

必要なプロトコル: OIDC が第一候補。「Google でログイン」「Microsoft でログイン」等のソーシャルログインを提供する場合も OIDC が使われます。

追加検討事項:

• 自社で ID を持たせるか、外部 IdP（Google 等）に委ねるか
• パスワード管理・パスワードリセット・アカウントロック等の運用を誰が担うか
• モバイルアプリ・SPA 対応の必要性（OIDC はモバイル・SPA に強い）
• ユーザー情報のどこまでを外部 IdP から取得するか（メール・氏名・組織情報等）

ユースケース3: 外部 SaaS の API に自社システムからアクセスしたい → OAuth 2.0（認可）

要件: 自社の業務システムから Salesforce の API にデータを送りたい、Slack に通知を投げたい、GitHub の情報を取得したい等、外部サービスの API に自社システムからアクセスしたい。

必要なプロトコル: OAuth 2.0。ここでは「認可の委譲」が主目的です。

追加検討事項:

• どの「フロー」（Authorization Code / Client Credentials 等）を使うか
• アクセストークンの保管・更新の仕組み
• スコープ設計（何を許可するか）
• サービス間連携か、利用者の同意を得る連携か

ユースケース4: 退職者アカウントを SaaS 横断で一元停止したい → SSO＋SCIM（プロビジョニング連携）

要件: 社員が退職した際、各 SaaS のアカウントを個別に停止するのではなく、社内 IdP でアカウントを無効化すると全 SaaS で使えなくなるようにしたい。

必要なプロトコル: SSO（SAML / OIDC）に加えて、SCIM（System for Cross-domain Identity Management）というプロビジョニング用のプロトコル。SCIM 2.0 は 2015年に RFC 7643／7644 として標準化されています（RFC 7643: SCIM Core Schema）。

SSO だけでは「ログイン時の連携」しか行えず、退職者アカウントの削除は各 SaaS に手動反映が必要になります。SCIM を組み合わせることで、IdP でのユーザー作成・更新・削除が SaaS 側に自動反映され、退職者アカウントを IdP 側で無効化するだけで各 SaaS のアクセスも遮断できます。

追加検討事項:

• 連携対象の各 SaaS が SCIM に対応しているか（対応状況は SaaS ごとに異なる）
• 退職者以外にも異動・改名・組織変更の反映が必要か
• 手動プロビジョニングとの併用範囲

選定を誤りやすい注意点

上記の逆引きを進める際、以下の点を必ず確認してください。

1. 既存 IdP との整合性: 社内に既に Active Directory・Entra ID 等の IdP がある場合、それを起点に設計しないと二重管理になります
2. 各 SaaS の対応プロトコル制約: 「SAML 対応」と書かれていても、SAML 2.0 のどの機能まで対応しているかは SaaS ごとに異なります。SCIM 対応は特にばらつきが大きいです
3. 有償プラン制約: 主要 SaaS では SAML/SSO 対応が上位プランに限定されているケースが多く、SSO 導入コストが SaaS のプランアップ費用を伴うことがあります（いわゆる「SSO Tax」問題）
4. モバイルアプリ・API連携での SAML の限界: SAML はブラウザリダイレクトが前提のため、モバイルアプリや API 中心の連携では OIDC・OAuth が現実的です

RFP・ベンダー提案の評価ポイント（発注者のチェック観点）

要件からプロトコルを選定できるようになったら、次はそれを RFP に落とし込み、ベンダー提案を評価するフェーズです。ここでは「発注者側が主導権を持つ」ためのチェック観点をまとめます。

RFPに書くべき認証・認可要件

RFP に以下の項目を明示することで、ベンダー間の比較可能性が上がり、後からの追加見積を抑制できます。

発注者側が主導する RFP の書き方のコツ: 「認証機能を実装してください」ではなく、「Entra ID を IdP として SAML 2.0 で Salesforce・Slack と SSO 連携し、SCIM 2.0 でプロビジョニングを自動化する」とプロトコル名と連携先を具体化します。これにより、ベンダーは同じ土俵で見積もり、比較可能な提案が返ってきます。

ベンダー提案書で必ず確認する4つのポイント

ベンダー提案書を受け取ったら、以下の4点を必ず確認してください。

1. プロトコル名と役割が正確に区別されているか: 「SAML で認証、OAuth で認可、SSO 対応可能」と書かれている場合、認証は SAML、API 連携（認可）は OAuth、SSO はその結果として実現される体験、という3層が整合しているかを確認します。「OAuth で認証」等の誤用がないかもチェックポイントです
2. 既存 IdP との連携方針が明示されているか: 社内に既存 IdP がある場合、それを活かす提案か、別の IdP を立てる提案かで工数が大きく変わります
3. 連携対象 SaaS の対応可否が事前確認されているか: 「Salesforce と SSO 連携」と書かれていても、そのプラン・機能で本当に SAML/SCIM が使えるかは事前確認が必要です。ベンダー側で確認済みか、発注後に確認するかを問い合わせてください
4. 監査ログ・MFA・SCIM の実装範囲が具体的か: これらは「対応」の一言で片付けられがちですが、実装コストに大きく影響します。監査ログの保持期間・エクスポート形式、MFA の対象操作、SCIM の対応イベント（作成・更新・削除）まで具体化されているか確認します

見積の妥当性を判断する観点

見積書を評価する際は、以下の観点で内訳を確認します。

• 認証基盤の初期構築費: IdP の設計・SP との連携設定・テストにかかる工数。連携先 SaaS の数に応じて増える
• プロトコル別の追加費用: SAML 対応と OIDC 対応で工数が異なる場合が多い（SAML のほうが XML 署名検証等で複雑になる傾向）
• SCIM 対応の追加費用: SCIM は SaaS ごとに対応状況が異なるため、対応する SaaS の数と種類で工数が大きく変動
• SaaS 側のプラン費用: 「SSO 対応は Enterprise プラン以上」等の制約により、SaaS 側の月額費用が上乗せされる（RFP の総コスト評価時に含める）
• 運用フェーズの費用: 新規社員追加・退職者削除・SaaS 追加時の運用コストが月額でどのくらいかかるか

見積の落とし穴: SSO 基盤の構築費だけを比較すると、SaaS 側のプランアップ費用や SCIM 対応の追加費用が見えにくくなります。総所有コスト（TCO）で3年間ベースで比較すると、実態が見えやすくなります。

なお、SSO 単体の導入判断・製品選定チェックリストについてより深く知りたい場合は、シングルサインオン（SSO）とは｜発注判断5つの基準と選び方チェックリストを参照してください。

よくある誤解と発注時に潰しておくべきチェック観点

最後に、発注実務で頻発する典型的な誤解を整理します。発注段階でこれらを潰しておくことが、後々のトラブル回避に直結します。

誤解1「OAuth で認証している」設計を渡された場合の指摘ポイント

すでに触れた話ですが、発注時の重要度が高いので改めて整理します。

症状: 提案書に「Google の OAuth を使ってログインを実装します」と書かれている。

問題: OAuth 2.0 は認可プロトコルであり、認証には不向きです。アクセストークンの取得成功をログイン成功と扱うと、他アプリ経由でトークンを取得された場合になりすましのリスクが生じます。

指摘ポイント: 「Google の OIDC（OpenID Connect）を使って認証してください」と要求してください。OIDC であれば ID トークンで「誰がログインしたか」が検証可能な形で伝わります。ベンダーが「OAuth と OIDC は同じ」と回答してきた場合は、別のベンダーの意見も聞くことを推奨します。

誤解2「SSO＝SAML」で他プロトコル対応 SaaS と連携できないケース

症状: SSO 導入プロジェクトを「SAML で統一する」と決めた後、連携予定の SaaS の一部が OIDC のみ対応と判明する。

問題: SSO は SAML でも OIDC でも実現できます。SaaS の側で「OIDC のみ対応」「SAML のみ対応」「両方対応」がまちまちです。SAML 一択で設計を進めると、後から OIDC 対応 SaaS を追加する際に IdP 側で OIDC 対応機能の追加・費用増が発生することがあります。

チェック観点: RFP 段階で連携予定の全 SaaS の対応プロトコルを一覧化し、「IdP 側で SAML と OIDC の両方に対応する必要があるか」を判断してください。主要 IdP（Entra ID・Okta 等）は両対応が基本ですが、簡易 SSO 製品では片方のみ対応のものもあります。

誤解3「認可プロトコルなのに認証情報を漏洩」させる実装の見抜き方

症状: OAuth 2.0 を使った API 連携で、アクセストークンに利用者の氏名・メールアドレス等の個人情報が含まれる設計。

問題: アクセストークンは API 呼び出しのたびに送信されるため、複数のシステム間を流通します。トークン内に個人情報を含めると、本来アクセスすべきでないシステムにも情報が漏れる経路になります。

チェック観点: ベンダーに「アクセストークンには何の情報が含まれるか」を確認してください。利用者情報を扱う場合は、別途 UserInfo エンドポイント（OIDC）で必要時に取得する設計が正解です。「トークンに全情報を入れておけば1回の通信で済むので便利」という説明を受けた場合は、セキュリティレビューの追加を要求してください。

発注前チェックリスト（社内で確定させる7項目）

RFP 発行前・ベンダー選定前に、以下の7項目を社内で確定させておくと、ベンダー選定の精度が上がります。

• 1. ユースケースの言語化: 「何を実現したいか」を発注者の言葉で1〜2文にまとめる
• 2. 認証と認可の分離: 要件のうち「本人確認（認証）」と「権限管理（認可）」を分けて整理する
• 3. 既存 IdP の棚卸し: 社内で稼働している IdP・ディレクトリサービスをすべて列挙する
• 4. 連携対象 SaaS の対応プロトコル確認: 各 SaaS の SAML／OIDC／SCIM 対応可否と有償プラン要件を確認する
• 5. MFA・監査ログの要件: セキュリティポリシー・コンプライアンス要件（個人情報保護法・ISMS 等）に照らして必要事項を洗い出す
• 6. プロビジョニング要件: 入退社・異動時の運用フローを整理し、SCIM 自動化の必要性を判断する
• 7. 総所有コスト（TCO）の試算前提: 3年間の TCO 比較を行う前提条件（社員数の増減見込み・連携 SaaS の追加予定）を確定する

このチェックリストを事前に整理することで、ベンダーからの提案を同じ土俵で比較でき、追加見積の妥当性判断もしやすくなります。認証・認可・OAuth・SAML・SSO──それぞれの守備範囲を発注者自身が理解して要件を語れる状態になれば、ベンダーに主導権を握られる状態から脱却できます。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。