OAuthは、複数のアプリケーション間で、ユーザーIDの認証データを共有することなく、ユーザーの承認を拡張するためのプロトコルです。
この記事を読み終えると、以下のことができるようになります。
関連コンテンツ
是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください！
記事のリンクをコピーする
OAuth は、ユーザーを承認するための技術標準です。これは、ユーザー名とパスワードなどの実際のユーザー資格情報を共有することなく、あるサービスから別のサービスへ権限を与えるためのプロトコルです。OAuthを使用すると、ユーザーは1つのプラットフォームでサインインし、別のプラットフォームでアクションを実行し、データを閲覧する権限を持つことができます。
OAuthは、2つのアプリケーションが何であるかを問わず、あるアプリケーションから別のアプリケーションへ権限を与えることができます。OAuthは、シングルサインオン（SSO）サービスから別のクラウドアプリケーションに権限を与えるために使用される最も一般的な方法の 1 つですが、任意の2つのアプリケーション間で使用できます。他のプロトコルでもこの機能を実行できますが、OAuthは最も広く使用されているプロトコルの1つです。
たとえば、家主がいない間に訪問者が家に来て、訪問者に実際の家の鍵を送る代わりに、鍵が入っている金庫を開けるための一時的なコードを家主から訪問者に送る場面を想像してみましょう。OAuthも同様の方法で機能します。OAuthでは、あるアプリケーションが別のアプリケーションにユーザー資格情報ではなく、承認トークンを送信して、ユーザーアクセスを許可します。
アリスは、会社のクラウドファイルストレージアプリケーションにアクセスしようとしています。彼女はすでに会社のSSOにサインインしていますが、その日はまだファイルストレージアプリケーションにアクセスしていません。彼女がファイルストレージアプリケーションを開くと、アプリケーションはただアクセスを許可するのではなく、アリスのSSOからの承認を要求します。
応答として、SSOはOAuth承認トークンをアプリケーションに送信します。トークンには、アリスがアプリケーション内で持つべき権限に関する情報が含まれています。トークンには時間制限もあります。一定時間が経過すると、トークンの有効期限が切れ、アリスはSSOに再度サインインする必要があります。
OAuthトークンは通常、HTTPSを使用して送信されます。つまり、暗号化されます。これらは、OSIモデルの 第7層で送信されます。
OAuthは、ユーザーの承認と、あるアプリケーションから別のアプリケーションへの部分的なアクセスの許可の両方に使用できます。ユーザーがよく遭遇する事例の 1 つは、アプリがソーシャルメディアプラットフォームまたは別のオンラインアカウントにアクセスできるようにすることです。Googleユーザーアカウントは、ブログプラットフォーム、ニュースWebサイト、多様なオンラインゲームなど、さまざまな消費者アプリケーションと統合できます。このような場合に、OAuthプロトコルをバックグラウンドで使用し、外部アプリがGoogleから必要なデータにアクセスできるようにします。
企業にとって、OAuthのより一般的な使用例は、IDおよびアクセス管理（IAM）システムとOAuthを併用することです。ユーザーは、OAuthを介してアプリケーションの使用を許可されます。たとえば、従業員は、ユーザー名とパスワードを使用して会社のSSOシステムにサインインできます。このSSOシステムは、従業員に対し、仕事を行うために必要なすべてのアプリケーションへのアクセスを提供します。SSOシステムは、これらのアプリケーションにOAuth承認トークンを送ることによってこれを行います。
OAuthは、現在使用されているいくつかの承認プロトコルの1つです。これらの承認プロトコルは必要不可欠となっています。ユーザーのログインデータを公開することなく、アプリケーション間で承認情報を送信する何らかの方法が必要とされているためです。いくつかのプラットフォームは、独自の承認方法を開発しています。たとえば、FacebookはFacebook Connectを提供しています。
OAuth 2.0はOAuthの最新バージョンです。OAuthの最初のバージョンは2010年に公開されました。OAuth 2.0は2012年に公開され、OAuth 1.0に存在していた多数の脆弱性を修正したものです。
承認と認証は似ていますが、アクセス管理ではまったく同じではありません。これらの違いは、アクセス管理技術（OAuthを含む）がどのように機能するかを理解する上で非常に重要です。認証はユーザーIDと関係しており、承認はユーザー権限と関係しています。
たとえば、ボブが正面に警衛所がある機密性の高い施設で働いていると想像してみてください。施設に入る車両はすべて警衛所で停車し、既知の従業員のみが立ち入りできます。警衛所は、ユーザーの認証が行われる場所です。警備員は、ボブの身分証明書を従業員リストと照合し、許可された車両のリストと照合して車両のナンバープレートをチェックします。ボブ本人と彼の車両が認証されれば、ボブはそのまま運転を続けて施設の駐車場に駐車することができます。
しかし、ボブが施設に運転して入れたからといって、駐車場内のどこにでも駐車できるわけではありません。代わりに、従業員の職種ごとに指定された駐車場があるのです。ボブは指定された駐車場にのみ駐車できます。CEOの駐車場を利用することはできません。
OAuthは承認のためのプロトコルです。ボブが適切な駐車場に行くことを保証します。対照的に、SAML（Security Assertion Markup Language）は、認証のためのプロトコルであり、ボブが警衛所を越えることを許可します。
IDプロバイダー（IdP）またはSSOサービスは、相互に組み合わせるか、OAuthのみで使用できます（ただし、認証にOAuthを使用すると「擬似認証」と見なされます）。
要約すると、SAMLとOAuthは異なるプロトコルであり、異なる目的のために使用されますが、両者はSSOでよく使用されます。
Cloudflare Zero Trust は、現在、SSOサービスなどのユーザー認証を提供しておりませんが、組織がユーザーのアクセスと権限を管理することを可能にします。Cloudflareは、仮想プライベートネットワーク（VPN）を使用せずにユーザーの承認を管理することを可能にします。
Cloudflare Zero TrustはさまざまなSSOプロバイダーと統合され、複数のSSOとの統合もできるため、外部の代理店や請負業者にシステムアクセスを提供しやすくなります。詳細については、Cloudflareを使用したマルチSSOに関するブログ記事をご覧ください。