シングルサインオンを自社Webサービスに組み込むには｜認証サービスの選び方

シングルサインオン（SSO）は、1回のログインで複数のWebサービスを使えるようにする仕組みです。利用者は、サービスごとにIDとパスワードを入力しなくて済むようになります。

SSOについて調べると、社内で使うクラウドサービスにSSOを導入する話が多く見つかります。

この記事でわかることは、次のとおりです。

• SSOの仕組みと、ソーシャルログインとの違い
• 自社サービスにSSOを組み込むメリットと注意点
• SAMLとOIDCのどちらに対応するかの目安
• 認証サービスを使うか自社で作るかの考え方と、認証サービスを選ぶときの観点

料金などの情報は、2026年10月時点の各社の公式情報にもとづいています。

シングルサインオン（SSO）とは

この章では、SSOの基本的な仕組みと、混同されやすい言葉との違いを整理します。

1回のログインで複数のWebサービスを使える仕組み

SSOを使うと、利用者は1回本人確認（IDとパスワードの入力など）を済ませるだけで、利用を許可された複数のアプリを、改めてログインせずに開けるようになります。

出典：Microsoft「What is single sign-on in Microsoft Entra ID?」

たとえるなら、建物の受付で一度身分証を見せて入館証をもらえば、中の各部屋では入館証を見せるだけで入れるようなものです。各部屋が毎回身分証を確認する必要はありません。

認証する側（IdP）とサービス側の役割分担

SSOでは、「本人かどうかを確認する役割」と「サービスを提供する役割」を分けて考えます。

• IdP（アイデンティティプロバイダー）：利用者が本人かどうかを確認する側です。Microsoft Entra IDや、Googleが提供するログインの仕組みなどがこの役割を担います。
• サービス側：自社のWebサービスや業務システムです。本人確認をIdPに任せ、受け取った結果を確かめます。そのうえで、その利用者にどの機能やデータを使わせるか（権限）を自社で判断します。仕様によって「RP（リライングパーティー）」や「SP（サービスプロバイダー）」と呼ばれます。

OpenID Foundation（OpenID Connectという規格を管理する団体）は、サービス側を「利用者の認証をIdPに任せるアプリやWebサイト」と説明しています。また、この仕組みを使うと、各サイトがパスワードを設定・保存・管理する負担がなくなる点を利点に挙げています。

出典：OpenID Foundation「How OpenID Connect Works」

ログインの流れは、前述のMicrosoftの解説では次の4段階で説明されています。

1. 利用者が自社のサービスを開く
2. サービスが利用者をIdPのログイン画面へ移動させる
3. IdPが本人かどうかを確認する
4. IdPが本人であることをサービスに伝え、サービスが利用を許可する

SAMLやOIDCを使う方式では、自社サービスはパスワードを受け取らず、IdPから届いた「本人である」という結果を確かめます。本人かどうかの確認（認証）とは別に、その利用者が何をしてよいか（認可）は、自社サービス側で判断します。

ID連携・ソーシャルログインとの違い

SSOとソーシャルログインは、よく似ていますが同じ意味ではありません。SSOは「1回のログインで複数のサービスを使える」仕組みを指す言葉です。ソーシャルログインは、Googleなどの外部のアカウントを使ってログインする方式を指します。両者は重なることもあり、Googleのアカウントで複数のサービスにまとめてログインできるようにすれば、ソーシャルログインでSSOを実現していることになります。

• ソーシャルログイン：利用者が個人で持っているGoogleなどのアカウントで、自社サービスにログインできるようにする方式です。一般消費者向けの会員サービスでよく使われます。
• 企業向けのSSO：利用者が勤める会社が管理する社員用のIDで、その会社が使う複数のサービスにまとめてログインできるようにします。退職などで会社側がIDを止めると、そのIDでは新たにログインできなくなります。ただし、自社サービス側のアカウントやログイン中の状態が、すぐに無効になるとは限りません。

どちらも「ID連携（異なるサービスの間で本人確認の結果を受け渡すこと）」の一種です。自社サービスでどちらを使えるようにするかによって、必要な規格や費用が変わります。

