SaaS SSOとは？SAML・OAuth・OpenID Connectの違いとISMAPとの関係

SaaSのSSO(シングルサインオン)とは、1回のログインで複数のSaaSを追加のログインなしで使えるようにする仕組みです。実現方法は主にSAML 2.0とOpenID Connect(OIDC)の2つで、OAuth 2.0は「認証」ではなくAPIへのアクセスを許可する「認可」の仕組みです。社内の業務SaaSをまとめるならSAML、新しく開発するWebサービスやスマホアプリならOIDCが第一候補になります。この記事では3つのプロトコルの違いに加えて、代理認証などSAML以外の方式、SSOの要であるIdPを止めない運用、エンタープライズ向けSAML実装、ISMAPとの関係、導入前の確認項目、よくある失敗までを解説します。

目次

開く

閉じる

1. SaaS SSOとは｜SAML・OAuth・OpenID Connectの違い
2. SSOの実装方式は4種類｜SAML以外の方式と向く環境
3. エンタープライズSAML実装で考慮すべき技術要素
4. ISMAP対応との関係｜認証基盤と運用ルールの整合
5. グリーンフィールド開発でのプロトコル選定フロー
6. SSOを入れる前に確認したいこと｜SaaS側の対応条件とSSOで補えない範囲
7. SSO導入でよくある失敗パターン
8. SSO導入の効果をどう確認するか
9. よくある質問(FAQ)
10. まとめ
11. 参考文献

SaaS SSOとは｜SAML・OAuth・OpenID Connectの違い

SaaS SSOとは、IdP(認証を担うサービス)で1回ログインすれば、連携したSaaSをそれぞれ個別にログインしなくても使える仕組みのことです。SSOを理解するうえで最初に押さえたいのは、「認証」と「認可」の違いです。認証は「この人が誰か」を確かめること、認可は「このアプリに何をしてよいか」を許可することです。SAMLとOIDCは認証、OAuth 2.0は認可のための仕組みで、役割がそもそも異なります。

プロトコル	主な役割	データ形式	向いている用途
SAML 2.0	認証(ログイン情報の受け渡し)	XML(SAMLアサーション)	企業が社員向けに業務SaaSをまとめるSSO
OAuth 2.0	認可(APIへのアクセス許可)	アクセストークン	アプリ同士の連携、外部サービスからのデータ取得
OpenID Connect(OIDC)	認証(OAuth 2.0の上に認証機能を追加)	JSON(IDトークン、JWT形式)	新規開発のWebサービス、スマホアプリ、SPA

SSOの中心はIdP｜止まると連携先すべてにログインできなくなる

SSOでは、IdPがログインの入口をすべて引き受けます。そのため、IdPが止まると連携しているSaaSのすべてにログインできなくなります。これを単一障害点(SPOF)といいます。

IdPの持ち方は大きく2つあります。Microsoft Entra IDやOktaのようなIDaaS(認証基盤をクラウドで提供するサービス)を使う方法では、基盤そのものの運用はサービス提供側が担います。一方、IdPのソフトウェアや自社SaaSの認証機能を、自社で用意したAWSなどのクラウド上で動かす場合は、監視、障害対応、証明書の更新、利用料の支払いまでが自社の運用業務になります。夜間や休日に障害が起きたとき、誰が気づき、誰が復旧するかを決めていないと、翌朝の始業時に全員がログインできない事態になりかねません。

IdPや認証機能をAWS上で自社運用している場合の選択肢として、AWSの監視・運用を代行するサービスと、AWS利用料を円建ての請求書で支払えるようにするサービスがあります。役割の違いを表で整理します。IDaaSを使っていて認証基盤を自社で動かしていない場合は、この表は読み飛ばして構いません。

IdPや認証機能をAWS上で自社運用していて、夜間や休日の障害対応に不安がある場合の一例が、AWS監視・運用 マネージドクラウド for AWSです。GMOグローバルサイン・ホールディングス株式会社のCloudCREW byGMOが提供するAWSの監視・運用代行サービスで、24時間365日の有人監視体制をとっています。運用監視ツールはAmazon CloudWatch、Zabbix、Mackerelから選べます。注意点として、障害発生時の一次対応は手順書に沿った復旧になるため、認証基盤ならではの確認事項は契約前に相談しておく必要があります。料金はプランによって異なるため、資料や公式サイトで確認してください。

