推奨はしませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフロー（OAuth 2.0 RFC 6749のセクション4.3で定義され、リソース所有者のパスワード付与やROPGとも呼ばれる）を使用することができます。このフローでは、通常インタラクティブなフォームを使用して、ユーザーが認証情報（ユーザー名/メール/電話番号とパスワード）を提供します。資格情報はバックエンドへ送られ、アクセストークンとの交換前に、将来の使用に備えて保管することができるため、資格情報を保護できるという絶対的な信頼がアプリケーションに対して必要不可欠になります。 また、この条件を満たす場合でも、リソース所有者のパスワードフローの使用は、（認可コードフローのような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。Documentation Index
Fetch the complete documentation index at: https://auth0-feat-ionic-capacitor-quickstart-modernization.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
仕組み
- ユーザーがアプリケーション内で**［Login（ログイン）］**をクリックし、資格情報を入力します。
- アプリケーションがユーザーの資格情報をAuth0の認可サーバー（
/oauth/tokenエンドポイント）に送ります。 - Auth0の認可サーバーが資格情報を検証します。
- Auth0の認可サーバーがアクセストークン（リフレッシュトークンは任意）で応答します。
- アプリケーションはこのアクセストークンを使ってAPIを呼び出し、ユーザーに関する情報にアクセスできます。
- APIが要求されたデータを返します。
実装方法
リソース所有者のパスワードフローを実装する最も簡単な方法は、チュートリアルに従ってAPIエンドポイントを使用し、「リソース所有者のパスワードフローを使ってAPIを呼び出す」ことです。レルムの対応
Auth0の拡張機能付与には、リソース所有者のパスワード付与と似たような機能性がありますが、ユーザーディレクトリを（別の接続にマッピングしている）個別のディレクトリに保ち、フローで使用するものを指定できるようになってます。 たとえば、アプリケーションのログインUIにドロップダウンを表示して、ユーザーがEmployeesかCustomersのユーザータイプを選択できるようにしたいとします。この場合、EmployeesとCustomersをレルムとして構成（してから、それぞれに対応する接続をセットアップ）して、従業員と顧客の資格情報を個別のユーザーディレクトリに保管することができます。トークンを要求する際にレルム値をユーザーの資格情報と一緒に送信すると、送信したレルムがパスワードの検証に使用されます。
この拡張機能付与の実装については、「リソース所有者のパスワードフローを使ってAPIを呼び出すレルムの対応を構成する」の「」をお読みください。
ルール
ルールはリソース所有者のパスワードフロー（レルム拡張機能付与を含む）で実行されます。ただし、リダイレクトのルールは機能しません。ルールでcontext.redirectを指定してリダイレクトの実行を試みると、認証フローはエラーを返します。ルールの詳細については、「Auth0ルール」をお読みください。リダイレクトルールについての詳細は、「ルール内でユーザーをリダイレクトする」をお読みください。