「社内にSSOを導入する」と「自社サービスに組み込む」は別の話

SSOの情報を探すときは、自分がどちらの立場かを先に確認しておくと、必要な情報を見分けやすくなります。

この記事では、後者の「自社サービスに組み込む」立場で説明を進めます。

自社サービスにSSOが求められる2つの場面

自社サービスにSSOを組み込む理由は、大きく分けて次の2つです。どちらに当てはまるかで、対応すべき規格や選ぶ認証サービスが変わります。

取引先企業の社員に、その会社のIDでログインしてもらいたい

企業向けのWebサービスや業務システムを提供している場合、導入先の企業から「自社の社員用IDでログインできるようにしてほしい」と求められることがあります。

前述のMicrosoftの解説では、自社のアプリを企業に提供する事業者にとって、SSOはアプリを企業顧客に向いた製品にするものだと説明されています。企業の購入担当者がSSOを求めることは多く、対応していることが他社との違いにもなるとしています。

利用企業にとっては、社員のログイン用のIDを自社でまとめて管理できる利点があります。サービス提供者にとっては、取引先のIdPでログインする利用者のパスワードを、自社で保存・管理しなくて済む利点があります。ただし、自社サービスの中のアカウントや権限を、取引先側の変更とどう揃えるかは別に設計する必要があります。

自社の複数サービスを1つのIDで使えるようにしたい

自社で複数のWebサービスを運営している場合、サービスごとに会員登録が必要だと、利用者の手間が増えます。会員IDを1つにまとめれば、共通のログインの仕組みに対応したサービスを、利用者に許可された範囲で、改めてログインせずに使えるようになります。

社内向けの業務システムでも同じです。複数のシステムを自社で作っている場合、ログインを1か所にまとめると、社員が使うIDとパスワードを減らせます。

この場面では、取引先のIDではなく、自社で管理する会員IDを共通の土台にするのが一般的です。既存の会員データをどこにまとめるかが、計画の中心になります。

自社サービスにSSOを組み込むメリットと注意点

SSOを組み込むと、利用者・取引先・自社のそれぞれに利点があります。一方で、費用や運用の面で事前に考えておくべき点もあります。

メリットは、前述のMicrosoftとOpenID Foundationの解説で挙げられている内容をもとに整理しています。注意点への対策は、この後の章で順に説明します。

シングルサインオン（SSO）を実現する方式

SSOにはいくつかの実現方式があります。自社サービスに組み込む場合は、標準の規格を使う方式が基本になります。

主な5つの方式

一般によく挙げられる方式を、表にまとめます。呼び方や分け方は、製品や資料によって少しずつ異なります。

これらは、同じ基準で分けたものではありません。フェデレーション方式は標準の規格を使う方式で、後ろの4つは、主に規格に対応していない社内の既存システムに使われる構成です。

自社サービスに組み込むなら標準規格（SAML・OIDC）が基本

自社サービスにSSOを組み込む場合は、フェデレーション方式を選ぶのが基本です。前述のMicrosoftの解説でも、フェデレーション方式は最も充実した連携ができる方式とされています。

理由は、相手側のIdPが標準の規格に対応しているためです。取引先企業が使っている社員用のIDの仕組みや、Googleなどのアカウントは、SAMLやOIDCで本人確認の結果を受け渡せます。自社サービスがこの規格に対応していれば、相手ごとに独自の認証方式を開発せずに済みます。ただし、取引先ごとの接続の設定や動作の確認は必要です。

SAMLとOIDCのどちらに対応するか

SAML（サムル）とOIDC（OpenID Connect）は、どちらもIdPからサービスに本人確認の結果を安全に渡すための規格です。Microsoftは、両者の違いを次のように比べています。

出典：Microsoft「SAML versus OpenID Connect: Choose the right SSO protocol」

この比較は、Microsoftが示している一般的な傾向です。実際の開発の難しさや対応できる範囲は、使う部品（ライブラリ）や、連携先のIdPの仕様によって変わります。