ジャスネットコミュニケーションズ株式会社は、自社サービスのWebサイトをオンプレミスからクラウド環境へ移設した際の課題として、「社内に安定的なクラウドインフラ運用に必要なノウハウが足りないこと」を挙げています。

出典: CloudCREW AWS事例紹介 ジャスネットコミュニケーションズ株式会社

自社のSaaSをAWSで提供していて、AWS利用料の支払い事務まで見直したい場合の一例が、CloudCREW AWS請求代行です。AWSの利用料を円建ての請求書で後払いできるサービスで、AWSへ直接支払う場合に必要になるドル建て決済や海外送金の手間を避けられます。東京海上日動火災保険株式会社と連携し、障害・停止や不正アクセスなどで生じた損害を補償する保険が標準で付帯します。注意点として、監視や運用サービスを使いたい場合は有料オプションの扱いになります。料金はプランによって異なるため、資料や公式サイトで確認してください。

次に、プロトコルそのものの違いを1つずつ見ていきます。

SAML 2.0は企業向けSSOの主流

SAMLは2000年代に標準化されたXMLベースのプロトコルです。IdP(Microsoft Entra ID、Oktaなど)がユーザーを認証し、その結果を「SAMLアサーション」という署名付きのXML文書にしてSaaS(SP、サービス提供側)に渡します。多くの企業向けSaaSがSAML連携に対応しており、社員が使う業務SaaSをまとめるSSOでは現在も主流です。

SAMLのログインの流れ｜SP InitiatedとIdP Initiated

SAMLによるSSOには、ログインをどこから始めるかで2つの流れがあります。SP Initiatedは、利用者がSaaSのログイン画面にアクセスし、SaaSがIdPへ認証を依頼して、認証後にSAMLアサーションを受け取る流れです。IdP Initiatedは、利用者がIdPのポータル画面でアプリのアイコンを選び、IdPから直接SAMLアサーションがSaaSへ送られる流れです。社員がブックマークからSaaSを開く運用ならSP Initiated、ポータルに業務アプリを集約する運用ならIdP Initiatedも使えるようにしておくと便利です。なお、OpenID Connectは仕様上、SaaS側からログインを始める流れが基本になります。どちらの流れでも、SSOはIdPへのログインがすべての入口になるため、IdPのアカウントが乗っ取られると連携するSaaS全体に影響が及びます。IdPへのログインには多要素認証を必ず組み合わせましょう。

OAuth 2.0は「認証」ではなく「認可」

OAuth 2.0は、ユーザーのパスワードを渡さずに、あるアプリが別のサービスのデータへアクセスすることを許可する仕組みです。たとえば「カレンダーアプリに、クラウドストレージの閲覧だけを許可する」といった場面で使われます。アクセストークンは「何をしてよいか」を示すもので、「誰がログインしたか」を保証するものではありません。OAuth 2.0だけでログイン機能を作ると、なりすましの原因になるため注意が必要です。

OpenID ConnectはOAuth 2.0に認証を加えたもの

OIDCは、OAuth 2.0の仕組みの上に「IDトークン」を加えて、ログインしたユーザーが誰かを確認できるようにした規格です。JSON形式で扱いやすく、スマホアプリやSPA(1ページで動くWebアプリ)とも相性がよいため、「Googleでログイン」などのソーシャルログインや、新しく作られるSaaSで採用が広がっています。

SSOの実装方式は4種類｜SAML以外の方式と向く環境

SSOの実装方式は、SAML認証、代理認証、リバースプロキシ、エージェントの4つに大きく分けられます。クラウドのSaaSが中心ならSAMLやOIDC、社内の古いシステムが混ざるなら他の方式を組み合わせるのが基本です。対象システムの種類によって使える方式が変わるため、先に自社のシステムを分類しておくと選びやすくなります。

