SAMLとOAuthとは？比較と違い、OpenID（OIDC）との関係を解説

Security Assertion Markup Language（SAML）は、認証プロセスです。毎朝、仕事を始める際にコンピューターにログインするときには、SAMLが使用されるケースが多いのではないでしょうか。SAMLは、XML形式のマークアップ言語の一種で、シングルサインオン（SSO）のプロトコルの一種としても使用されています。

Open Authorization（OAuth）は、認可プロセスです。新たなユーザー名とパスワードを使用せずに、あるサービスから別のサービスに移ることができます。例えばGoogleにログインし、その資格情報を使用してHootsuiteにアクセスする場合は、OAuthを使用したことになります。

どちらのアプリケーションもWebのシングルサインオン（SSO）に使用できますが、SAMLがユーザー固有になる傾向があるのに対して、OAuthはアプリケーション固有になる傾向があります。一方を他方の代わりとして使用することはできないため、ここでは単純に比較するのではなく、SAMLとOAuthの2つをどのように一緒に使うのかについて説明します。

→Okta Japanの資料請求はこちら

SAMLの仕組み

SAML は、アイデンティティを検証して認証を提供するオープン標準です。一般的なオフィス環境では、従業員は社内の機能の一部にアクセスするためにログオンする必要があります。

SAML認証が完了すると、ユーザーは、企業のイントラネット、Microsoft Office、ブラウザなどのツールスイート全体にアクセスできるようになります。SAMLを使用することにより、ユーザーは1つのデジタル署名でこれらのリソースをすべて利用できるようになります。

セキュリティがより厳しい企業の場合、SAMLは、ユーザーがドアを開けたり、コンピューター画面のロックを解除したりといったことしか許可しません。ユーザーがファイルへのアクセスを含む他の操作を実行する前には、認可が必要となります。

ネットワーク管理者はSAMLを使用して、一元的にユーザーを管理できます。1つのパスワードでユーザーが必要とするすべてのサービスを使用可能にし、企業のセキュリティも保護します。

SAMLの一般的なワークフローは以下のようになります。

要求：ユーザーが「ログイン」ボタンをタップします。
検証：SAMLとアイデンティティプロバイダーが認証のために接続します。
ログイン：ユーザー名とパスワードの入力画面が表示されます。
トークンの作成：ユーザーが正しい情報を入力すると、SAMLトークンがサービスプロバイダーに渡され、ユーザーはサーバーにログインできます。

このワークフローにより、サービスプロバイダー、ブラウザ、アイデンティティプロバイダーは情報をシームレスにやりとりできます。このプロセスは通常数秒で処理されるため、ユーザーが遅延に気付かないこともあります。

OAuthの仕組み

「Auth」は認証（Authentication）の意味とも認可（Authorization）の意味とも言えますが、OAuthプロトコルについては認可を意味します。このOAuthプロトコルは、ユーザーのユーザー名とパスワードを保護しながら、あるユーザーから別のユーザーに認可を渡すために使用されます。

平均的な従業員が業務上重要なアプリケーションを1日に1,100回も切り替えて使用するような環境では、OAuthは時間を節約する上で重要な役割を担います。従業員は、再度ログインすることなく複数のアプリ間を行き来して使用する方法を必要とすることがあり、これを可能にするのがOAuthです。

たとえば、有効なGoogleアカウントを持つ従業員は、同じ資格情報を使用して以下に含まれるデータを活用できます。

Hootsuite
SurveyMonkey
HotJar
Microsoft 365
Salesforce
Marketo
Box

従業員が業務遂行のため、これらのWebベースのプログラムをすべて必要とする場合も、そのためにユーザー名/パスワードを何セットも作成する（さらに記憶する）となると、気後れするのではないでしょうか。

ユーザー名とパスワードの使い回しは、セキュリティのリスクを引き起こします。いずれかのサイトが侵害されると、ユーザーの重要データがすべてのプラットフォームで公開され、脆弱になります。しかし、最初のサイトによって提供される検証を使用して別のサイトにログインすることは、大きく異なります。

