リソース所有者のパスワードフロー
リソース所有者のパスワード（ROP）フローには、ユーザーのパスワードを処理するアプリケーションが関与するため、サードパーティクライアントで使用してはなりません。
推奨はしませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフロー（OAuth 2.0 RFC 6749のセクション4.3で定義され、リソース所有者のパスワード付与やROPGとも呼ばれる）を使用することができます。このフローでは、通常インタラクティブなフォームを使用して、ユーザーが認証情報（ユーザー名/メール/電話番号とパスワード）を提供します。資格情報はバックエンドへ送られ、アクセストークンとの交換前に、将来の使用に備えて保管することができるため、資格情報を保護できるという絶対的な信頼がアプリケーションに対して必要不可欠になります。
また、この条件を満たす場合でも、リソース所有者のパスワードフローの使用は、（認可コードフローのような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。
仕組み
ユーザーがアプリケーション内で［Login（ログイン）］をクリックし、資格情報を入力します。
アプリケーションがユーザーの資格情報をAuth0の認可サーバー（
/oauth/tokenエンドポイント）に送ります。Auth0の認可サーバーが資格情報を検証します。
Auth0の認可サーバーがアクセストークン（リフレッシュトークンは任意）で応答します。
アプリケーションはこのアクセストークンを使ってAPIを呼び出し、ユーザーに関する情報にアクセスできます。
APIが要求されたデータを返します。
実装方法
リソース所有者のパスワードフローを実装する最も簡単な方法は、チュートリアルに従ってAPIエンドポイントを使用し、「リソース所有者のパスワードフローを使ってAPIを呼び出す」ことです。
レルムの対応
Auth0の拡張機能付与には、リソース所有者のパスワード付与と似たような機能性がありますが、ユーザーディレクトリを（別の接続にマッピングしている）個別のディレクトリに保ち、フローで使用するものを指定できるようになってます。
たとえば、アプリケーションのログインUIにドロップダウンを表示して、ユーザーがEmployeesかCustomersのユーザータイプを選択できるようにしたいとします。この場合、EmployeesとCustomersをレルムとして構成（してから、それぞれに対応する接続をセットアップ）して、従業員と顧客の資格情報を個別のユーザーディレクトリに保管することができます。トークンを要求する際にレルム値をユーザーの資格情報と一緒に送信すると、送信したレルムがパスワードの検証に使用されます。
この拡張機能付与の実装については、「リソース所有者のパスワードフローを使ってAPIを呼び出すレルムの対応を構成する」の「」をお読みください。
ルール
ルールはリソース所有者のパスワードフロー（レルム拡張機能付与を含む）で実行されます。ただし、リダイレクトのルールは機能しません。ルールでcontext.redirectを指定してリダイレクトの実行を試みると、認証フローはエラーを返します。ルールの詳細については、「Auth0ルール」をお読みください。リダイレクトルールについての詳細は、「ルール内でユーザーをリダイレクトする」をお読みください。
MFAの対応
リソース所有者のパスワードフローを使用する必要がある反面、より強固な認証が要求される場合には、多要素認証（MFA）を追加することができます。方法については、「MFAでリソース所有者のパスワードフローを使って認証する」をお読みください。
攻撃防御
リソース所有者のパスワードフローと総当たり攻撃防御を併用すると、一部の攻撃防御機能が失敗する可能性があります。ただし、いくつかの一般的な問題は回避することができます。詳細については、「リソース所有者のパスワードフローと攻撃防御のよくある不具合を回避する」をお読みください。