方式	仕組み	向く環境	考慮したい点
SAML認証	IdPが認証結果を署名付きのXMLでSaaS(SP)に渡す	クラウドのSaaSを含む環境	連携先がSAMLのSPに対応している必要がある
代理認証(代行認証)	クライアントPCのエージェントが、対象システムのログイン画面にID・パスワードを代行入力する	WebシステムとクライアントサーバーシステムのどちらもSSOの対象にしたい環境	クライアントPCへのエージェント導入と、アカウント情報のデータベースに接続できる環境が必要
リバースプロキシ	中継サーバーで認証し、そのサーバー経由で対象システムにアクセスさせる	Webシステム。対象システム側にエージェントを入れたくない環境	アクセスが中継サーバーに集中してボトルネックになることがある。クライアントサーバーシステムは対象にできない
エージェント	対象のWebシステムごとにエージェントを導入して認証する	Webシステム。アクセス集中を避けたい環境	導入するエージェントが対象システムに対応している必要がある

4方式の仕組みと対象システムとの対応は、株式会社アシストの解説ページに整理されています。国産のSaaSや社内の独自システムはSAMLに対応していないことも多いため、非対応のシステムが残る場合は、代理認証などを併用できる製品かどうかも確認ポイントになります。

Kerberos認証とSSOの違い

Kerberos認証は、利用者とサービスがチケットを使って互いを確認し合う認証プロトコルで、IETFのRFC 4120(Kerberos V5)で規定されています。一方、SSOは「1回の認証で複数のシステムを使えるようにする」という仕組み全体を指す言葉です。Kerberosは社内ドメイン内でSSOを実現する手段として使われることが多く、クラウドのSaaSとの連携には、SAMLやOIDCが使われるのが一般的です。つまり、Kerberosは認証プロトコルの1つ、SSOはその使い方の1つという関係です。

SSOとIDaaS・多要素認証の違い

SSOは「1回のログインで複数のサービスを使う」機能で、IDaaSはそのSSOを含む認証基盤をクラウドで提供するサービスです。IDaaSにはSSOのほか、アカウントの自動作成・停止や多要素認証の機能がセットで含まれることが多くあります。多要素認証(MFA)は、パスワードに加えて別の確認手段を求める方式で、SSOの入口であるIdPのログインを守るために組み合わせます。

エンタープライズSAML実装で考慮すべき技術要素

自社SaaSを企業に提供する場合、顧客から「SAMLでSSOできるか」を問われることが多くなります。SAML対応は、ログイン画面にボタンを1つ足すだけの作業ではありません。以下の要素を設計段階で決めておく必要があります。

技術要素	考慮すべき内容
マルチテナント対応	顧客企業ごとに異なるIdPの設定(エンティティID、証明書、ログインURL)を保持し、ログイン時にどの企業のIdPへ振り分けるかを判定する
署名の検証	SAMLアサーションの署名を必ず検証し、XML署名ラッピング攻撃などの既知の脆弱性に対応した実績あるライブラリを使う
証明書の更新	IdP側の証明書には有効期限がある。期限切れで全社員がログインできなくなる事態を防ぐため、更新手順と通知の仕組みを用意する
属性マッピング	メールアドレス、氏名、部署などの属性名はIdPによって異なる。自社SaaSのユーザー情報とどう対応させるかを設定できるようにする
JITプロビジョニングとSCIM	初回ログイン時にアカウントを自動作成するJIT方式か、SCIM(RFC 7644で標準化されたID管理のプロトコル)でIdPからアカウントの作成・停止を同期するかを決める。退職者のアカウント停止を確実にするにはSCIMが有効
SSO強制とパスワードログインの扱い	SSOを有効にした企業ではパスワードログインを禁止できるようにする。ただしIdP障害に備え、管理者用の緊急ログイン経路を残す

これらを自前で一から実装すると、テストまで含めて相応のエンジニア工数がかかります。IDaaS(認証基盤をクラウドで提供するサービス)や認証ライブラリを使って実装量を減らす方法もありますが、どちらを選んでも、証明書更新や顧客ごとの設定対応といった運用は自社に残ります。

ISMAP対応との関係｜認証基盤と運用ルールの整合

ISMAP(政府情報システムのためのセキュリティ評価制度)は、政府が求めるセキュリティ要求を満たすクラウドサービスをあらかじめ評価・登録する制度です。国家サイバー統括室(NISC)、デジタル庁、総務省、経済産業省が所管し、2020年6月に運用が始まりました。政府機関はこの登録簿に載ったサービスから調達するのが原則です。また、リスクの小さい業務で使うSaaS向けに、監査の負担を抑えた「ISMAP-LIU」という枠組みが2022年11月から運用されています。

ISMAPは特定のSSOプロトコルを指定する制度ではない

