OAuth（読み方：オーオース）は、ユーザーが自分のアカウントパスワードを共有することなく、サードパーティアプリケーションに自分のデータへのアクセスを許可するプロトコルです。これにより、ユーザーはサードパーティアプリが自分のデータや、アカウント情報、写真、文書など、特定のサーバーに保存されているリソースへのアクセスを認証・承認できます。ログイン情報を毎回入力することなく、Webサービスに自分を識別させることができるワンクリックログインにもOAuthは使用されています。
あるWebベースのサービスが別のサービスと接続する際、OAuthプロトコルを使用して、ユーザーにパスワードの共有を求めることなく、安全なやり取りができるようにします。
OAuth認証の歴史
パスワードの共有は、どのアプリケーションにおいても推奨されません。そのため、GoogleやTwitterのような大手テクノロジー企業は、OAuthという解決策を導入しました。
2010年に、Googleは小規模なアプリ開発者にGoogleアカウント情報を使用するサービスを書く方法を提供しました。これは、ユーザーにGoogleのパスワードをサードパーティと共有させるのではなく、サードパーティがGoogleのシステムを使用してユーザーに認証を求め、アクセストークンを保存できるようにするものです。アクセストークンはGoogleアカウントの認証情報を保存し、サードパーティアプリはそのOAuthトークンを使用して、定義された範囲のGoogleアカウントデータにアクセスします。センシティブなパスワードデータを保存し、ユーザーアカウントのセキュリティを維持する代わりに、この方法を取ります。
OAuthプロトコルはいくつかの反復を経ており、最後の主要な改善は2012年に行われました。現在、Amazon、Netflix、PayPal、Microsoft、LinkedIn、Facebookなど、他の多くの大手テクノロジー企業も、サードパーティ開発者がOAuthを統合できるようにしています。これらの企業は、サードパーティ開発者がOAuthを使用してアプリにユーザーアカウントデータを統合できるようにしています。
OAuth認証のメリット
OAuthが登場する前は、すべてのWebベースのサービスがユーザーアカウントごとに別々の認証情報を持っていました。サービス間でデータを共有することは、2つのサービス間でデータを受け渡すAPIを提供していない限り、できませんでした。APIがあっても、サービス間でパスワードを受け渡すことはセキュリティの脆弱性を生じさせ、一つのサービスが侵害されただけで複数のサービスにわたってプライベートデータが露出するリスクがありました。
OAuthを利用すると、ユーザーはさまざまな機能のために、サードパーティアプリに自分のアカウントへのアクセスを許可できます。例えば、カレンダーデータを使用してスケジューリングを容易にする、アプリの設定をクラウドに保存する、あるいは音楽プレイリストを分析して新しいおすすめを得る、といったことが含まれます。パスワードはもはや認証には必要なく、ユーザーはいつでもアクセスを取り消すことができます。サードパーティアプリの開発者は、認証されたデータを取得するためにアクセストークンを保存しますが、これは安全に保存されなければならず、ユーザーの認証情報を露呈することはありません。
OAuth認証の仕組み
OAuthトランザクションの成功には3つのエンティティが関与しています。
- ユーザー（自分のデータへのアクセスを承認する個人または組織）
- OAuthサービスプロバイダー（ユーザーのデータや認証情報を保存しているアプリまたはサービス）
- コンシューマー（ユーザーデータへのアクセスを要求するアプリケーション）
OAuthは、ユーザーデータのセキュリティを確保し、コンシューマーのリクエストを簡素化するために定義されたワークフローを使用します。まず、アクセスを要求するアプリケーション（コンシューマー）は、サービスプロバイダーからOAuthアクセストークンを要求します。サービスプロバイダーにすでにログインしていない場合、ユーザーはログインするよう求められます。次に、サービスプロバイダーは、コンシューマーアプリがアクセスしようとしているデータの種類をリストアップし、ユーザーにアクセスを承認または拒否するよう求めます。ユーザーが同意すると、サービスプロバイダーはアクセストークンをコンシューマーに送信し、これが将来のアクセスリクエストのために保存されます。一度検証されると、アクセストークンはユーザーのデータへのアクセスリクエストにおいて使用されます（ユーザーによって付与された権限の範囲内で）。
アクセストークンは有効期限が切れるため、サービスプロバイダーは開発者が将来のリクエストのためにアクセストークンを更新できる方法を提供します。アクセストークンの有効期間はサービスプロバイダーによって設定されるため、その期間はサービスプロバイダーのセキュリティプロトコルに依存します。アクセストークンは安全に保存されなければなりません。なぜなら、それを使用して誰でもユーザーデータを取得し、ユーザーに代わって機能を実行することができるからです。
ユーザーがアクセスを取り消すことを決定した場合、サービスプロバイダーを通じて取り消しを行うことができます。アクセスが取り消された後、コンシューマーは任意のデータを取得するために、ユーザーに再認証を求めなければなりません。コンシューマーがデータ侵害に遭い、アクセストークンが漏洩した場合、サービスプロバイダーはユーザーデータを保護するために、積極的にすべてのアクセストークンを無効にすることがあります。
OAuthとOpenID
コンシューマーがOAuthを使用する際、サービスプロバイダーはユーザーの同意があった後にのみ、ユーザーのデータへの承認済みアクセスを提供します。OAuthは、ユーザーが自分の認証情報を確認した後にコンシューマーによって提供される認証トークンを使用してデータを共有する方法です。OpenIDはOAuthとは異なるものですが、二つは一緒に使用されます。
シングルサインオン（SSO）は、一つのプロバイダーを使用して複数のサービスにユーザーを認証する一般的なセキュリティ戦略です。OpenIDは、2005年にLiveJournalへの認証用に導入された最も古いSSOプロトコルの一つです。いくつかのアップデートを経てきましたが、当時はFacebook Connectなどの他の方法と比較して実装が難しいと考えられていました。Facebookがよく知られたブランドであったため、ほとんどの開発者はユーザーが自分たちのアプリに認証することをもっと快適に感じるようにFacebook Connectに切り替えました。
2014年にOpenIDはそのコードを再設計し、後にOAuthに組み込まれました。現在、OAuthは認証層としてOpenIDを使用し、OAuth自体は認可層を扱います。このプロセスはユーザーにとってはシームレスですが、コンシューマーはOAuthをより簡単に統合して、ユーザーを認証し、彼らのアカウントデータへのアクセスを得ることができます。
OAuthとSAMLの違い
OAuthに似た古い製品には、XMLベースのSAML（セキュリティアサーションマークアップ言語）があります。SAMLとOAuthの主な違いは、SAMLが認証と認可の両方を行うことです。OAuthは認証層としてOpenIDを使用しますが、自身では認証を処理しません。SAMLを使用するアプリは、認証を提供するための他のサービスを必要としません。
2つのプロトコルのもう一つの違いは、サービス間でデータを渡すために使用される言語です。SAMLはXMLを使用するのに対し、OAuthはデータ転送に好まれる形式であるJSONを使用します。ほとんどのデータサービスは主にJSONで動作するため、OAuthは多くの企業にとって統合が容易です。
OAuth2.0とは？1.0との違い
他のプロトコルと同様に、OAuthも時間を経て進化し改善されてきました。OAuth 2.0はOAuth 1.0を超越しており（OAuth 1.0はもはや安全ではありません）、そのためほとんどのサービスプロバイダーはアクセスにOAuth 2.0のみを許可しています。OAuth 1.0は使用が容易で、いくつかの点でよりシンプルなワークフローを提供します。しかし、ユーザーアカウントを扱う上で安全とは考えられていません。
OAuth 2.0は認可ワークフローに2つのステップを追加しました。これによりHTTPSと署名付きシークレットが可能になり、トークンをエンドポイント（ユーザーのデバイス）上で暗号化する必要がなくなりました。HTTPSは転送中のアクセストークンを暗号化しますが、個人を特定できる情報（PII）やその他の機密データを保存する一部のサービスは、依然として休止中のデータを暗号化します。OAuth 2.0の一つの批判点は、未暗号化チャネル上でのデータ転送を許可することで、開発者がチャネル全体でTLS/SSL暗号化を維持する責任があることです。
OAuth 2.0の利用例
開発者がOAuth 2.0を利用するためには、サービスプロバイダーがシステムにOAuth2.0を実装している必要があります。複数の大手ソーシャルメディアサイトは、自社のプラットフォームを他のアプリと統合するためにOAuth 2.0を使用しています。これはマーケティングの利点であり、プラットフォームの所有者が自社の製品に対するフォロワーを構築するのに役立ちます。
Googleが最初にOAuth 2.0をリリースして以来、多くのアプリがOAuth2.0をSSOプロバイダーおよび基本的なユーザー情報を提供するサービスとして利用しています。シンプルなOAuth 2.0ワークフローでは、コンシューマーは「Googleでログインする」をアカウント作成のオプションとして提供します。ユーザーがすでに認証されている場合、Googleはユーザーが同意した場合にコンシューマーがアクセスできるリソースとデータのリストを表示します。
ユーザーは、コンシューマーの認可リクエストを許可または拒否することができます。ユーザーが拒否した場合、コンシューマーはユーザーのデータにアクセスできません。ユーザーがデータリクエストを許可すると、サービスプロバイダーはコンシューマーにアクセストークンを与えます。アクセストークンは、元のリクエストに記載されているデータのみに対する認可を提供します。ほとんどの主要プラットフォームでは、特定のデータにアクセスする前に、コンシューマーアプリがサービスプロバイダーによって事前に検証される必要があります。通常、コンシューマーは機能するために必要なデータとそのデータの使用方法を概説します。サービスプロバイダーは、リクエストを先取りして許可または拒否することができます。
OAuthは、あるプラットフォームを別のサービスに統合するためにも使用されます。例えば、GmailのようなGoogleの製品と直接連携するアプリを持っていたとします。ユーザーのメールを直接読むためには、ユーザーからの許可が必要です。Googleは、そのアプリがユーザーのGmailアカウントとやり取りできるようにOAuthを使用します。アプリでGoogle Gmailサービスを使用するためには、アプリが機能するために必要なデータを指定し、ユーザーはそのアプリがそのデータにアクセスすることを承認する必要があります。
OAuthは安全？
正しく導入されれば、OAuthは安全です。サービスプロバイダーは、コンシューマーがデータへの認可を持っていることを確認しなければなりません。コンシューマーは、TLS/SSLを使用して安全な接続を確立し、データを暗号化された形式で転送する必要があります。サービスプロバイダーは、コンシューマーに暗号化された接続の使用を要求し、暗号化されていないチャネルを拒否することで、データが安全に伝送されることを保証できます。
OAuth認証の危険性
認証情報を共有するよりも安全ではあるものの、OAuthがリスクフリーであるわけではありません。外部アプリがOAuthを使用してアカウントに接続することをユーザーに許可する際、組織が注意すべきいくつかのセキュリティの落とし穴があります。
フィッシング
OAuthにおける主要な懸念事項の一つがフィッシングの脅威です。攻撃者は、ユーザーにアカウントにログインするための認証情報を入力するよう要求するウェブページへのリンクを頻繁に使用します。そのページは、OAuthを使用するサービスに似た公式のページのように見えます。しかし、ユーザーが公式サービスに認証情報を入力する代わりに、攻撃者のフィッシングWebサイトにその情報を入力してしまいます。ユーザーは、認証ブラウザのポップアップに記載されているアドレスを確認し、サイトが正当なものであることを確認する必要があります。
私たちが発見したフィッシングキャンペーンでは、攻撃者はURLクエリ文字列のパラメーターを変更して、認証情報を盗むウェブサイトにユーザーをリダイレクトすることで、Microsoftユーザーの認証情報へのアクセスを得ました。
このフィッシングページは、多くのユーザーに馴染みのある偽装されたMicrosoftの許可メッセージを表示しました。このページはユーザーにMicrosoftアカウントへのログインを促しますが、ユーザーを認証する代わりに、攻撃者にMicrosoftアカウントのログイン認証情報を提供します。これらの認証情報は、Microsoftアカウントの乗っ取り、ユーザーデータの取得、またはユーザーがそれらの認証情報を再利用した別のサービス上でのアカウントのハイジャックに使用することができます。
過剰に広範な権限
ユーザーがOAuthを通じてアプリをインストールし、承認する際、彼らはしばしば「同意する」をクリックしますが、権限の範囲を十分に確認しません。広範なアクセス権限を持つアプリは、組織にとって潜在的なセキュリティリスクです。
サードパーティアプリは容易に悪用され得ます。攻撃者はOAuthアクセスを利用して、クラウドアカウントを侵害し、乗っ取ることができます。OAuthトークンが明示的に取り消されるまで、攻撃者はユーザーのアカウントとデータへの持続的なアクセスを持ち続けます。たとえユーザーがクラウドアカウントのパスワードを変更したり、二要素認証（2FA）を使用したとしてもです。
私たちの研究では、Office 365用の多くのOAuthアプリが高いレベルの権限を持っていることが分かりました。こちらが私たちの調査結果の一部です。
- 30%のテナントが、「他人に代わってメールを送信する」権限を持つMailMerge365のようなアプリを持っています。
- 30%のテナントが、「Exchangeの設定を管理する」権限を持つTypeAppのようなアプリを持っています。
- 70%のテナントは平均して、「ユーザーとしてメールを送信する」権限を使用するアプリ（例えばTask in A Box）を持っています。
- Microsoft 365のテナントは平均して、「いつでもユーザーのデータにアクセスする」権限を使用するアプリが34個あります（OneSyncの場合がそうです）。
- 「ゲーム」カテゴリーのサードパーティアプリを持つGoogle Workspaceのテナントは、平均して10個のゲームを持っています。
悪意のあるOAuthアプリ
一部のアプリとそのOAuth権限リクエストには明らかに悪意があります。例えば、私たちの研究者は、信頼できるアプリパブリッシャーのふりをして悪意のあるアプリを公開するOiVaVoiiという攻撃キャンペーンを追跡しています。以下がその流れです。
- 攻撃者はまず、正規のアプリパブリッシャーのアカウントを乗っ取ります。
- 信頼できるパブリッシャーになりすまして、攻撃者は悪意のあるアプリを作成し、多くの場合、管理職や企業の幹部であるユーザーに電子メール経由で認証リクエストを送信します。
- 疑いもせずにユーザーはアプリを認証し、それが信頼できるパブリッシャーから来たと信じます。
- 権限が付与されると、攻撃者はユーザーのアカウントを乗っ取ります。
このキャンペーンでは、CEO、一般的なマネージャー、元取締役、社長などのアカウントが乗っ取られたことを検出しました。通常、この乗っ取りは、悪意のあるOAuthアプリがOAuthトークンまたは認証情報を盗む結果です。
公開組織の一見無害な認証プロセスは、多くの疑いもしない被害者を誘い込み、悪意のあるアプリの認証をさせる大きな利点となりました。これらのアプリは主にメールボックスへのアクセス（読み取りと書き込み）に関わっており、以下のことを可能にしました。
- 内部および外部への悪意のあるメールの送信
- 貴重な情報の窃取
- 攻撃後もユーザーのメールを攻撃者に送信し続けるためのメールボックスルールの作成
図1:悪意のあるアプリのOAuth権限リクエストのスクリーンショット
OAuthアプリの悪用
Contactuallyは、不動産の専門家が顧客やセールスを管理するのに役立つ正当なクラウドアプリです。しかし、間違った手に渡ると、その強力な機能は攻撃者が犠牲者の環境内で容易に横断移動し、アクセスを維持することを可能にします。
私たちは、特定の組織内のユーザーを標的とした、メールに基づくフィッシングを使用して開始されたキャンペーンを検出しました。侵害されたアカウントを使用して、攻撃者はContactuallyアプリを認証し、メールボックスのルールを設定しました。これらのルールはおそらく、貴重なメールを外部のアカウントに転送し、攻撃の証拠を削除するために設計されていました。
Contactuallyは正当なパブリッシャーです。このアプリには、ユーザーの連絡先への完全なアクセスやメールの読み取り/書き込みアクセスなど、幅広いアプリの権限があります。しかし、これらは一般的なメールクライアントが使用するものと似ており、アプリの宣伝されている機能の範囲内でもあります。
それでも、攻撃者がアカウントを侵害し、キャンペーンで検出されたように、あなたの環境内でアプリを認証した場合、それらの機能を悪用して持続的な被害を引き起こす可能性があります。