ユーザーの同意とサードパーティアプリケーション

アプリケーションがユーザーに代わってAPIへのアクセスを要求する際に、Auth0がユーザーの同意をどのように処理するかを学びます。

OAuth では、アプリケーションがユーザーに代わってAPIにアクセスできます。アプリケーションがユーザーに代わって処理を行うには、事前にユーザーが要求された権限を明示的に承認する必要があります。この承認の手順をユーザー同意と呼びます。

サードパーティアプリケーションでは、ユーザー同意が常に必要です。ユーザーは認可リクエストのたびに承認しなければなりません。ファーストパーティアプリケーションでは、アプリケーションを管理しており、適切に動作すると信頼できるため、設定によっては同意を省略できます。

​

同意ダイアログ

サードパーティアプリケーションがユーザーを /authorize エンドポイントにリダイレクトして API へのアクセスをリクエストすると、Auth0 は、そのアプリケーションがリクエストしている権限の一覧を表示する同意ダイアログを表示します。

次の認可リクエストでは、API の read:posts 権限と write:posts 権限を承認するようユーザーに求める同意ダイアログが表示されます。

GET /authorize?
  client_id=tpc_THIRD_PARTY_CLIENT_ID
  &redirect_uri=https://partner.example.com/callback
  &response_type=code
  &scope=read:posts write:posts
  &audience=https://social.example.com
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256
  &state=STATE_VALUE

ユーザーが承認すると、Auth0 はそのアプリケーション、API、要求されたスコープの組み合わせに対するユーザーの同意を表すユーザーグラントを作成します。アプリケーションは通常どおり認可コードを受け取ります。

いったん同意すると、明示的に同意を取り消さない限り、その後のログイン時に同意ダイアログは表示されません。

強化されたセキュリティ制御が適用されたサードパーティアプリケーションでは、このリリースで OIDC スコープ (openid、profile、email) はサポートされていません。同意ダイアログには API スコープのみが表示されます。サードパーティアプリケーションの OIDC サポートは、今後のリリースで提供される予定です。

​

スコープの説明

デフォルトでは、同意ページではユーザーに同意を求める際にスコープ名が使用されます。以下のように、わかりやすく表示されるよう、スコープは action:resource_name 形式で定義します。

同意ページでは、同じ API のスコープがグループ化され、すべてのアクションが 1 行にまとめて表示されます。たとえば、上記の設定では Posts: read and write your posts と表示されます。

スコープ名の代わりに Description フィールドを表示するには、テナントの use_scope_descriptions_for_consent フラグを true に設定します。

この設定は、そのテナント上のすべての API の同意プロンプトに影響します。

​

拒否されたアクセス許可への対応

ユーザーが同意を拒否した場合の動作は、アプリケーションのリダイレクトポリシーによって異なります。

• open_redirect_protection (サードパーティ アプリの既定) : Auth0 はリダイレクトせず、代わりにエラーページを表示します。これにより、オープンリダイレクト攻撃を防止します。
• allow_always: Auth0 は access_denied エラーを付けて redirect_uri にリダイレクトします。

HTTP/1.1 302 Found
Location: https://partner.example.com/callback?
    error=access_denied
    &state=STATE_VALUE

​

ファーストパーティアプリケーションの同意をスキップする

API で Allow Skipping User Consent オプションが有効になっている場合、ファーストパーティアプリケーションでは同意ダイアログをスキップできます。

Allow Skipping User Consent の切り替えに移動するには、Applications > APIs > (API を選択) > Settings > Access Settings を選択します。

サードパーティアプリケーションでは常に同意が必要で、同意ダイアログをスキップすることはできません。

ファーストパーティアプリケーションで同意をスキップする場合でも、アプリケーションが検証不能なコールバック URI (localhost やカスタム URI スキームなど) を使用していると、ログイン確認プロンプトが表示されることがあります。これは、同じデバイス上でのアプリケーションのなりすましからユーザーを保護するためです。詳しくは、アプリケーションのなりすまし対策 を参照してください。

​

Organizations における同意

サードパーティアプリケーションが組織コンテキストでユーザーを認証する場合、同意は組織ごとに設定されます。ある組織でアプリケーションへの同意を行ったユーザーは、別の組織で同じアプリケーションに対して同意したことにはなりません。

つまり、次のようになります。

• 新しい組織から同じサードパーティアプリケーションにアクセスする場合、別の組織ですでに同意していても、ユーザーには再度同意ダイアログが表示されます。
• ある組織で同意を取り消しても、別の組織での同意には影響しません。
• グラントは組織ごとに保存されます。

特定の組織コンテキストで再度同意を求めるには、/authorize リクエストに prompt=consent を含めます。

​

同意を取り消す

特定のアプリケーションに対するユーザーの同意を取り消すには、次の手順を実行します。

1. Auth0 Dashboard > User Management > Users に移動します。
2. ユーザーを選択します。
3. Authorized Applications タブを選択します。
4. アプリケーションの横にある 取り消す を選択します。

​

パスワードベースのフロー

Resource Owner Password Flow は、サードパーティアプリケーションでは利用できません。ファーストパーティアプリケーションにのみ適用されます。

ファーストパーティアプリケーションでは、ユーザーは自身のパスワードをアプリケーションに直接提供するため、同意ダイアログは表示されません。これは、ユーザーのアカウントへの完全なアクセス権をそのアプリケーションに与えるのと同等です。

​

同意を毎回求める

ユーザーにログインのたびに同意を求めるには (既存のグラントがある場合も含め) 、/authorize request に prompt=consent を含めます。

GET /authorize?
  client_id=tpc_THIRD_PARTY_CLIENT_ID
  &redirect_uri=https://partner.example.com/callback
  &response_type=code
  &scope=read:posts write:posts
  &audience=https://social.example.com
  &prompt=consent
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256
  &state=STATE_VALUE

​

詳しくはこちら

• サードパーティアプリケーション
• ファーストパーティアプリケーションとサードパーティアプリケーション
• サードパーティアプリケーションのセキュリティ制御
• アプリケーションのグラントタイプ
• アプリケーションのなりすまし対策