誤解されやすい点ですが、ISMAPは「SAMLを使えば適合」「OIDCなら適合」といった形で認証方式を指定する制度ではありません。評価されるのは、アクセス制御、ID管理、ログの取得と保管、インシデント対応など、クラウドサービスの管理策全体が基準どおりに整備・運用されているかです。つまり、SSOを導入しただけではISMAPの要求を満たしたことにはならず、認証基盤の設定と、それを支える運用ルールの両方がそろっている必要があります。

認証基盤と運用ルールで整合させたいポイント

観点	認証基盤側の設定	運用ルール側で決めること
アカウントのライフサイクル	SCIM連携による自動停止	退職・異動時に誰がいつまでに停止を確認するか
多要素認証	IdPでの多要素認証の強制	例外を認める条件と、その承認者
特権アカウント	管理者権限の分離、緊急用アカウントの保護	緊急用アカウントを使ってよい場面と事後の記録
ログ	ログイン成功・失敗ログの取得	保管期間、定期的な確認の頻度と担当者

民間企業同士の取引でも、発注側がISMAP登録の有無を選定基準の1つにするケースがあります。自社SaaSで登録を目指す場合も、ISMAP登録済みのSaaSを導入する場合も、「設定」と「運用ルール」をセットで確認する姿勢が大切です。

グリーンフィールド開発でのプロトコル選定フロー

既存システムのしがらみがない新規開発(グリーンフィールド開発)では、プロトコルを自由に選べます。次の順番で考えると迷いにくくなります。

1. ログインするのは誰か：一般消費者が中心ならOIDC(ソーシャルログインを含む)を優先する。企業の社員が中心なら次へ進む。
2. 顧客企業のIdPはどれか：顧客がMicrosoft Entra IDやOktaなどで社員を管理している場合、SAMLとOIDCの両方に対応できるが、既存の業務SaaSとの連携実績が多いSAMLを求められることが多い。
3. どの端末から使うか：スマホアプリやSPAが中心ならOIDCが扱いやすい。
4. 他のアプリにデータを渡すか：外部サービスとのAPI連携が必要なら、ログインとは別にOAuth 2.0による認可を設計する。
5. 結論：企業向けSaaSでは、SAMLとOIDCの両方に対応しておくと、顧客側のIdPを問わず導入しやすくなる。

両方に対応するなら、最初からIDaaSや実績ある認証ライブラリを前提に設計し、プロトコルの違いを自社のアプリ本体から切り離しておくのが現実的です。ただし、選んだ仕組みを正しく設定・保守できるのは、プロトコルを理解しているエンジニアだけです。外部の開発会社に任せた場合も、社内に仕様を判断できる人がいないと、障害時や顧客からの問い合わせに対応できません。

SSOを入れる前に確認したいこと｜SaaS側の対応条件とSSOで補えない範囲

社内で使うSaaSをSSOでまとめる場合は、連携したいSaaSがSAMLやOIDCに対応しているか、アカウントの作成・停止まで自動化できるかを先に確認します。SSO製品(IDaaS)を比べるときも、次の観点で見ると違いがつかみやすくなります。

確認する観点	確認すること	確認先
対応プロトコル	SAMLかOIDCか。SP Initiated(SaaS側からのログイン開始)に対応しているか	各SaaSの管理者向けヘルプ、IdPの連携ドキュメント
利用できるプラン	SSOの設定を使えるプランか(プランによって異なる場合がある)	各SaaSのプラン表、公式サイト
アカウントの作成・停止	SCIMに対応しているか。非対応なら退職者のアカウント停止を手作業で確認する必要がある	IdPと各SaaSのヘルプ
属性の対応づけ	メールアドレス、氏名、部署などの属性名をIdPと対応づけられるか	各SaaSのSSO設定画面
IdP障害時の対応	管理者がIdPを通さずSaaSに直接ログインできる緊急経路があるか	各SaaSのヘルプ、社内の運用ルール
多要素認証	IdPの多要素認証を強制できるか。例外を認める条件は何か	IdPの管理画面、社内の運用ルール
サポートと可用性	障害時のサポート対応時間、稼働率の目安が示されているか	IdPの提供元の公式サイト

SSOだけでは管理できない範囲

