HC
橋爪兼続
2023/07/21
シングル・サインオン（以下、SSO）を実現する方法として、SAMLとOAuthとがあります。この2つについて何が異なるのか良く解らないという事が多いと思います。この記事では、この2つの違いについてわかりやすく解説します。
認証と認可
SAMLとOAuthを理解するためには、認証と認可の違いを理解する必要があります。この2つはよく似ていますが、異なります。
認証（Authentication）： 「あなたは誰ですか？」 を確認することです。例えば、次に挙げたものを確認することが認証です。
What you are：相手自身の特徴を確認 例）指紋認証や顔認証
What you have：相手が持っているものを確認 例）免許証やパスポート
What you know：相手が知っていることを確認 例）email と password
認可（Authorization）：認可は 「あなたには、リソースにアクセスする権限がありますか？」 を確認することです。例えば次のような事例が認可です。
家の鍵を持っているから、家に入ることができる
バスの乗車券を持っているから、バスに乗ることができる
SAMLは「認証」に対応するプロトコルであり、OAuthは「認可」に対応するプロトコルです。
SAMLとOAuthの仕組み
SAMLの仕組み
SAMLでは認証情報を提供する側を「IdP（Identity Provider）」と呼び、認証情報を利用する側（一般的にアプリケーションやサービス側）を「SP（Service Provider）」と呼びます。SAMLによる認証フローがどのようになっているのかを簡単にご紹介します。
＊SP Initiatedによるフロー
シングルサインオン（SSO）に必要なSAMLとは？ https://www.idearu.info/article/system/single-sign-on-saml より引用
1.アクセス要求
まず利用者（ユーザー）は使いたいサービス（SP）に対してアクセスします。
2.認証リクエスト
アクセスしてきたユーザーがSPの利用を許可されているかどうか、アカウントがあるかどうかを確認します。
3.認証依頼
ユーザーはSPを利用するために、認証が必要です。認証の証明書である認証トークンをIdPに発行してもらいます。このとき、まだログインしていない（シングルサインサービスに対してまだID・パスワードの入力をしていない）場合は、ここでID・パスワードや、設定によっては多要素認証などを求められるので必要に応じて入力します。
4.認証トークン
ID・パスワードなどが適切に入力された場合は、ユーザーに「認証トークン」という証を渡します。
5.認証トークン
IdPからもらった「認証トークン」をSPに渡します。
6.サービス提供
SPはユーザーから受け取った「認証トークン」を確認し、正規のユーザーであることをチェックします。チェックし、正規のユーザーであると認証した後、ユーザーは各サービスが利用できるようになります。
OAuthの仕組み
OAuth2.0を例に説明します。
主な用語
クライアント：利用するWebアプリケーションを指します
認可サーバー：リソースサーバーに信頼されたサーバーで、リソースオーナーの認証を行い、リソースサーバーに対するアクセストークンを発行できます
リソースオーナー：Webアプリケーションを利用する人（ユーザー）のことです
リソースサーバー：アクセス対象のWebサーバーです。（Gmailなど）
認可サーバーへのリダイレクト クライアント（Webアプリ等）から必要なパラメーターを付与して、認可サーバーへリダイレクトします。リダイレクトを行う理由は、クライアントを識別したりする情報を付与して認可サーバーへアクセスさせるためです。
認可サーバーでの確認 認可サーバーは、リソースオーナーに対して要求されている認可の可否を確認します。リソースオーナーは、必要に応じてパスワード等で認証を行った後に、問題がなければ許可をします。
認可コードの発行 認可サーバーは、許可されるとアクセストークンを発行するための認可コードを発行します。認可サーバーからクライアントへリダイレクトします。認可コードが外部にもれないよう、リダイレクトは事前に設定されたURLのみ可能です。
アクセストークンの発行 クライアントは、認可コードを認可サーバーに渡してアクセストークンを取得します。
リソースサーバーへアクセス 取得したアクセストークンを使用して、保護されたリソースにアクセスします。
OpenID Connect
さて、ここでOpenID Connectについて説明します。OpenID ConnectはOAuthを拡張した規格です。
OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い https://baasinfo.net/?p=4418 より引用
OAuthのフローに記載されているとおり認可のプロセスにおいて、認証が含まれるので、「認可とは別に認証は不要ではないか」と思う人もいると思います。しかしながら、認可情報は、流出する恐れがあります。
クレジットカードを例に上げると、発行する際には本人確認を行い発行します。ただ、一度発行したクレジットカードを紛失した場合、他人に利用されてしまう可能性があります。そのため、大きな金額を利用する際は署名など事後的に本人確認が可能となるプロセス（認証）が求められます。
つまり、認可だけではセキュリティとして不十分であり、このような認可(OAuth)の問題に対処するのがOpenID Connect（認証）です。
先ほど、「OpenID ConnectはOAuthを拡張した規格」と書きましたが、正確には、認可プロトコルとしてOpenID Connectが、認証プロトコルとしてOAuthが使用されることになります。ですので、OpenID Connect単独では利用できず、OpenID Connectを利用するときはOAuthにより認証を行うことになります。
SAMLとOAuthの違い
OAuthはGoogleやTwitter等のSNSの認証を目的として開発されたもので比較的簡易的なプロトコルです。一方でSAMLは、非常に複雑な権限管理を行うことができます。 このような違いにより、OAuthおよび、拡張したOpenID ConnectはFacebookやTwitterなどのSNSの認証で使用されることが多いです。また、SAMLは、Active Directoryの機能の一つであるADFS（Active Directory Fereration Service）やOktaなどIDPサービスで主に用いられています。
SAMLもOAuthもそれぞれ役割が異なります。まずは、使用するシステムがどちらに対応するかを確認する必要があるでしょう。確認の結果、どちらの方式を採用するかどうかについては、提供するサービスの目的や趣旨と照らし合わせて十分に検討して決定しましょう。
認証と認可
シングル・サインオン（以下、SSO）を実現する方法として、SAMLとOAuthとがあります。この2つについて何が異なるのか良く解らないという事が多いと思います。この記事では、この2つの違いについてわかりやすく解説します。
SAMLとOAuthを理解するためには、認証と認可の違いを理解する必要があります。この2つはよく似ていますが、異なります。
認証（Authentication）： 「あなたは誰ですか？」 を確認することです。例えば、次に挙げたものを確認することが認証です。
What you are：相手自身の特徴を確認 例）指紋認証や顔認証
What you have：相手が持っているものを確認 例）免許証やパスポート
What you know：相手が知っていることを確認 例）email と password
認可（Authorization）：認可は 「あなたには、リソースにアクセスする権限がありますか？」 を確認することです。例えば次のような事例が認可です。
家の鍵を持っているから、家に入ることができる
バスの乗車券を持っているから、バスに乗ることができる
SAMLは「認証」に対応するプロトコルであり、OAuthは「認可」に対応するプロトコルです。
詳細はこちら
SAMLとOAuthの仕組み
SAMLの仕組み
SAMLでは認証情報を提供する側を「IdP（Identity Provider）」と呼び、認証情報を利用する側（一般的にアプリケーションやサービス側）を「SP（Service Provider）」と呼びます。SAMLによる認証フローがどのようになっているのかを簡単にご紹介します。
＊SP Initiatedによるフロー
シングルサインオン（SSO）に必要なSAMLとは？ https://www.idearu.info/article/system/single-sign-on-saml より引用
1.アクセス要求
まず利用者（ユーザー）は使いたいサービス（SP）に対してアクセスします。
2.認証リクエスト
アクセスしてきたユーザーがSPの利用を許可されているかどうか、アカウントがあるかどうかを確認します。
3.認証依頼
ユーザーはSPを利用するために、認証が必要です。認証の証明書である認証トークンをIdPに発行してもらいます。このとき、まだログインしていない（シングルサインサービスに対してまだID・パスワードの入力をしていない）場合は、ここでID・パスワードや、設定によっては多要素認証などを求められるので必要に応じて入力します。
4.認証トークン
ID・パスワードなどが適切に入力された場合は、ユーザーに「認証トークン」という証を渡します。
5.認証トークン
IdPからもらった「認証トークン」をSPに渡します。
6.サービス提供
SPはユーザーから受け取った「認証トークン」を確認し、正規のユーザーであることをチェックします。チェックし、正規のユーザーであると認証した後、ユーザーは各サービスが利用できるようになります。
OAuthの仕組み
OAuth2.0を例に説明します。
主な用語
クライアント：利用するWebアプリケーションを指します
認可サーバー：リソースサーバーに信頼されたサーバーで、リソースオーナーの認証を行い、リソースサーバーに対するアクセストークンを発行できます
リソースオーナー：Webアプリケーションを利用する人（ユーザー）のことです
リソースサーバー：アクセス対象のWebサーバーです。（Gmailなど）
認可サーバーへのリダイレクト クライアント（Webアプリ等）から必要なパラメーターを付与して、認可サーバーへリダイレクトします。リダイレクトを行う理由は、クライアントを識別したりする情報を付与して認可サーバーへアクセスさせるためです。
認可サーバーでの確認 認可サーバーは、リソースオーナーに対して要求されている認可の可否を確認します。リソースオーナーは、必要に応じてパスワード等で認証を行った後に、問題がなければ許可をします。
認可コードの発行 認可サーバーは、許可されるとアクセストークンを発行するための認可コードを発行します。認可サーバーからクライアントへリダイレクトします。認可コードが外部にもれないよう、リダイレクトは事前に設定されたURLのみ可能です。
アクセストークンの発行 クライアントは、認可コードを認可サーバーに渡してアクセストークンを取得します。
リソースサーバーへアクセス 取得したアクセストークンを使用して、保護されたリソースにアクセスします。
OpenID Connect
さて、ここでOpenID Connectについて説明します。OpenID ConnectはOAuthを拡張した規格です。
OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い https://baasinfo.net/?p=4418 より引用
OAuthのフローに記載されているとおり認可のプロセスにおいて、認証が含まれるので、「認可とは別に認証は不要ではないか」と思う人もいると思います。しかしながら、認可情報は、流出する恐れがあります。
クレジットカードを例に上げると、発行する際には本人確認を行い発行します。ただ、一度発行したクレジットカードを紛失した場合、他人に利用されてしまう可能性があります。そのため、大きな金額を利用する際は署名など事後的に本人確認が可能となるプロセス（認証）が求められます。
つまり、認可だけではセキュリティとして不十分であり、このような認可(OAuth)の問題に対処するのがOpenID Connect（認証）です。
先ほど、「OpenID ConnectはOAuthを拡張した規格」と書きましたが、正確には、認可プロトコルとしてOpenID Connectが、認証プロトコルとしてOAuthが使用されることになります。ですので、OpenID Connect単独では利用できず、OpenID Connectを利用するときはOAuthにより認証を行うことになります。
詳細はこちら
SAMLとOAuthの違い
OAuthはGoogleやTwitter等のSNSの認証を目的として開発されたもので比較的簡易的なプロトコルです。一方でSAMLは、非常に複雑な権限管理を行うことができます。 このような違いにより、OAuthおよび、拡張したOpenID ConnectはFacebookやTwitterなどのSNSの認証で使用されることが多いです。また、SAMLは、Active Directoryの機能の一つであるADFS（Active Directory Fereration Service）やOktaなどIDPサービスで主に用いられています。
SAMLもOAuthもそれぞれ役割が異なります。まずは、使用するシステムがどちらに対応するかを確認する必要があるでしょう。確認の結果、どちらの方式を採用するかどうかについては、提供するサービスの目的や趣旨と照らし合わせて十分に検討して決定しましょう。
よくある質問
AuthとOAuthの違いは何ですか？
"Auth"は、認証（Authentication）または承認（Authorization）の意味を持つ言葉であり、OAuthプロトコルにおいては主に承認を指します。OAuthプロトコルは、ユーザー名とパスワードを保護しながら、あるユーザーが別のユーザーに対して承認を与えるために利用されます。
SAMLとOAuthは、シングルサインオン（SSO）やクラウドサービスなどのユーザー認証に関連しますが、異なるアプローチを取っています。
OAuthは、パスワードをサービスプロバイダーに直接提供せず、代わりにユーザーのアクセス権を制御するための仕組みです。これにより、ユーザーがアプリケーションに直接パスワードを提供せずに、複数のアプリケーションに対するアクセスを管理できます。
一方で、SAMLはSSOのプロトコルであり、クラウドサービスなどの複数のアプリケーションに対するユーザー認証情報を安全に共有するための仕組みです。ユーザーは1回のログインで複数のアプリケーションにアクセスでき、セキュリティと利便性を両立させます。
SAMLの認証と認可の違いは何ですか？
SAMLは認証、OAuthは認可のプロトコルです。しかし、これらには重要な違いがあります。 SAMLはユーザーの確認、OAuthはアクセス権限の付与を目的とします。つまり、SAML認証はユーザーの身元確認を行いますが、OAuthはアクセス権限の付与を担当します。
SAML接続とは何ですか？
SAMLは、異なるインターネットドメイン間でユーザーの認証情報を交換することで、シングルサインオン（SSO）を実現する仕組みの一つです。 SSOを実現する他の方法には、証明書認証方式、エージェント方式、リバースプロキシ方式などがあります。
SAMLを使うメリットは？
SAML（Security Assertion Markup Language）は、SSOを実現するための認証システムであり、異なるインターネットドメイン間でもユーザーの属性情報や権限などの認証に必要な情報を効率的にやり取りすることができます。 SAMLを利用することで、対応するクラウドサービスやWebアプリケーションにおいてシングルサインオン（SSO）やフェデレーションを容易に実現でき、異なるシステム間での横断的な利用が可能となります。
OAuth 何に使う？
OAuthは、複数のWebサービスを連携して動作させるための仕組みです。 通常、Webサービスを利用する際には、個別にユーザーIDとパスワードを入力してユーザーを認証する必要があります。OAuthを利用することで、IDやパスワードを入力することなく、アプリケーション間での連携が可能になります。
SAMLのデメリットは？
SAML認証によるSSOのデメリットは以下の3つです。
・サービスの停止時にすべてのログインが不可になる可能性がある。
・SSO導入に伴いコストが高くなる恐れがある。
・不正アクセスされた場合、悪用されるリスクがある。
SAMLの特徴・利点は？
SAML認証を使用する際、ユーザーの認証だけでなく属性情報も認証可能であり、これによりユーザーのアクセス範囲を制限することができる特徴があります。 言い換えれば、SAML認証を利用することでシングルサインオンを実現するだけでなく、特定の部署のみに特定の機能へのアクセスを制限するなどのアクセス制御も可能です。
OAuthの最大の利点は、アクセストークンを使用した認可プロセスにあります。通常、Webサービス間でユーザーのIDとパスワードを直接共有する代わりに、アクセストークンを生成して渡すことで、トークンが盗まれた場合でも最小限の被害で済むため、セキュリティが強化されます。
SAML認証は必要ですか？
SSOでSAML認証が必要とされる理由は、IdP（Identity Provider）とSP（Service Provider）を結ぶ役割を果たすからです。 SAML認証はIdPとSPを結ぶ役割を担い、これによりSSOを実現することができます。 多くのクラウドサービスがSAML認証を採用しているため、SSOを適用する際にはSAML認証が不可欠と言えます。
OAuthの問題点は？
OAuthのデメリットは以下の3つです。
・利用権限が悪用されるリスクがある
・アカウント情報が不正に書き換えられるリスクがある
・定期的なフリーメールやSNSのセキュリティ設定の見直しが必要
saml認証のアサーションとは？
SAMLアサーションは、ユーザーがサインインしたことをサービスプロバイダーに通知するメッセージです。このアサーションには、アサーションの発信元、タイムスタンプ、ユーザーIDを確認するための条件など、サービスプロバイダーが必要とするすべての情報が含まれます。
SAMLアサーションは、シングルサインオンの一環として使われるもので、セキュリティアサーションマークアップ言語（SAML）によって提供されます。これは、ユーザーがアプリケーションやサービスにサインインした際に、その情報をセキュアに伝達するためのものです。SAMLアサーションには、アサーションの内容や有効性を示す情報が含まれており、これをサービスプロバイダーが要求し、受け取ります。具体的には、認可決定アサーションと呼ばれるものも含まれ、ユーザーの認可情報を含むものです。
シャドーITの検知はCASB？or SMP(SaaS管理)？
詳細はこちら
執筆者：
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
マネーフォワード Adminaについて
