リソース所有者のパスワードフローと攻撃防御のよくある不具合を回避する

リソース所有者のパスワードフローを使って、攻撃防御が有効なサーバー側APIを呼び出すときに発生する一般的な問題を回避する方法について説明します。

リソース所有者のパスワード（ROP）フローには、ユーザーのパスワードを処理するアプリケーションが関与するため、サードパーティクライアントで使用してはなりません。

推奨はされませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフロー（リソース所有者のパスワード付与（ROPG）とも呼ばれる）を使ってサーバー側APIを呼び出すことができます。このフローは、ユーザーに資格情報（ユーザー名とパスワード）の提供を要求するもので、通常は対話型フォームを使用します。Auth0でこの資格情報を検証中に総当たり攻撃防御が有効になっている場合、攻撃の有無も確認され、攻撃が検出されたら適切な措置が講じられます。

残念ながら、このフローと総当たり攻撃防御を併用する場合には、一部の攻撃防御が機能しない可能性があります。ただし、いくつかの問題は回避することができます。

​

攻撃防御とサーバー側API

総当たり攻撃防御と不審なIPのスロットリングは、ユーザーのIPアドレスに応じて行われます。サーバーからAPIを呼び出す場合、Auth0はサーバーのIPアドレスをユーザーのIPアドレスとして扱い、総当たり攻撃防御と不審なIPのスロットリング機能への入力として報告します。これにより、誤検出が発生する可能性があり、攻撃防御がユーザーをブロックしたり、正当な要求にもかかわらず警告が表示される恐れがあります。

これを回避するには、ユーザーのIPアドレスを資格情報とともにAuth0に送り、IPアドレスを信頼するようにアプリケーションを構成します。

セキュリティに関する考慮事項があるため、この方法で構成できるのは、認証済みアプリケーション (クライアントシークレットに基づいて認証されたアプリケーションなど）に限られます。認証済みアプリケーションは、保護されたリソース（通常はサーバー側）でしか使用できません。ネイティブアプリケーションやシングルページアプリケーション（SPA）では、シークレットが保管できないため、使用しないでください。

​

IPアドレスを信頼するようにアプリケーションを構成する

通常のWebアプリケーションまたはマシンツーマシンアプリケーションを登録します。アプリケーションの構成中に、以下の操作を行います。

1. ［Settings（設定）］ で、None以外の ［Token Endpoint Authentication Method（トークンエンドポイント認証方法）］ を選択します。
2. ［Advanced Settings（高度な設定）］ の ［OAuth］ タブで、［Trust Token Endpoint IP Header（トークンエンドポイントのIヘッダーを信頼する）］ を有効にします。これにより、総当たり攻撃防御に対して、auth0-forwarded-forヘッダーがユーザーのIPアドレスの信頼できるソースとして設定されます。この設定は、非認証アプリケーションでは利用できません。

​

サーバーからユーザーのIPアドレスを送信する

1. リソース所有者のパスワードフローを使用してトークンを要求する場合には、ユーザーのIPアドレスの値が入ったauth0-forwarded-forヘッダーを含めてください。入力したIPアドレスがユーザーのもので間違いないことを確認します。

   auth0-forwarded-forなどのヘッダー（あるいはアプリケーションのデータ全般）をユーザーのIPアドレスのソースとして信頼することにはリスクがあります。ヘッダーは、簡単になりすまして攻撃防御の検証を回避することができるので、信頼できるヘッダーであることを知っている場合のみ信頼するようにしてください。

2. 総当たり攻撃防御と不審なIPのスロットリングをトリガーするときに、IP許可リストを無視するように指定します。

総当たり攻撃防御と不審なIPのスロットリングの許可リストを作成する

認証済のアプリケーションがauth0-forwarded-forヘッダーを送信するように設定されている場合には：

• auth0-forwarded-forヘッダーに含まれているIPアドレスのみが、総当たり攻撃防御と不審なIPのスロットリングのAllowListに照らし合わせてチェックされます。
• プロキシIPアドレスは、総当たり攻撃防御と不審なIPのスロットリングで無視されるため、AllowListに加える必要はありません。
• プロキシを使用している特定のクライアントを、総当たり攻撃防御や不審なIPのスロットリングの対象から外したい場合は、AllowListに追加してください。

auth0-forwarded-forヘッダーは、クライアントシークレットを使った認証済みの呼び出しにのみ受け入れられます。アプリケーションが認証されていないか、auth0-forwarded-forヘッダーを送信するように設定されていない場合には：

• 各要求の送信元IPアドレスが、総当たり攻撃防御と不審なIPのスロットリングのAllowListに照らし合わせてチェックされます。
• AllowListにIPプロキシが含まれている場合は、そのプロキシを通過するすべてのトラフィックが総当たり攻撃防御と不審なIPのスロットリングの対象から外されます。このような処理が希望に沿うかどうかをご確認ください。

​

例

var request = require("request");

app.post('/api/auth', function(req, res, next) {
  var options = {
    method: 'POST',
    url: 'https://{yourDomain}/oauth/token',
    headers: {
      'content-type': 'application/x-www-form-urlencoded',
      'auth0-forwarded-for': req.ip // End user ip
    },
    form: {
      grant_type: 'password',
      username: 'USERNAME',
      password: 'PASSWORD',
      audience: 'YOUR_API_IDENTIFIER',
      scope: 'SCOPE',
      client_id: '{yourClientId}',
      client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated
    }
  };

  request(options, function (error, response, body) {
    if (error) return next(error);

    // ...
  });
});

​

侵害されたパスワードの検出応答の処理

テナントの［Breached Password Detection（侵害されたパスワードの検出）］が有効な場合は、Auth0 Authentication APIからの応答に適宜対処するようアプリケーションを構成する必要があります。

たとえば、ROPフローを使ってパスワードを送信してAuth0で侵害が検出された場合、Authentication APIはHTTP 401 Unauthorizedステータスコードと次の本文が記述された応答を返します。

{
    "error": "password_leaked",
    "error_description": "This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application). Please check your email for more information."
}

アプリケーションはこのエラーを処理し、メッセージをユーザーに表示し、インタラクティブなパスワードリセットフローをトリガーします。

​

ログで検証する

設定が正しく機能している場合は、ログに以下のように表示されます。

type:  sepft
...
ip:  <ip from auth0-forwarded-for header>
client_ip:  <ip of actual client/proxy>
...

​

もっと詳しく

• リソース所有者のパスワードフロー
• リソース所有者のパスワードフローを使ってAPIを呼び出す
• 攻撃防御