サイバーセキュリティ 
ワンクリック詐欺から身を守るためには、どんなに不安を
SAML (Security Assertion Markup Language) とOAuth (オープン認証) の主な違いは、それぞれの役割にあります。
SAMLが認証を重視するのに対し、OAuthは認可に特化したものです。 SMALとOAuthは異なるものですが、どちらも企業の全体的なセキュリティを改善する上で不可欠です。これらのプロトコルによって、権限のあるユーザーが本人確認を実施し、適切なリソースにアクセスできるようなるのです。
ここでは、SAMLとOAuthとは何か、それらの違いと類似点、企業がそれらを使用すべきかどうかについて解説します。
SAMLとは？
SAMLとは、Security Assertion Markup Languageのそれぞれの頭文字を略した名称で、ログインプロセスを簡素化するものです。
ユーザーが1つの認証情報でログインすると、複数のシステムにアクセスする際に毎回ログイン認証情報を再入力しなくてもアクセスできるようにします。
SAMLは、認証情報をIDプロバイダー (IdP) とウェブアプリケーションの間に特定の形式で送信することで機能します。 ユーザーがログインしようとすると、SAMLを認証に使用するウェブアプリケーションが、ログイン認証情報の確認をIDプロバイダーに要求します。 ユーザー名とパスワードを入力すると、IdPはSAMLアサーションと呼ばれる特別なメッセージをウェブアプリケーションに送信し、本人確認が実行できたことを確認します。 IdPは、ユーザーがログインしようとしていた元のウェブアプリケーションにSAMLアサーションを送信しします。これにより、SAMLアサーションが審査されてユーザーへのアクセスが許可されます。 SAMLは、複数のウェブアプリケーションでのログインプロセスを簡素化し、各アプリケーションへのログインに費やす時間を最小限に抑えます。
OAuthとは？
OAuth (オープン認証) を使用すると、データへのアクセス権をサードパーティ製のアプリケーションと共有できます。その際、サードパーティーにログイン認証情報へのアクセスを許可しなくても済みます。 例えば、クラウドに保存されたカメラロールへのアクセスを必要とするアプリを使おうとしているとしましょう。 アプリはそのデータへのアクセス権を要求し、ユーザーをクラウドストレージ・プロバイダーにログインするようリダイレクトします。
ユーザーがログインすると、アプリにカメラロールへのアクセスを許可したいかどうかを尋ねられます。 ユーザーが承諾すると、クラウドサービスがアクセストークンを作成します。これは、ユーザーのログイン認証情報を明らかにすることなく、アプリにカメラロールへのアクセスを許可するものです。 パスワードではなく鍵でアクセスを許可することで、ログイン認証情報をサードパーティ製のアプリケーションと共有せずに済むのです。 代わりに、サードパーティ製のアプリケーションは、ユーザーが許可したデータのみにアクセスできるようになります。
SAMLとOAuthの主な違いとは？
SAMLとOAuthは、どちらも企業がデータを保護するために実装すべき重要なセキュリティプロトコルですが、両者にはいくつかの大きな違いがあります。
SAMLとOAuthには異なる使用方法がある
SAMLは企業の認証向けに設計されていますが、OAuthはアプリやサービス間の認可向けに設計されています。
複数のサービスにログインする際に毎回ログイン認証情報を入力しなくても済むSAMLは、ビジネス環境において特に役立ちます。 例えば、企業がメール用、マーケティング用、営業用、人事用にそれぞれ異なるアプリを使用しているとします。 SAMLがあれば、ユーザーが企業のポータルに一度ログインすると、繰り返しログインすることなく必要なアプリケーションすべてにアクセスできます。
一方、OAuthは、ログイン認証情報の安全を保つのに役立つと同時に、SNSプラットフォームやサードパーティ製のサービスなどのアプリとデータを共有します。 例えば、仕事用のアプリを開いて、それにGoogleアカウントでログインすることが必要な場合、そのアプリはOAuthを使用していることになります。 つまり、ユーザーがアプリに許可した場合、パスワードを必要とせずにアプリがデータにアクセスできるのです。
SAMLとOAuthには異なるセキュリティモデルを採用
SAMLはデジタル署名とアサーションを使用してデータを保護しますが、OAuthはアクセストークンに依存します。 SAMLアサーションは、ログインプロセス中に本人確認をすることで、ユーザーが本人であることを裏付けします。 SAMLアサーションは、多くの場合デジタル署名が使用されます。これは、ユーザーの情報が変更されておらず信頼できるものであることを保証するものです。
OAuthは、アサーションやデジタル署名を使用する代わりに、トークンとスコープを使用してユーザーを認可します。 アプリにデータへのアクセスを許可すると、そのアプリはアクセストークンを受け取ります。これにより、アプリはユーザーのログイン認証情報を必要とせずにデータを閲覧できます。 スコープは、トークンが持つアクセスの種類をユーザーが決定できるようにするものです。 OAuthは、パスワードを共有することなく特定の権限を付与し、データの整合性を重視し、サードパーティ製のアプリによるアクセスを必要なデータのみに制限します。
SAMLとOAuthは異なるデータ形式を使用
SAMLは、詳細なユーザー属性を含むXMLベースのアサーションを使用します。 XML形式のSAMLアサーションには、ユーザーの情報、ユーザーが最後にログインした日時、ユーザーがアクセスすべき内容などが含まれます。 XMLは複雑であるため、読み取りにくく管理が難しいことがあります。そのため、大企業にとってより良い選択肢となります。
対照的に、OAuthはJavaScriptオブジェクト表記 (JSON) を使用してデータを表現します。 JSONはXMLよりも読みやすいため、このフォーマットはウェブアプリケーション内のデータによく使用されます。 OAuthアクセストークンは、通常JSONオブジェクトとして表され、トークンの有効期限や付与される権限の内容、データにアクセスするために使用されるトークンの種類を指定します。
SAMLはOAuthよりも実装が複雑
SAMLは、ユーザーの本人確認を行うためにアサーションに依存し、同時に複数のシステムが機能することを要求します。そのため、ユーザーがそれに応じて認証されるために複雑な構成を必要とします。 セキュリティの面では、SAMLにはデジタル署名や暗号化されたアサーションなど、より広範な機能があります。複数のセキュリティ層があるため実装が複雑になります。
OAuthは、主にXMLではなくJSONをデータ表現に使用するため、はるかに単純です。 JSONは読みやすくコンパクトであるため、読み込みやすく、制御も厳しくありません。 SAMLとは異なり、OAuthに必要なのはアプリケーションと定義された権限のみであるため、設定するのに必要な手順が少なくて済みます。 OAuthは、証明書やアサーションではなくアクセストークンを使用するため、ユーザーの権限も管理しやすくなります。
SAMLとOAuthは異なる方法でセッションを管理する
SAMLは、ブラウザセッションを作成し、複数のアプリケーション間でログインを処理します。 IdPを介してアプリにログインすると、セッションが作成されます。これにより、ユーザーは毎回ログイン認証情報を入力することなく、複数のアプリにアクセスできるようになります。
これが、アクセストークンを使用してセッションを管理するOAuthとは異なる点です。 ユーザーがアプリを認可すると、アプリはトークンを受け取ります。これにより、ユーザーは限られた時間だけデータにアクセスできます。 アプリが拡張アクセスを必要とする場合、ユーザーが再ログインすることなく新しいアクセストークンを要求できます。
SAMLとOAuthの類似点は？
SAMLとOAuthには多くの重要な相違点がありますが、類似する特徴もいくつか共有しています。
- SAMLとOAuthは、どちらもオープンスタンダードのフレームワークです。つまり、あらゆる企業が実装できるセキュリティガイドラインに基づいています。
- どちらもシングルサインオン (SSO) を有効にすることにより、ユーザーが1つのログイン認証情報で複数のアプリやサービスにアクセスすることを可能にします。 SAMLとOAuthは、ユーザーがログイン認証情報を入力する回数を減らすことで、時間を節約するとともにセキュリティリスクを最小限に抑えます。
- どちらも、フェデレーション・アイデンティティ管理 (FIM) をサポートしており、ユーザーが外部の複数のサービス (さまざまな企業のアプリケーションなど) にログインできるようにします。 SAMLとOAuthは、単一のログイン認証情報を使用して複数のITリソースへのアクセスを可能にし、アサーションとトークンを介してログインプロセスを安全にします。
企業が使用すべきなのはSAMLかOAuthどっちが良いのか？
企業は、SAMLとOAuthのどちらかを選択するのではなく、両方の使用を検討すべきでしょう。なぜなら、双方が互換性のあるプロトコルではないためです。 SAMLはユーザーの認証と認可をサポートしていますが、それでもOAuthを使用してユーザーの特権を管理することにはメリットがあります。 SAMLとOAuthの両方を使用することで、企業は、システムへのアクセスをSAMLで付与し、リソースへのアクセスをOAuthで付与できるのです。
結論：企業内ではSAMLとOAuthの両方のアプローチが最適
企業は、不正ユーザーからデータを保護するために、SAMLとOAuthの両方を使用することでメリットを得られます。
SAMLは、複数のサービスやアプリにアクセスする際にユーザーが本人であることを検証し、OAuthは、パスワードを共有することなくアプリがデータにアクセスすることを許可します。 SAMLとOAuthの両方を実装すると、複数のサービスにログインするために費やす時間を短縮し、やりとりをより簡単なものにしてデータを保護することで、全体的なセキュリティとユーザーエクスペリエンスを向上させることができます。
KeeperがSAML 2.0に互換性のあるIdpと連携する仕組みを検討していたり、興味をお持ちの方は、ぜひデモのお問い合わせをご検討ください。
Keeper SSOコネクト®のデモをリクエストして、企業の全体的なセキュリティを強化しましょう。
