☰

oAuth はどのように安全になるのでしょうか?

tag-icon • tag-icon security oauth2
oAuth はどのように安全になるのでしょうか?

Google の IMAP メールなど、多くのサービスでは、ユーザー ID/パスワード認証から oAuth の使用に移行しています。

監視するリソースが豊富な大規模で資金力のある企業が提供するサービスである以外に、oAuth はどのような点でより安全ですか?

答え1

技術的な利点は次のとおりです。

  • OAuth の「初期認証」部分は Web サイトを通じて行われるため、パスワード以外の認証要素を簡単に要求できます。たとえば、TOTP ワンタイム コードや U2F キーを要求することができます。(必要に応じて reCAPTCHA を使用することもできます。)

    • 通常、これは、入力するパスワードが Web ブラウザーにのみ表示され、メール アプリでは実際に表示されないことも意味します。

      最近、特に Google は、ホスト プログラムにパスワードを公開する可能性のある「埋め込み」ブラウザー内に認証ページが読み込まれるのを防止することに積極的に取り組んでいます。(古い GNOME バージョンでは、当時はまだ OAuth2 をサポートしていなかった特定の Google API を使用する必要があったため、これを半ば合法的に行っていました。)

    • また、Web サイトを使用すると、UI を実際の Web ベースのサービスとより一貫性のあるものにすることができ、新しいカスタムの多段階認証方法を考案するよりもアプリに実装するのがいくらか簡単になります。

      (SSH と比較すると、SSH にはカスタム テキストを含む複数のプロンプトを表示できる「KeyboardInteractive」認証方法があります。基本的なパスワード + OTP またはキー ペア + OTP では問題なく機能しますが、2FA に関しては全体的にかなり扱いにくいです。多くの企業は、OAuth2 トークンや Kerberos チケットに非常によく似た方法で、有効期間の短い SSH キー ペアを使用するシステムを実際に実装しています。つまり、企業の SSO Web サイトを通じて認証して、その日の SSH キーを取得します。)

  • メール クライアントに発行されたトークンは、特定のサービス (スコープ)、この場合は IMAP と SMTP にのみアクセスできます。たとえば、ドライブ ファイルや YouTube の履歴にアクセスするために使用することはできません。

    • ただし、これはサービス プロバイダー側​​で悪用される可能性があります (たとえば、Google では、100 人を超えるユーザーがいてメール関連のスコープにアクセスする OAuth2 アプリに対して高価な「検証」を要求します)。

    • 手動で生成された「アプリパスワード」できた特定のサービスに限定することもできますが、その機能を効果的に使用する人はほとんどいません。たとえば、これは GitHub アクセス トークンで可能ですが、どのスコープがどのアプリに必要なのかを判断するには (多くの場合は試行錯誤で) 多大な精神的労力がかかるため、すべての可能なスコープが有効になっているトークンが多数生成されます...

サービス プロバイダーにとって、「多層防御」の利点もいくつかあります。

  • 実際のサービスは実際のパスワード (リフレッシュ トークンも受信せず、有効期間の短いアクセス トークンのみ) を受信することはありません。そのため、1 つのサービスが侵害された場合でも、他のサービスにアクセスするための資格情報を収集することはできません (「横方向の移動」?)。

    • これは、Active Directory での Kerberos チケットの使用や、エンタープライズ SSO システムでの SAML アサーションの使用と非常によく似ています。

      このようなシステムでは、すべてのサービスがユーザー データベースへのアクセスを必要とするのではなく (すべてが貴重なターゲットになるのではなく)、特権を持つのは KDC または IdP だけになります。

答え2

少なくともいくつかの良い点が考えられます。

  1. パスワードが再利用される可能性を減らします。パスワードを入力する場所が増えるほど、重大な漏洩の可能性が高まり、パスワードを再利用すると他のサイトも危険にさらされます。
  2. 大量のサイトへのアクセスを一度に素早く取り消すことができる中央機関を提供します。サイトには Google から「アクセス トークン」のみが付与されるため、サイトはすべて一意であり、個別に取り消すことも、一度にすべて取り消すこともできます。
  3. これにより、サイトがパスワードの変更を処理し、パスワードを安全に保管する必要性が隠されます。パスワードを受け取らない場合は、それを平文で保管することはできません。一部のサイトでは、平文で保管していたか、おそらく今でも保管しています
    。すべきトークンは引き続き安全に処理されますが、侵害が発生した場合のプロセスはよりシンプルになります。OAuth プロバイダーに侵害を通知すると、ユーザーが次に認証したときに新しいトークンを取得するまでトークンが取り消されます。

これは OAuth プロバイダーが安全であることに依存しますが、パスワードを 1 か所でリセットする方が、50 または 500 のサイトでリセットするよりもはるかに簡単です。

関連情報