SSOは認証の仕組みなので、導入すれば運用が全部楽になるわけではありません。SCIMに対応していないSaaSは、SSOを使っていてもアカウントの停止を自動化できず、棚卸しの手順に組み込む必要があります。また、IdPに登録されていないSaaS(部署が独自に契約したものなど、いわゆるシャドーIT)はSSOの対象外で、ログインが一元化されません。SaaSのライセンス数や利用状況の管理も、SSOとは別の仕組みで行います。SaaS利用全体のセキュリティの考え方は、SaaSセキュリティとは｜利用者の責任範囲とリスク・対策の基本で、API・iPaaS・Webhookなど他の連携手段との違いは、SaaS連携とは？API・iPaaS・Webhook・SSOの違いと始め方で整理しています。

SSO導入でよくある失敗パターン

SSOは、うまく動いている間は意識されず、止まったときに全社の業務に影響する仕組みです。よくある失敗と対策をまとめました。

失敗パターン(Before)	改善例(After)
OAuth 2.0のアクセストークンだけでログイン判定をしており、なりすましの余地が残る	ログインにはOIDCのIDトークンを使い、署名・発行者・有効期限を検証する
IdPの証明書が期限切れになり、ある朝から全員がSaaSにログインできなくなる	証明書の期限を一覧で管理し、期限の1か月前に更新作業を行う担当を決める
SSOを導入したが、退職者のアカウントがSaaS側に残り続ける	SCIMで自動停止を設定し、対応していないSaaSは棚卸しの手順に組み込む
IdPの障害時にログイン手段がなくなり、管理者も設定を戻せない	多要素認証で保護した緊急用管理者アカウントを用意し、使用時の記録ルールを決める
設定内容を担当者1人しか理解しておらず、異動後に誰も触れなくなる	設定手順を文書化し、複数の担当者が同じ基礎知識を学ぶ仕組みを作る
SAMLに対応していない社内システムを残したままSSOを入れ、ログインが二重になる	導入前に利用中のシステムを棚卸しし、非対応のものは代理認証など別の方式を併用できる製品を選ぶ
IdPを自社でクラウド上に動かしているが、夜間・休日の監視担当が決まっておらず、障害に翌朝まで気づかない	監視の担当と連絡経路を決める。体制を作れない場合は、監視・運用を外部に任せることも検討する

技術的な設定ミスと、運用上の抜け漏れが半々で起きている点に注目してください。SSOの安定運用には、プロトコルの知識と運用ルールの両方が欠かせません。

ここまでの失敗パターンのうち、自社に当てはまるものを数えてみましょう。

SSO導入の効果をどう確認するか

SSOは「入れたら便利になったはず」で終わらせず、導入前後で数値を比べておくと、次の投資判断や社内への説明に使えます。確認したい指標は次のとおりです。

指標	確認方法	見るべき変化
パスワード関連の問い合わせ件数	ヘルプデスクの問い合わせ記録を月単位で集計	パスワード忘れ・ロック解除の依頼が減っているか
SSO連携済みSaaSの割合	利用中のSaaS一覧とIdPの連携設定を突き合わせる	SSO対象外のまま残っているSaaSが減っているか
退職者アカウントの停止にかかる日数	退職日とアカウント停止日の差を記録	停止が当日中に完了しているか
多要素認証の適用率	IdPの管理画面で登録状況を確認	例外ユーザーが最小限に抑えられているか
SSO関連の障害件数と復旧時間	障害記録から、原因と復旧までの時間を集計	証明書切れなど防げる障害が再発していないか

最後の「障害件数と復旧時間」は、運用する人のスキルに最も左右される指標です。ログを読んで原因を切り分けられる担当者が複数いれば、復旧は早くなります。IdPや自社SaaSの認証機能をAWSなどのクラウド上で動かしている場合、夜間・休日の復旧時間は監視と障害対応の体制に左右されます。24時間365日の有人監視体制をとる代行サービスに任せる方法もあるため、自社の体制で足りるかを、障害件数と復旧時間の記録と照らして確認しておきましょう。

よくある質問(FAQ)

Q1. SaaSのSSOとは何ですか？

A. 1回のログインで、連携している複数のSaaSを追加のログインなしで使えるようにする仕組みです。IdP(認証を担うサービス)がユーザーを認証し、その結果をSAMLやOpenID Connectといったプロトコルで各SaaSに伝えます。既存のSaaSや社内システムをこの仕組みで使えるようにIdPへ連携することを、「SSO化」と呼ぶことがあります。