前述のOpenID Foundationの解説でも、SAMLはWebで使うことを前提に作られた規格で、OIDCはスマホアプリにも対応するよう作られたと説明されています。両者は当面共存するとの見方も示されています。

同じMicrosoftの資料では、選び方の目安を次のように示しています。

• OIDCが向いている：新しくクラウドで動くサービスを作る場合、スマホアプリを含む場合、新しいIDの仕組みを使う企業が主な顧客の場合
• SAMLが向いている：SAMLを求める企業顧客がいる場合、取引先がSAMLにしか対応していない場合、調達の条件でSAMLが指定されている場合
• 両方に対応する：両方の顧客がいる場合

迷う場合、新しく作るサービスではOIDCを基本にするよう勧めています。ただし企業向けのサービスでは、商談の中でSAMLへの対応を求められることもあります。主な顧客がどちらを使っているかを、先に確認しておくことをおすすめします。

組み込み方は「認証サービスを使う」か「自社で作る」か

SSOを組み込む方法は、大きく分けると、外部の認証サービスを使うか、認証の仕組みを自社で作る（運用する）かの2つです。「自社で作る」には、自社サービスから取引先のIdPへ直接接続する機能を作る方法と、オープンソース（公開されていて誰でも使えるソフト）の認証基盤を自社で運用する方法があります。ここでは費用の仕組みと、自社で作る場合の注意点を整理します。

認証サービスを使う場合の費用の仕組み

認証サービスとは、ログインや本人確認の仕組みをクラウドで提供するサービスです。認証の仕組みを一から作らずに、SSOやソーシャルログインを導入できます。ただし、認証サービスとの接続や、既存の会員アカウントとの紐付けなどの開発は必要です。

多くの認証サービスは、MAU（月間アクティブユーザー：その月にログインなどをした利用者の数）にもとづいて料金が決まります。登録している会員の総数ではなく、その月に実際に使った人数で数える点が特徴です。ただし、SMSによる認証などの追加機能や、上位プランでしか使えない機能によって、別に費用がかかる場合もあります。使う予定の機能を含めて試算することが大切です。

主なサービスの無料枠は次のとおりです（2026年10月時点）。

出典：AWS「Amazon Cognito pricing」、Auth0「Pricing」、Microsoft「Microsoft Entra External ID pricing」

注意したいのは、Amazon Cognitoのように、SAMLやOIDCで連携する利用者の料金を別に設定しているサービスがあることです。企業向けにSSOを提供すると、通常の会員より早い段階から費用がかかり始める場合があります。料金は改定されることがあるため、検討の時点で各社の公式ページを確認してください。

自社で作る場合に必要になる確認項目

認証の仕組みを自社で作れば、認証サービスへの利用料はかかりません。ただし、サーバーなどの費用や、保守・障害対応の人件費はかかります。また、安全に動かすための確認作業を自社で担うことになります。

この章でいう「自社で作る」は、主に、取引先のIdPから届いた結果を受け取って確かめる側（サービス側）の機能を作ることを指します。本人確認を行うIdPそのものを作ることとは別の話です。IdPに当たる仕組みも自社で持つ場合は、前述のオープンソースの認証基盤を使うなどの方法があります。

Webアプリの安全性に関する指針を公開している団体OWASPは、SAMLの処理には確認すべき手順が非常に多く、抜けが起きやすいと指摘しています。サービス側で確認すべき項目として、たとえば次のようなものが挙げられています。

出典：OWASP「SAML Security Cheat Sheet」

• 受け取った本人確認の結果に、正しいIdPの署名（改ざんされていないことを示す印）があるか
• その結果が、自社サービス宛てに発行されたものか
• 有効期間内のものか
• 同じ結果を使い回されていないか

このほか、署名を確かめた部分と、実際にログインの判断に使う部分が一致しているかを確かめることも挙げられています。これらは、実績のある部品（ライブラリ）を使えば負担を減らせます。自社で作る場合も、すべてを一から書くのではなく、こうした部品を組み合わせて作るのが一般的です。それでも、署名に使う鍵の更新や、障害時の対応といった運用は自社に残ります。

