データを攻撃する方法が多様であるように、データを安全に保つ方法多くあります。多要素認証、シングルサインオン、オンプレミスのファイアウォールなど、選択肢は多岐にわたります。開発者やIT専門家にとって、データとアイデンティティをいか安全に保つかという選択は、さらに早い段階の、フェデレーションアイデンティティを安全に保つために導入すべき標準を選択することから始まります。
この判断は必ずしも一筋縄ではいきません。OAuth 2.0、OpenID Connect、SAML（Security Assertion Markup Language）は、それぞれがフェデレーションプロセスの構造を形成するものですが、違いを理解しにくい人が多いようです。ここでは、これらの標準の意味、比較、使用目的の違いを明確に解説いたします。
また、SAMLとOAuthの比較については、別の記事で詳しく紹介していますので、そちらもご覧ください。
→Okta Japanの資料請求はこちら
OAuth、OpenID Connect、SAMLの違い
OAuth、OpenID Connect、SAML、これら3つの標準の主な違いは、OAuth 2.0がアプリケーションやファイルセットなどの保護されたリソースに対する認可を制御するフレームワークであるのに対し、OpenID ConnectとSAMLはどちらもフェデレーション認証の業界標準であることです。つまり、OAuth 2.0は、他の2つの標準とは根本的に異なる状況で使用され（その例を以下に示します）、OpenID ConnectまたはSAMLのいずれかと同時に使用できます。
OpenID ConnectまたはSAMLを単独で使用することで、ユーザー認証を実現し、シングルサインオンを導入できます。どちらもログインを扱いますが、メリットとデメリットが異なります。
- OpenID Connectは、OAuth 2.0プロトコルをベースに構築されており、IDトークンと呼ばれる追加のJSON Web Token（JWT）を使用して、スコープやエンドポイントの発見など、OAuth 2.0が選択に委ねている部分を標準化しています。ユーザー認証に特化しており、消費者向けWebサイトやモバイルアプリでユーザーのログインを可能にするために広く利用されています。
- SAMLは、OAuthとは独立しており、JWTとは対照的に、XML SAMLフォーマットで認証するためのメッセージの交換に依存しています。一般的には、企業ユーザーが1回のログインで複数のアプリケーションにサインインするために使用されます。
OAuth 2.0、OpenID Connect、SAMLの用途・目的を比較
ここで問題となるのは、どの構造を使うかではなく、どの構造をいつ展開するかです。強力なアイデンティティソリューションは、保護対象となる業務の種類に応じて、これら3つの構造を使用して異なる目的を達成します。その使用例を以下に示します。
OAuth 2.0：新しいアプリケーションに登録して、新しい連絡先をFacebookや携帯電話の連絡先から自動的に取得することに同意した場合は、おそらくOAuth 2.0が使われています。この標準は、安全な委任アクセスを提供します。つまり、ユーザーが認証情報を共有しなくても、アプリケーションがユーザーに代わってアクションを起こしたり、サーバーからリソースにアクセスしたりすることができます。これは、アイデンティティプロバイダー（IdP）がユーザーの承認を得て、サードパーティのアプリケーションにトークンを発行できるようにすることで実現されます。
OpenID Connect：Googleを使ってYouTubeなどのアプリケーションにサインインしたり、Facebookを使ってオンラインショッピングのカートにログインしたりする場合に使用されるのが、この認証オプションです。OpenID Connectは、組織がユーザーを認証するために使用するオープンスタンダードです。IdPはこれを利用して、ユーザーがIdPにサインインした後、他のWebサイトやアプリにアクセスする際に、ログインしたりサインイン情報を共有したりする必要がないようにします。
SAML：SAML認証は、多くの場合に仕事環境で使用されます。たとえば、企業のイントラネットやIdPにログインした後、Salesforce、Box、Workdayなどの多数の追加サービスに、認証情報を再入力せずにアクセスできるようになります。SAMLは、IdPとサービスプロバイダーの間で認証・認可データを交換するためのXMLベースの標準で、ユーザーのアイデンティティとアクセス許可を検証し、サービスへのアクセスの許可/拒否を決定します。
企業は、OAuth 2.0、OpenID、SAMLなどのWebフレームワークやプロトコルを利用して、フェデレーションアイデンティティの構造とセキュリティを形成しています。どのような場合にそれぞれを使用するべきかを理解することは、組織のデータを基盤から守るための重要なステップです。