> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# リソース所有者のパスワードフロー

> リソース所有者のパスワードフローの仕組みと、信頼性の高いアプリケーションで使用すべき理由について説明します。

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

推奨はしませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフロー（[OAuth 2.0 RFC 6749のセクション4.3](https://tools.ietf.org/html/rfc6749#section-4.3)で定義され、リソース所有者のパスワード付与やROPGとも呼ばれる）を使用することができます。このフローでは、通常インタラクティブなフォームを使用して、ユーザーが認証情報（ユーザー名/メール/電話番号とパスワード）を提供します。資格情報はバックエンドへ送られ、アクセストークンとの交換前に、将来の使用に備えて保管することができるため、資格情報を保護できるという絶対的な信頼がアプリケーションに対して必要不可欠になります。

また、この条件を満たす場合でも、リソース所有者のパスワードフローの使用は、（[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)のような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。

## 仕組み

<Frame>
  <img src="https://mintcdn.com/docs-dev-actions-triggers-prototype/lj4yKtFBkRd_2GRB/docs/images/ja-jp/cdy7uua7fh8z/4EeYNcnVX1RFcTy5z4lP4v/5d942135c065b7a3732d889a86abe5b6/ROP_Grant.png?fit=max&auto=format&n=lj4yKtFBkRd_2GRB&q=85&s=16d12f499780174e65e3e8514c23b6e4" alt="図 - リソース所有者のパスワードフロー" width="2234" height="1330" data-path="docs/images/ja-jp/cdy7uua7fh8z/4EeYNcnVX1RFcTy5z4lP4v/5d942135c065b7a3732d889a86abe5b6/ROP_Grant.png" />
</Frame>

1. ユーザーがアプリケーション内で\*\*［Login（ログイン）］\*\*をクリックし、資格情報を入力します。
2. アプリケーションがユーザーの資格情報をAuth0の認可サーバー（[`/oauth/token`エンドポイント](/docs/api/authentication#resource-owner-password)）に送ります。
3. Auth0の認可サーバーが資格情報を検証します。
4. Auth0の認可サーバーがアクセストークン（リフレッシュトークンは任意）で応答します。
5. アプリケーションはこのアクセストークンを使ってAPIを呼び出し、ユーザーに関する情報にアクセスできます。
6. APIが要求されたデータを返します。

## 実装方法

リソース所有者のパスワードフローを実装する最も簡単な方法は、チュートリアルに従ってAPIエンドポイントを使用し、「[リソース所有者のパスワードフローを使ってAPIを呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)」ことです。

## レルムの対応

Auth0の拡張機能付与には、リソース所有者のパスワード付与と似たような機能性がありますが、ユーザーディレクトリを（別の接続にマッピングしている）個別のディレクトリに保ち、フローで使用するものを指定できるようになってます。

たとえば、アプリケーションのログインUIにドロップダウンを表示して、ユーザーが`Employees`か`Customers`のユーザータイプを選択できるようにしたいとします。この場合、`Employees`と`Customers`をレルムとして構成（してから、それぞれに対応する接続をセットアップ）して、従業員と顧客の資格情報を個別のユーザーディレクトリに保管することができます。トークンを要求する際にレルム値をユーザーの資格情報と一緒に送信すると、送信したレルムがパスワードの検証に使用されます。

この拡張機能付与の実装については、「[リソース所有者のパスワードフローを使ってAPIを呼び出すレルムの対応を構成する](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)」の「」をお読みください。

## ルール

ルールはリソース所有者のパスワードフロー（レルム拡張機能付与を含む）で実行されます。ただし、リダイレクトのルールは機能しません。ルールで`context.redirect`を指定してリダイレクトの実行を試みると、認証フローはエラーを返します。ルールの詳細については、「[Auth0ルール](/docs/ja-jp/customize/rules)」をお読みください。リダイレクトルールについての詳細は、「[ルール内でユーザーをリダイレクトする](/docs/ja-jp/customize/rules/redirect-users)」をお読みください。

## MFAの対応

リソース所有者のパスワードフローを使用する必要がある反面、より強固な認証が要求される場合には、多要素認証（<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=multifactor-authentication" tip="多要素認証（MFA）: ユーザー名とパスワードに加えて、SMS経由のコードなどの要素を使用するユーザー認証プロセス。" cta="用語集の表示">MFA</Tooltip>）を追加することができます。方法については、「[MFAでリソース所有者のパスワードフローを使って認証する](/docs/ja-jp/secure/multi-factor-authentication/authenticate-using-ropg-flow-with-mfa)」をお読みください。

## 攻撃防御

リソース所有者のパスワードフローと総当たり攻撃防御を併用すると、一部の攻撃防御機能が失敗する可能性があります。ただし、いくつかの一般的な問題は回避することができます。詳細については、「[リソース所有者のパスワードフローと攻撃防御のよくある不具合を回避する](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/avoid-common-issues-with-resource-owner-password-flow-and-attack-protection)」をお読みください。

## もっと詳しく

* [Auth0ルール](/docs/ja-jp/customize/rules)
* [Auth0のフック](/docs/ja-jp/customize/hooks)
* [トークン](/docs/ja-jp/secure/tokens)
* [トークンのベストプラクティス](/docs/ja-jp/secure/tokens/token-best-practices)
* [どちらのOAuth 2.0フローを使用するべきですか？](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)