OIDCを使う場合も、受け取った結果を確かめる処理は欠かせません。OWASPは、OIDCの土台であるOAuth 2.0について、認可コードの横取りを防ぐ仕組み（PKCE）をすべての種類のアプリで使うことや、使い回しを防ぐための値（nonce）を使うこと、発行元（iss）を確かめることなどを推奨しています。

出典：OWASP「OAuth2 Cheat Sheet」

比較表：認証サービスと自社開発

2つの方法の違いをまとめると、次のようになります。

認証サービスでは、利用者が無料枠を超えて増えると、月額費用が増えます。どこから費用が増えるかは、料金プランによって異なります。一方で、自社で作る場合は安全性の確保に継続して手間がかかります。どちらが合うかは、想定する利用者数、求められる規格、社内に運用を担える人がいるかによって変わります。

どちらの方法が自社に合うか判断に迷う場合は、開発会社に要件を伝えて相談するのも一つの方法です。弊社オプスインでも、Webサービスや業務システムの開発について、要件の整理の段階からご相談を受け付けています（お問い合わせはこちら）。

認証サービスを選ぶときに確認したい4つの観点

認証サービスを使うと決めた場合、機能の多さだけで選ぶと、後から費用や移行で困ることがあります。ここでは、自社サービスに組み込む立場で確認しておきたい4つの観点を挙げます。

1. 料金の数え方

まず、何を基準に料金が決まるかを確認します。前述のとおり、多くのサービスはMAUで料金が決まります。ただし、何をもって「使った」と数えるか、どの利用者が別料金になるかはサービスごとに異なります。

たとえばAmazon Cognitoの料金ページでは、ログインやログアウトのほか、ログイン状態の更新なども、その月に使った利用者として数える対象に挙げられています。また前述のとおり、SAMLやOIDCで連携する利用者には、通常の利用者とは別の無料枠が設定されています。プランによっては単価も異なります。

見積もりでは、次の2つを分けて試算しておくと、実際の請求との差が出にくくなります。

• 自社で会員登録した利用者や、ソーシャルログインの利用者の数
• 取引先企業のIDでSSOログインする利用者の数

2. 企業向けSSO（SAML接続）がどのプランで使えるか

取引先企業ごとのIdPと接続する機能は、プランによって使える数や範囲が違うことがあります。たとえばAuth0では、無料プランに企業向けの接続が1つ含まれており、接続数や関連する機能はプランごとに異なります。また、一般消費者向け（B2C）の有料プランで企業向けの接続を使い続けるには、企業向け（B2B）のプランが必要とされています。自社の複数のアプリの間でSSOを行う機能（Cross App SSO）は、料金ページの比較表では無料プランとEssentialsプランに含まれていません。

取引先が増えるたびに接続を追加する場合、どの時点で上位のプランが必要になるかを、事前に確認しておきましょう。

3. 会員データを後から移せるか

自社の会員を認証サービスで管理する場合、会員のログイン情報や、メールアドレスなどの基本的な情報は、そのサービスの中に保存されます。後から別のサービスに乗り換えるときは、それらを取り出して移す作業が必要です。一方、取引先企業のIdPでログインする利用者のパスワードは取引先側で管理されるため、自社側には保存されません。

Auth0の料金ページのよくある質問では、利用をやめる場合に会員データを書き出す方法が案内されています。ほかのサービスを検討するときも、会員データをどの形式で、どこまで取り出せるかを確認しておくと安心です。パスワードの扱いなど、移行できる範囲には制約がある場合もあるため、具体的な条件は提供元に確認してください。

4. データの保存場所

会員の情報をどの国のサーバーに保存するかを、取引先から確認されることがあります。Microsoft Entra External IDには、外部の利用者のデータの保存先を、日本またはオーストラリアに限定できる追加機能（Go-Local）が用意されています。対象となるデータの範囲や条件は、公式の資料と契約条件で確認してください。

保存場所を選べるかどうか、選ぶ場合に追加の費用がかかるかは、サービスごとに異なります。取引先の求める条件を先に確認したうえで、サービスを比べることをおすすめします。