Q2. SAMLとOpenID Connectはどちらを選べばよいですか？

A. 社員向けに業務SaaSをまとめるならSAML、新しく開発するWebサービスやスマホアプリならOpenID Connectが第一候補です。企業向けにSaaSを提供する側は、顧客のIdPを問わず導入しやすいよう、両方に対応しておくと安心です。

Q3. OAuth 2.0でSSOはできますか？

A. OAuth 2.0は「認可」の仕組みで、ログインしたユーザーが誰かを保証するものではありません。ログイン(認証)に使う場合は、OAuth 2.0に認証機能を加えたOpenID Connectを使うのが基本です。

Q4. SSOを導入すればISMAPに対応できますか？

A. できません。ISMAPは特定の認証方式を指定する制度ではなく、アクセス制御、ID管理、ログ、インシデント対応など、クラウドサービスの管理策全体を評価する制度です。SSOの設定に加えて、アカウント停止や多要素認証の例外などの運用ルールを整える必要があります。

Q5. ケルベロス認証とSSOの違いは何ですか？

A. ケルベロス認証(Kerberos)は、チケットを使って利用者とサービスが互いを確認し合う認証プロトコルです。SSOは「1回の認証で複数のシステムを使う」仕組み全体を指す言葉で、Kerberosは社内ドメイン内でSSOを実現する手段の1つとして使われます。クラウドのSaaSとの連携には、SAMLやOIDCが使われるのが一般的です。

Q6. SSO導入で最も多いトラブルは何ですか？

A. IdPの証明書の期限切れによるログイン障害と、退職者アカウントの停止漏れがよく挙げられます。証明書の期限管理とSCIMによるアカウント同期、設定を理解する担当者を複数置くことが有効な対策です。IdPを自社でクラウド上に動かしている場合は、夜間・休日の監視体制も決めておく必要があります。

まとめ

SaaS SSOのプロトコルの違いと、導入・運用のポイントを4つに整理して振り返ります。

1. SAMLとOpenID Connectは「認証」、OAuth 2.0は「認可」の仕組み。社員向けの業務SaaSはSAML、新規開発のWebサービスやアプリはOIDCが第一候補になる。
2. 企業向けSAML実装では、マルチテナント対応、署名検証、証明書更新、属性マッピング、SCIMによるアカウント同期を設計段階で決めておく。
3. ISMAPは認証方式を指定する制度ではない。認証基盤の設定と運用ルールをセットで整え、設定を理解できる担当者を複数育てておくことが安定運用の条件になる。
4. IdPが止まるとSSO連携先すべてにログインできなくなる。IdPや認証機能をAWS上で自社運用する場合は、監視と障害対応の体制、利用料の支払い事務を決め、必要なら代行サービスの資料も確認する。

参考文献

• 国家サイバー統括室「政府情報システムのためのセキュリティ評価制度(ISMAP)」 https://www.cyber.go.jp/policy/group/general/ismap.html
• ISMAPポータル(独立行政法人情報処理推進機構 運営) https://www.ismap.go.jp/csm
• 独立行政法人情報処理推進機構(IPA)「中小企業の情報セキュリティ対策ガイドライン」 https://www.ipa.go.jp/security/guide/sme/about.html
• 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」 https://www.soumu.go.jp/main_content/000843318.pdf
• 株式会社アシスト「シングルサインオン(SSO)の選び方と仕組みの解説」 https://www.ashisuto.co.jp/cm/insight/approaches/sso.html
• IETF「RFC 7644: System for Cross-domain Identity Management: Protocol」 https://datatracker.ietf.org/doc/html/rfc7644
• IETF「RFC 4120: The Kerberos Network Authentication Service (V5)」 https://www.rfc-editor.org/rfc/rfc4120
• GMOグローバルサイン・ホールディングス株式会社「AWS事例紹介 ジャスネットコミュニケーションズ株式会社」 https://managed.gmocloud.com/case/case-jusnet.html
• Microsoft Learn「SAML と OpenID Connect: 適切な SSO プロトコルを選択する」 https://learn.microsoft.com/ja-jp/entra/identity/enterprise-apps/saml-vs-oidc-decision-guide