2025年11月16日·2 分
SSO のための OAuth と SAML：企業購買担当は何を期待するか
SSO 向けの OAuth と SAML を平易に解説。企業が求める要件、何を実装すべきか、既存のログインを壊さずに導入する方法までを分かりやすく説明します。
SSO 向けの OAuth と SAML を平易に解説。企業が求める要件、何を実装すべきか、既存のログインを壊さずに導入する方法までを分かりやすく説明します。
案件が「チームでのトライアル」から社内展開に移ると、SSO の要望が一気に重要になります。購入担当者はプロダクトを気に入っていても、セキュリティ部門や IT が新しいパスワードを作成させる運用や、別の場所での MFA 管理、担当者が変わったときにアカウントが残るような仕組みを嫌がると、調達が止まります。
多くの企業にとって SSO は利便性よりも「管理」の問題です。ログインルールを一元的に適用し、アクセスを素早く取り消し、監査に対してアイデンティティが中央で管理されていることを示したいのです。だから「OAuth vs SAML for SSO」の話題は商談の後半で出てきます。相手のアイデンティティ構成に合うかを手早く確認する方法だからです。
SSO を後から追加すると、既存の前提が壊れることがあります。例えば現在のモデルが「1つのメール＝1ユーザー」だとすると、SSO は共有エイリアスや複数の IdP、移行中にパスワードログインと SSO の両方を持つ必要のあるユーザーなどのエッジケースを生みます。アカウント連携が正しくないと、ユーザーがアクセスを失ったり、最悪の場合別のテナントにアクセスできてしまったりします。
SSO はオンボーディングとサポートのやり方も変えます。うまくやればパスワードリセットや「このアカウントは誰の？」といった問い合わせが減ります。下手をすると導入が止まり、管理者が怒り、トライアルでは動いていたものが本番初日に失敗して更新が危うくなります。
意思決定はめったに一人の判断だけではありません。購入担当はプロジェクトの進行を望み、セキュリティはリスクと監査をチェックし、IT 管理者は明確な設定手順を求め、エンドユーザーはスムーズなログインを望み、サポートはロックアウト、移行、例外対応を担当します。
Koder.ai のようなプラットフォームでアプリを作る場合は、顧客が既に稼働している後でアイデンティティを作り直さなくて良いよう、早めに SSO を見越した設計をしておくと役立ちます。
SSO (シングルサインオン) は、顧客が自社のアカウントであなたのアプリにログインすることを意味します。別のパスワードをあなたが管理するのではなく、会社のアカウントでサインインし、アクセスは会社のポリシーで制御されます。
企業向けの会話で出てくる主な用語は次の通りです：
「OAuth ログイン」と言うとき、多くは OpenID Connect (OIDC) を指しています。OAuth は主に認可（何かにアクセスする権限）に関する規格で、OIDC はそこに認証（誰か）を加えるものです。
SAML は古い XML ベースの SSO 規格で、企業で広く使われています。実績があり、多くの IdP がサポートし、コンプライアンスチェックリストにも載っていることが多いです。
SCIM は SSO ではありません。SCIM はプロビジョニング（ユーザーやグループの自動作成・更新・無効化）に使います。一般的な構成は、サインインに SAML または OIDC を使い、SCIM でアクセスを自動的に追加・削除する形です。
企業の購入担当はプロトコルの詳細から話を始めるわけではありません。まずはリスクと管理を確認します：「IdP からアクセスを管理できるか、誰が何をしたか証明できるか？」です。
多くの企業は少なくとも一つのエンタープライズ向けオプションを求め、多くは両方を求めます：
設定方法についても尋ねられます：メタデータやディスカバリ URL、証明書ローテーション、IT がエンジニアを待たずに自己操作できるかどうかなど。
オフボーディングが曖昧だと契約を逃します。従業員が退職したり、部署移動や端末紛失があったときにどうなるかを聞かれます。
期待される質問例：
管理者が 9:02 にユーザーを無効化し、9:03 にそのユーザーがアプリを開けないことを示せなければなりません。フローを明確に説明できないと追加の審査が入ります。
OAuth はもともと代理アクセスのために作られました：パスワードを共有せずにあるシステムが別のシステムの API を呼べるようにする仕組みです（例：カレンダー読み取りの連携）。社員ログインには多くの製品が OpenID Connect (OIDC) を使います。OIDC は OAuth の上に認証方法を標準化して追加したものです。
OIDC では、一般的に認可コードフローを使います。アプリはユーザーを会社の IdP に送ってサインインさせ、成功すると短時間有効な認可コードが返ってきます。バックエンドがそのコードをトークンと交換します。
重要なトークンの分担は次の通りです：
実務的には、OIDC はウェブ・モバイル・API パターンに合うモダンなログインに向いています。SAML は企業が従来の「アプリにサインインする」ハンドシェイクを望む場合に多く使われます。
保存する情報はシンプルに：ユーザーの安定した識別子（subject）、メール（提供される場合）、どのテナント接続を使ったか、など。ユーザーのパスワードは保存しないでください。オフラインで API にアクセスする必要がない限り、長期間有効なリフレッシュトークンを保存するのは避けてください。
テナントごとに動かすには次が必要です：
正しく行えば、ユーザーはアプリに戻り、トークンを検証して通常のセッションを作れます。認証モデル全体を書き換える必要はありません。
SAML は IdP が「この人は既にサインイン済みで、詳細はこちらです」とあなたのアプリに伝える仕組みです。IdP は SAML アサーションを送ります。これは署名付きの短い有効期間をもったメッセージで、誰がユーザーか（と場合によってはグループやロール）を含みます。
このメッセージを信頼できるようにするために、SAML はメタデータと証明書に依存します。メタデータはエンドポイントや鍵を記述する小さな設定パッケージです。証明書は主に署名に使われ、アサーションが顧客の IdP から来たこと、改ざんされていないことを確認します。
ほとんどの設定で登場する識別子は次の二つです：
どちらかが間違うと、他が正しく見えてもログインは失敗します。
実際の SAML はコードだけでなく運用も重要です。テナントレベルの SAML 設定、証明書ローテーションをダウンタイムなしで行う仕組み、数分の時刻ずれでもアサーションが壊れることがある点、管理者向けに分かりやすいエラーを出す設計（単なる「無効な応答」ではない）を計画してください。
典型的なパターンは、顧客管理者がテナントごとに SAML を有効化し、あなたのアプリが署名を検証し、アサーションの有効期限を確認し、メール（または NameID）を既存ユーザーにマップするか安全な自動プロビジョニングルールに従って処理する、という流れです。実務上、ここが OAuth vs SAML の意思決定の核心で、SAML は通常より強い管理ワークフローの構築を要求します。
OIDC と SAML の選択は主に相手がすでに何を使っているかに左右されます。多くの B2B アプリは時間をかけて両方をサポートすることになりますが、それぞれの顧客ごとに明確に選べるようにしておけば、認証システムは予測可能に保てます。
OIDC はモダンなアプリにとって滑らかな体験を提供します。ブラウザやモバイル、API と相性が良く、スコープやトークン寿命の調整など拡張やデバッグが比較的容易です。顧客がモダンな IdP 設定を使っており、IT チームが OIDC に馴染みがあるなら、まずは OIDC を勧めてください。
SAML は交渉の余地がないこともあります。多くの大企業は既存の SAML プログラムや「ベンダーは SAML のみ」というオンボーディングルールを持っています。その場合は、コントロールされた形で一度 SAML を実装し、ログインシステムの他の部分とは分離して扱うのが得策です。
決める前に聞くべきこと：
簡単な意思決定ガイド：
| 顧客がこう言ったら | 優先 | 理由 |
|---|---|---|
| "Entra ID を使っていてモダンなアプリ統合を望む" | OIDC | ウェブや API フローに適している |
| "ベンダーは SAML のみ" | SAML | セキュリティ審査を通すために必須 |
| "子会社で別々に必要" | 両方 | 大規模組織では一般的 |
| "アプリごとにカスタムクレームが必要" | どちらでも可 | 属性マッピングは両方で可能 |
両方をサポートする場合でも、アプリ内部は一貫させましょう：一つの内部ユーザーモデル、一つのセッションモデル、一組の認可ルール。SSO の方法は「このユーザーは誰でどのテナントに属するか」を返すだけで、アクセスの仕組みを作り変えるべきではありません。
まずプロダクト内で「テナント」が何を意味するか定義してください。ほとんどの B2B アプリでは SSO は組織やワークスペース単位で設定され、これが IdP 設定の保存場所や変更権限、ユーザー移動の扱いを決めます。
次に予測可能なログイン挙動を選びます。メールドメインルーティング（メールを入力させて、そのドメインが SSO 有効ならリダイレクトする）は混乱を減らしますが、請負業者やマルチドメイン企業のエッジケースを処理する必要があります。単純な「SSO で続行」ボタンは理解しやすいですが、ユーザーが間違ったオプションを選ぶこともあります。
OIDC でも SAML でも安全に作るための順序：
テストは必須です。サンドボックス IdP と現実に近いドメインを持つステージングテナントを使い、正常系と異常系（証明書期限切れ、audience 間違い、時刻ずれ、IdP からユーザーが削除されたケース）を実行してください。SSO のロールアウトは機能フラグのように扱いましょう。
Koder.ai のようなプラットフォームは、テナントごとの設定やスナップショット、ロールバックをサポートすることで、誤った変更が全顧客のアカウントをロックする事態を避ける助けになります。
SSO は単なるログインボタンではありません。セキュリティチームはセッション長、オフボーディング、インシデント発生時に何を証明できるかを聞いてきます。SSO を認証システムの中核として扱えば、多くの問題を事前に防げます。
まずセッションルールを決めましょう。アイドルタイムアウトと絶対的なセッション寿命を選び、ノートパソコンを閉じて翌日に戻ったときにどう振る舞うかを明示してください。OIDC ではリフレッシュトークンがセッションを予想以上に長くすることがあるため、回転や最大寿命を設定してください。SAML では強制再認証をかけないとブラウザセッションが長く残ることがあります。
ログアウトも注意点です。「Single logout」は普遍的ではありません。アプリ側のローカルログアウトを確実にサポートし、全アプリにまたがるグローバルログアウトは IdP の機能に依存することを明示してください。
MFA は同様です。企業は IdP による MFA を期待するので、アプリは追加で二度ログインを求めるべきではありません。ただし、データのエクスポートや課金情報の変更などリスクの高い操作にはステップアップの確認をサポートすると良いでしょう。
ユーザープロビジョニングはアクセス漏れの原因になります。JIT プロビジョニングは便利ですが、認証できる誰にでもアカウントが作られるリスクがあります。招待のみは安全ですが管理作業が増えます。多くは中間の運用で落ち着きます：ドメイン制限やグループクレームで JIT を制限するなどです。
SSO 設定は最小権限の管理下に置きましょう。証明書や IdP URL を更新するためにスーパー管理者権限が必要であってはなりません。
サポートのためには、シークレットを保存せずに単一のログインを追跡できるログが必要です：
これが「再現できません」から「数分でエンタープライズ SSO 障害を修正できる」への違いです。
中堅企業が調達チームで「契約前に SSO が必要」と言うことがあります。これは単なる哲学的な話ではなく、オンボーディング・オフボーディング・監査のための管理手段です。
さらにひねりがあります：あなたは二つのチームに売っています。チーム A は Okta とモダンな統合を前提に OIDC で問題ないと言い、チーム B はレガシーツールがあるため SAML を要求します。ここで OAuth vs SAML の議論は意味をなさなくなり、ロールアウト計画に変わります。
ルールは一つ：SSO はテナントごとのログインオプションであって、グローバルな置き換えではないこと。既存ユーザーはテナント管理者が「SSO を必須にする」までは従来通りサインインできます。
最初の SSO ログインでは安全なアカウント連携が必要です。クリーンな手法は：検証済みメールでマッチし、ドメインや招待でテナントを確認し、IdP 識別子を既存ユーザーに紐付けることです。マッチがなければ、管理者が許可していれば JIT でユーザーを作成します。
ロール割当は契約が詰まるポイントです。シンプルにしておきましょう：新規ユーザーにはデフォルトロールを与え、必要なら IdP のグループやクレームからあなたのアプリのロールにマッピングします。
管理者側が通常設定する項目：
切り替え時のロックアウトを避けるため、SSO 外のブレイクグラス管理アカウントを残し、最初の数回はテストモードで動作確認を行い、少なくとも一つの管理者セッションが動作確認されるまで SSO を強制しないでください。
多くの SSO 障害は IdP 側の問題ではなく、あなたのアプリが SSO をグローバルな単一スイッチとして扱ったときに起きます。
典型的な失敗はテナント境界の欠如です。新しい IdP 設定を保存したらそれがグローバルに適用され、最後に触った IdP に全顧客がリダイレクトされてしまう、というものです。IdP 設定は常にテナントに紐付け、SSO ハンドシェイクを始める前にテナントを解決してください。
アカウントマッチングもよくある罠です。メールだけに頼ると、重複ユーザーが生まれたり、IdP のメールが従来ログイン時のメールと異なると実ユーザーが締め出されたりします。マージポリシーを事前に定義しましょう：どの識別子を信頼するか、メール変更時の扱い、管理者がエンジニアの手を借りずに不一致を修正できる方法。
チームはクレームを過信しがちです。受け取った値は必ず検証してください：issuer、audience、署名、メールが検証済みか、あるいは安定した subject 識別子を使うこと。間違った audience や未検証メールを受け入れると、誤った人物にアクセスを与えてしまうリスクがあります。
何かが失敗したとき、曖昧なエラーは長いサポートコールを生みます。ユーザーには分かりやすいメッセージを出し、管理者には診断ヒント（例：「Audience mismatch」や「Certificate expired」）を示してください。秘密は露出させないように。
時刻関連の問題は事前テストが重要です。時刻ずれや証明書ローテーションは月曜の朝 9:00 にログインを壊します。
ほとんどの障害を防ぐ 5 つのチェック：
SSO は小さな前提が大きなサポートチケットに変わる場所です。企業に対応可能だと伝える前に、デモだけでなくプロダクト上で基本が整っているか確認してください。
以下を本番に近いステージング環境で確認しましょう：
1 回フルの「悪い日」ドリルをやってください：証明書をローテーションする、クレームを変更する、IdP URL を壊して検知と復旧が速やかにできるか確認します。
その後、テナント単位の SSO 障害を監視・アラートする体制と、練習済みのロールバック手順（機能フラグ、設定のリバート、素早いデプロイ）を確認してください。
出発点を明確に選びましょう。多くの企業は「Okta/Entra ID で SAML」か「Google/Microsoft で OIDC」を求めます。初期段階で両方を約束する必要はありません。どちらをまずサポートするか（SAML のみ、OIDC のみ、または両方）を決め、プロダクトとサポートチームにとっての「完了の定義」を書いてください。
実際の顧客を巻き込む前に小さな内部デモ用テナントを作成し、フロー全体（SSO 有効化、ログインテスト、ドメインでのロックダウン、問題発生時の復旧手順）をリハーサルしてください。ここでサポートプレイブックも実地検証されます。
企業要件を記録するドキュメントを生かしておきましょう。レビューや要求は時間とともに変わります。対応可能な内容を一箇所にまとめておけば、その場限りの約束でオンボーディングを壊すことを防げます。
実用的なシンプルプラン：
素早く進めたい場合、設定画面やテナント構造のプロトタイプを Koder.ai (koder.ai) で作り、顧客のセキュリティ質問に合わせて反復すると効率的です。
SSO の次に来ることが多い付帯機能も計画してください：SCIM プロビジョニング、監査ログエクスポート、明確な権限を持つ管理者ロール。すぐに出荷しなくても、買い手は尋ねてくるので一貫した答えを用意しておきましょう。
ほとんどの企業はアクセスを中央で管理したいと考えています。SSO により IdP 側で MFA やログインポリシーを適用でき、社員が退職したときにアクセスを素早く取り消せ、監査要件を満たせます。これによりパスワード管理をアプリ側に依存させずに済みます。
まずは相手の IdP が何をサポートしているか、ベンダー導入ポリシーで何が求められているかを確認してください。一般に OIDC はモダンなウェブやモバイルに向いており扱いやすい一方、SAML は大企業の既存運用や調達ルールで必須になることが多いです。
OIDC は OAuth の上にある認証レイヤーで、ログイン向けに設計されています。OAuth 単体は主に API へのアクセス許可（認可）を扱う仕組みです。企業 IdP でサインインを実装する場合は、ほとんどの場合 OIDC を指します。
いいえ。SSO はサインインの仕組みで、SCIM はユーザーの作成・更新・無効化を自動化するためのプロビジョニング規格です。一般的な構成は、SAML か OIDC をサインインに使い、SCIM でオフボーディングや権限変更を自動化します。
SSO 設定はテナント単位に扱い、グローバルなスイッチにはしないことです。まずドメインルーティングや招待、組織選択などで対象テナントを確定してから、そのテナントの IdP 設定で SSO ハンドシェイクを開始してください。これにより他の顧客の IdP 設定が影響することを防げます。
IdP からの安定した識別子（OIDC の sub や SAML の NameID など）を一次キーとして使い、メールは変更され得る二次属性として扱うのが安全です。最初の SSO ログイン時は、同一人物である確信とテナントの正当性がある場合のみ既存アカウントに紐付け、そうでなければ招待や管理者確認を求めます。
SSO を有効化する前に、SSO を介さずにサインインできるブレイクグラス管理者アカウントを保持してください。SSO はテナント単位で任意にしておき、管理者が動作を確認するまでは必須にしない運用が安全です。IdP 設定が壊れた場合にサポートが素早く SSO を無効化できる単一のトグルも用意してください。
アプリ内のローカルログアウトを確実にサポートし、全アプリにまたがるグローバルなサインアウトは IdP の設定に依存することを文書化しておきましょう。迅速なアクセス取り消しのためにセッション有効期限やリフレッシュトークンの最大寿命を設定し、必要に応じて再認証を要求してください。
機密情報を漏らさずに問題を特定できるログを残してください。ログにはコレレーション ID、テナント、issuer や entity ID、タイムスタンプ、署名失敗や audience 不一致、証明書期限切れなどの明確な理由コードを含めます。生のトークン、完全な SAML アサーション、クライアントシークレットや秘密鍵はログに保存しないでください。
まずはテナント単位の設定ストレージ、IdP 設定を管理する管理 UI、安全なアカウント連携ルール、ロールバック手順を実装してください。Koder.ai 上で構築する場合はテナントモデルを早めに決め、スナップショットとロールバックを使ってロールアウト中に全顧客がサインイン不能にならないようにします。