組み込む前に決めておきたいこと

SSOは便利な一方で、ログインの入口を1か所に集める仕組みです。組み込む前に、次の3点を決めておくと、運用を始めてからの手戻りを減らせます。

認証の仕組みが止まったときの影響

SSOでは、本人確認をIdPや認証サービスに任せます。そのため、そこが止まると、連携しているサービスすべてで、新たにログインできなくなるおそれがあります。

対策として、利用する認証サービスのサービスレベル契約（SLA：稼働率の目標と、下回った場合の扱いを定めた取り決め）を確認しておきます。たとえばAmazon Cognitoでは、月間の稼働率99.9%以上を目標とするサービスレベル契約が定められています。これは、下回った場合に以後の利用料から差し引く（サービスクレジット）条件を定めたもので、止まらないことを約束するものではありません。

出典：AWS「Amazon Cognito Service Level Agreement」

なお、すでにログイン中の利用者がそのまま使い続けられるかは、自社サービス側のログイン状態の管理方法によって異なります。障害が起きたときに利用者へどう知らせるか、管理者がどうログインするかも、あらかじめ決めておくと安心です。

あわせて、入口が1つになる分、その入口を破られたときの影響も大きくなります。管理画面を含めた多要素認証（パスワードに加えて別の確認方法を求める仕組み）などの基本的な対策は、「新規事業のアプリセキュリティ超入門」で紹介しています。

株式会社オプスイン

新規事業のアプリセキュリティ超入門｜“リリースと成長”を止めないための3ステップ

🕒️2026年2月17日

新規事業はスピードが命。ただ、セキュリティが弱いとストアの審査や外部の確認（ストア/顧客/パートナー）で止まり、事故なら販売停止や信頼低下につながります。本記事は、今日から決められる5つの方針と、3ステップで進める方法を解説します。B2B/B2Cどちらでも使える基本形です。 1. セキュリティは事業の必須条件アプリは「動くかどうか」だけでは評価されません。「安心して使い続けられるか」が問われます。B2Cではストア審査やプライバシー表示の不備が差し戻しや低評価につながり、B2Bでは顧客やパートナーからの質問票...

SSO機能を自社サービスのどの料金プランに含めるか

企業向けにSSOを提供する場合、その機能をどの料金プランで使えるようにするかを決める必要があります。

米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）は、SSOは追加料金なしの基本機能として提供されるべきだと提言しています。その背景として、SSOが上位の企業向けプランでしか使えないことが多く、中小企業が導入を見送る大きな理由になっている点を挙げています。

出典：CISA「Why SMBs Don’t Deploy Single Sign On (SSO)」、2024年6月

一方で、前述のとおり、認証サービスによってはSSOで連携する利用者ごとに費用がかかります。顧客が求めることと、自社にかかる費用の両方を見たうえで、どのプランに含めるかを決めることになります。

退職者や退会者のアカウントの扱い

SSOでログインしている利用者が取引先企業を退職すると、そのIDでは新たにログインできなくなります。ただし、自社サービスの中に作られたアカウントや、その人のデータまで自動で消えるとは限りません。

ログインできなくなった利用者のアカウントやデータを、いつ、どのように整理するか。取引先との契約や、自社サービスの利用規約とあわせて決めておきましょう。

アカウントの作成・更新・停止を取引先側の変更と自動で連動させたい場合は、SCIM（アカウント情報を自動で連携するための標準規格）への対応も検討すべきです。SSOはログインの仕組みなので、それだけでは自社サービスの中のアカウントの停止までは連動しない場合があるためです。Microsoftは、SCIMをSAMLやOIDCと組み合わせることで、アカウントの管理まで含めた仕組みになると説明しています。

出典：Microsoft「Microsoft Entra IDでのアプリ プロビジョニングとは」

開発会社に相談する前に整理しておくこと

SSOの組み込みを開発会社に相談する場合、次の情報がそろっていると、方式の選定や見積もりが進めやすくなります。完璧でなくても、わかる範囲で構いません。