データマイニングについて懸念する一部の消費者は、このようなツールを使用することで、Facebookのような企業に過度に大きな権限が集中するリスクについて論じています。ユーザーが他のアプリやサイト向けにFacebookログインを選択するたびに、Facebookはより多くの顧客インサイトを得ることができます。Facebookのデータが侵害された場合、追加されたログインも侵害される可能性があります。

しかし、ほとんどの従業員は、忙しくストレスの大きな時期に時間を節約できることは歓迎すべきことだと受け止めるのではないでしょうか。

OAuthのワークフローは以下のようになります。

要求：ユーザーがWebページの「ログイン」ボタンをクリックします。
選択：使用するサードパーティ認可の資格情報を選択します。
ログイン：認可サーバーによってアクセストークンが作成され、リソースサーバーに送信されます。
接続：トークンを検証した後、リソースサーバーがアクセスを許可します。

このOAuthのプロセスを通して、2つのサーバーが情報をやりとりします。通常、OAuthはトークンにJWTを使用しますが、代わりにJavaScript Object Notationを使用することもできます。

トークンは、その作成方法を問わず常にエンコードされます。通常は署名されますが、サーバー間で渡されるときに暗号化されることはほとんどありません。

OAuthとSAMLの類似点と違い

OAuthとSAMLはどちらも、相互運用を奨励し標準化するためのプロトコルです。

これらのツールを使用することで、ユーザー名/パスワードが増加し続けて重要リソースへのアクセスが妨げられる事態を回避できます。アプリの所有者にとって、OAuthとSAMLはオンボーディングが簡単であり、ユーザー管理を任せることができます。管理者にとって、これらのツールは迅速な統合と、一元化された認証・認可を意味します。

しかし、OAuthとSAML、2つのツールは以下を含む非常に異なる機能を扱います。

認証：このプロセスには、ユーザーのアイデンティティが関与します。SAMLは、家の鍵のようなものです。つまり、家に入る許可を与えます。
認可：このプロセスには、ユーザーの権限が関与します。OAuthは、その家のルールに若干似ています。つまり、家に入った後にできること/できないことを規定します。

これをさらに細かく説明するため、従業員の平均的な就業日を考えてみましょう。まず、朝にSAMLで一回ログインします。このログインによって、SAMLベースのアプリケーションのスイート全体に対するアクセス権が付与されます。ユーザーがアプリケーション間で行き来するために、さらなる操作は必要ありません。

SAMLとOAuthはいつ使うべきか？

SAMLとOAuthは両方とも、SSOの機会を可能にし、従業員の生産性向上にとって重要です。2つは、互いを代替するというよりは、一緒に使用できるテクノロジーであると考えることができます。

たとえば、Microsoft環境では、OAuthが認可を処理し、SAMLが認証を処理します。2つを同時に使用する場合、SAML経由でログインして、OAuth経由で保護されたリソースへのアクセスを許可できます。

また、これらのツールを両方とも排除することも可能です。たとえば、一部のWebページは認証と認可のどちらも必要としません。

しかし、デジタルシステムを使用するほとんどの企業は、効果的に機能するために何らかの認証/認可システムを使用しなければなりません。ユーザーは、日々の業務に従事するために、企業のシステムにサインインし、システム内で移動する許可を必要とします。

OpenID Connect（OIDC）とは？ SAMLやOAuthとの関係

アプリケーションやポータルなどの消費者向けセカンダリツールを開発している場合には、OAuthが重要になることがあります。新しいユーザー名とパスワードを作成せずにツールにアクセスできる機会を提供することが、市場に高く評価される可能性があります。また、従業員がSAML以外のツールを使用する場合も、OAuthが役立ちます。

しかし、SAMLとの真の比較のためには、SAML、OAuth、およびOpenID Connectの違いを確認する必要があります。

Oktaとの連携

OktaのSSOサービスは、日常的に使用するアプリケーションをシームレスに認証できることで高く評価されています。セキュアなSSOでは、多くの場合にプロトコルとしてSAMLが選択されますが、Oktaはさらに、サインインウィジェット、Auth SDK（JavaScriptベースのライブラリ）、ソーシャルログイン、任意のクライアント向けの認証APIなどのオプションも提供します。

Oktaの事前構築済みアイデンティティソリューションの詳細については、こちらをご覧ください。