メインコンテンツへスキップ
リソース所有者のパスワードフロー（リソース所有者のパスワード付与（ROPG）と呼ばれることもある）は、信頼性の高いアプリケーションでアクティブな認証を行うために使用されます。認可コードや暗黙的付与とは異なり、この認証メカニズムではユーザーはAuth0にリダイレクトされず、単一の要求でユーザーを認証し、パスワード資格情報をトークンと交換します。 OIDC準拠のパイプラインがリソース所有者のパスワード（ROP）フローに影響を与えるエリアは以下のとおりです。
  • 認証要求
  • 認証応答
  • IDトークンの構造
  • アクセストークンの構造

​
認証要求

​
旧

POST /oauth/ro HTTP 1.1
Content-Type: application/json
{
  "grant_type": "password",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w",
  "connection": "my-database-connection",
  "scope": "openid email favorite_color offline_access",
  "device": "my-device-name"
}
deviceパラメーターは、offline_accessスコープを渡してリフレッシュトークンを要求する場合にのみ必要です。

​
OIDC準拠

POST /oauth/token HTTP 1.1
Content-Type: application/x-www-form-urlencoded
grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fpassword-realm&client_id=123&username=alice&password=A3ddj3w&realm=my-database-connection&scope=openid+email+offline_access&audience=https%3A%2F%2Fapi.example.com
  • 資格情報交換を実行するエンドポイントは/oauth/tokenです。
  • Auth0の独自の付与タイプは、特定の接続（realm）からユーザーを認証するために使用されます。標準のOIDCパスワード付与もサポートされていますが、realmなどAuth0固有のパラメーターは受け入れません。
  • favorite_colorは有効なスコープでなくなりました。
  • deviceパラメーターは削除されています。
  • audienceパラメーターは任意です。

​
認証応答

​
旧

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • 返されるアクセストークンは、/userinfoエンドポイントの呼び出しに対してのみ有効です。
  • リフレッシュトークンは、deviceパラメーターが渡され、offline_accessスコープが要求された場合にのみ返されます。

​
OIDC準拠

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "eyJ...",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • 返されるアクセストークンは、/userinfoエンドポイント（audienceパラメーターで指定したAPIがRS256を署名アルゴリズムとして使用していることを条件とする）と、audienceパラメーターで指定したリソースサーバー（任意）の呼び出しに対してのみ有効です。
  • IDトークンは、公開アプリケーションによって要求されると、RS256を使用して強制的に署名されます。詳細については、「機密アプリケーションとパブリックアプリケーション」をお読みください。
  • リフレッシュトークンは、offline_accessスコープが付与された場合にのみ返されます。

​
IDトークンの構造

​
旧

​
OIDC準拠

  • IDトークンは、公開アプリケーションによって要求されると、RS256を使用して強制的に署名されます。
  • favorite_colorクレームには名前空間が存在し、ルールを通じて追加される必要があります。詳細については、「名前空間カスタムクレームを作成する」をお読みください。

​
アクセストークンの構造（任意）

​
旧

JSON
SlAV32hkKG
返されるアクセストークンは不透明で、/userinfoエンドポイントの呼び出しに対してのみ有効です。

​
OIDC準拠

  • 返されるアクセストークンは、/userinfoエンドポイント（audienceパラメーターで指定したAPIがRS256を署名アルゴリズムとして使用していることを条件とする）と、audienceパラメーターで指定したリソースサーバーの呼び出しに対してのみ有効です。
  • /userinfoが唯一指定されたオーディエンスである場合でも、不透明なアクセストークンが返されることがあります。

​
標準のパスワード付与要求

Auth0のパスワードレルム付与は標準のOIDCによって定義されてはいませんが、Auth0固有のrealmパラメーターをサポートしているため、レガシーのリソース所有者エンドポイントの代わりとして推奨されます。OIDC認証を使用する場合には、標準のOIDCフローもサポートされます。

​
もっと詳しく