• 誰がログインするか：自社の会員か、取引先企業の社員か、その両方か
• どのIDでログインさせたいか：取引先が使っているIDの仕組み、Googleなどのアカウント、自社の会員IDなど
• 求められている規格：取引先からSAMLやOIDCを指定されているか
• 想定する利用者数：毎月どのくらいの人が使う見込みか（現在と、数年後の目安）
• 既存の会員データ：すでに会員がいるか、そのデータがどこにあるか
• 時期と予算：いつまでに使えるようにしたいか、予算の上限があるか

これらは、開発の前に行う要件定義（何を作るかを開発会社と決める工程）で確認する内容の一部です。進め方は「要件定義の進め方｜7つのステップと各段階のポイント」で詳しく説明しています。

株式会社オプスイン

要件定義の進め方｜7つのステップと各段階のポイント

🕒️2026年7月10日

システムやアプリの開発を依頼する際、要件定義はどのように進めるべきか理解することも必要です。本記事では実務の流れに焦点を当てて解説します。 要件定義は、依頼側と開発会社が一緒に作り上げていくプロセスです。専門的な技術判断は開発会社が担いますが、業務の実態や解決したい課題については、依頼側からの情報提供が欠かせません。この記事を通じて、各ステップで何が行われ、どのような準備や確認が必要なのかを把握していただければと思います。要件定義についての解説記事は以下でご覧ください。 要件定義の全体像...

よくある質問

Q. SSOとソーシャルログインは同じものですか？

A. 同じ意味ではありません。SSOは1回のログインで複数のサービスを使えるようにする仕組み、ソーシャルログインはGoogleなどの外部のアカウントでログインする方式を指し、両者が重なる場合もあります。認証サービスによっては、この2つで料金の扱いが異なります。

Q. 自社サービスがSAMLに対応していないと、商談で不利になりますか？

A. 前述のMicrosoftの解説では、企業の購入担当者がSSOを求めることは多いとされています。ただし、求められる規格がSAMLかOIDCかは取引先によって異なります。主な顧客がどちらを使っているかを、まず確認することをおすすめします。

Q. 利用者が増えると、費用はどう変わりますか？

A. 認証サービスを使う場合、多くはその月に使った利用者の数（MAU）が無料枠を超えると、それに応じて費用が増えます。SSOで連携する利用者に、別の無料枠や単価を設定しているサービスもあるため、利用者の種類ごとに試算しておくと安心です。

Q. 認証サービスと自社開発では、どちらが安くなりますか？

A. 条件によって大きく変わります。利用者の数、対応する規格の数、安全性の確保や障害対応にかかる社内の手間などで、総額が変わるためです。初期の費用だけでなく、数年間の運用費用を含めて比べることをおすすめします。

Q. すでに動いているサービスに、後からSSOを追加できますか？

A. 一般的には追加できます。ただし、今のログイン機能の作り方や、既存の会員データの扱いによって、改修の範囲が変わります。まずは現在の仕組みを開発会社に確認してもらうとよいでしょう。

まとめ

自社のWebサービスにSSOを組み込むときの要点は、次の4つです。

• SSOは、本人確認をIdPに任せ、1回のログインで複数のサービスを使えるようにする仕組みです。社内への導入と、自社サービスへの組み込みは別の話として考えます。
• 自社サービスに組み込むなら、標準の規格（SAML・OIDC）が基本です。新しく作るならOIDC、SAMLを求める企業顧客がいるならSAMLへの対応も検討します。
• 認証サービスを使うか自社で作るかは、利用者数、求められる規格、社内で運用を担えるかで判断します。認証サービスはMAUで料金が決まることが多く、SSOで連携する利用者は、無料枠や単価が異なる場合もあります。
• 認証サービスを選ぶときは、料金の数え方、企業向けSSOが使えるプラン、会員データの移しやすさ、データの保存場所を確認します。

まずは「誰が、どのIDでログインするか」を整理するところから始めてみてください。

SSOを含むWebサービスや業務システムの開発について相談したい場合は、弊社のお問い合わせページからご連絡ください。要件の整理の段階からお話を伺います。