Skip to main content
Resource Owner Password (ROP) フローではアプリケーションがユーザーのパスワードを扱うため、サードパーティのクライアントでは使用してはいけません。
推奨はしていませんが、高信頼アプリケーションでは、 Passwordフロー (OAuth 2.0 RFC 6749, section 4.3 で定義されており、Resource Owner Password Grant または ROPG と呼ばれることもあります) を使用できます。このフローでは、通常は対話型フォームを使用して、ユーザーに資格情報 (ユーザー名/email/phone とパスワード) の入力を求めます。資格情報はバックエンドに送信され、 と交換される前に将来利用するため保存される可能性があるため、アプリケーションがこの情報を完全に信頼できることが不可欠です。 この条件を満たしていても、Resource Owner Passwordフローを使用すべきなのは、リダイレクトベースのフロー (たとえば 認可コードフロー) を利用できない場合に限られます。

​
動作の仕組み

図 - Resource Owner Passwordフロー
  1. ユーザーはアプリケーション内のLoginをクリックし、資格情報を入力します。
  2. アプリケーションは、ユーザーの資格情報を Auth0 Authorization Server (/oauth/token エンドポイント) に送信します。
  3. Auth0 Authorization Server は資格情報を検証します。
  4. Auth0 Authorization Server はアクセストークン (必要に応じてリフレッシュトークンも) を返します。
  5. アプリケーションはアクセストークンを使用して API を呼び出し、ユーザーに関する情報にアクセスできます。
  6. API はリクエストされたデータを返します。

​
実装方法

Resource Owner Password Flow を実装する最も簡単な方法は、API エンドポイントの使用方法を説明したチュートリアル「Resource Owner Password Flow を使用して API を呼び出す」に従うことです。

​
レルムのサポート

Auth0 では、Resource Owner Password グラントと同様の機能を持つ拡張グラントを提供しています。この拡張グラントを使うと、個別のユーザーディレクトリ (それぞれ別の接続に対応) を分けて維持したまま、フローの中でどれを使用するかを指定できます。 たとえば、アプリケーションのログイン画面にドロップダウンを表示し、ユーザーが自分のユーザータイプとして Employees または Customers を選択できるようにしたいとします。この場合、Employees と Customers をレルムとして設定し (それぞれに対応する接続も設定) 、従業員と顧客の資格情報を別々のユーザーディレクトリで管理できるようにします。トークンをリクエストするときは、ユーザーの資格情報とあわせてレルム値も送信し、送信されたレルムを使ってパスワードが検証されます。 この拡張グラントの実装方法について詳しくは、Resource Owner Password Flow を使用して API を呼び出す: レルムサポートを構成する をご覧ください。

​
ルール

ルールは、Resource Owner Passwordフロー (レルム拡張グラントを含む) でも実行されます。ただし、リダイレクトルールは機能しません。ルール内で context.redirect を指定してリダイレクトしようとすると、認証フローはエラーを返します。ルールの詳細については、Auth0 ルール を参照してください。リダイレクトルールの詳細については、ルール内からユーザーをリダイレクトする を参照してください。

​
MFA への対応

より強力な認証が必要で、Resource Owner Password Flow を使用する必要がある場合は、 (MFA) を追加できます。手順については、MFA を使用して Resource Owner Password Flow で認証する をご覧ください。

​
攻撃対策

を使用する Resource Owner Passwordフロー では、一部の機能が正しく動作しないことがあります。ただし、よくある問題の一部は回避できます。詳しくは、Resource Owner Passwordフロー と攻撃対策でよくある問題を回避するをご覧ください。

​
詳しくはこちら