メインコンテンツへスキップ
GDPR 第7条に基づき、個人データの処理については、明確で容易にアクセスできる形でユーザーの同意を得る必要があります。また、ユーザーが同意したことを示せるようにし、いつでも簡単に同意を撤回できる手段も提供する必要があります。 この記事では、これらの要件を実装するために Auth0 の機能をどのように利用できるかを説明します。
これらのドキュメントの内容は、法的助言を目的としたものではなく、また法的支援に代わるものでもありません。GDPR の内容を理解し、これを遵守する最終的な責任はお客様にありますが、Auth0 は可能な限り GDPR 要件への対応を支援します。
サインアップ時には、ユーザーから同意を取得する必要があります。Auth0 では、この情報をユーザーメタデータに保存できます。利用できる方法はいくつかあり、Auth0 を使ってユーザーをどのように認証するかによって異なります。メタデータを使用したソリューションを設計する前に、必ず制限事項を理解しておいてください。Auth0 では、user_metadata の合計サイズは 16 MB に制限されています。詳しくは、Metadata Field Names and Data Types を参照してください。
Auth0 のメタデータは安全なデータストアではないため、機微な情報 (高リスクのシークレットや、社会保障番号、クレジットカード番号などの個人を特定できる情報 (PII) ) の保存には使用しないでください。Auth0 をご利用のお客様には、メタデータに保存するデータを評価し、ID 管理およびアクセス管理の目的に必要なものだけを保存することを強く推奨します。

​
Lock を使用する

Lock UI をカスタマイズして、利用規約やプライバシーステートメントのページへのリンク、およびユーザーがサインアップする際にチェックする必要がある同意チェックボックスを表示できます。これは、Lock の mustAcceptTerms オプションで実現できます。このプロパティを true に設定すると、サインアップ前にチェックが必須の利用規約とあわせてチェックボックスが表示されます。利用規約は languageDictionary オプションで指定できます。詳細については、Lock の設定オプションを参照してください。 ユーザーが同意してサインアップしたら、初回ログイン時に実行される ルール を使用して、同意情報を user_metadata に保存します。Rules の詳細については、Auth0 Rulesを参照してください。 サインアップ時にユーザーからより多くの情報を取得したい場合で、データベース接続を使用してユーザーを認証している場合は、Lock UI にカスタムフィールドを追加できます。これは、Lock の additionalSignUpFields オプションで実現できます。カスタムフィールドはすべて自動的に user_metadata に追加されます。 ソーシャルログインを使用している場合は、カスタムフィールドを追加できませんが、ユーザーを別のページにリダイレクトして、そこで同意や追加情報を求めたあと、認証トランザクションを完了するためにリダイレクトで戻すことができます。これは、redirect rules で実現できます。詳細については、Rules 内からユーザーをリダイレクトするを参照してください。サインアップ処理が完了したら、 の Update User エンドポイントを呼び出して、同意情報を user_metadata に保存します。 これらのシナリオの実装方法については、GDPR: Lock で同意を追跡するを参照してください。

​
カスタム UI を使用する

データベース接続を使用するカスタムのサインアップフォームを利用している場合は、ユーザーの同意を取得するために、サインアップ画面に追加のフィールドを設ける必要があります。その後、Auth0 にユーザーを作成するため、Authentication API の Signup endpoint を呼び出します。この時点で、同意情報は user_metadata の一部として設定できます。 また、SPA から Auth0.js を使用している場合は、signup method を使用して Auth0 にユーザーを作成し、同意情報を user_metadata の一部として設定できます。 ソーシャルプロバイダーを使用するカスタムのサインアップフォームを利用している場合、サインアップ時にユーザーの同意情報を設定することはできませんが、ユーザーの作成後すぐに更新できます。Management API の Update User endpoint を呼び出して、同意情報を user_metadata に保存してください。 これらのシナリオの実装方法については、GDPR: カスタム UI で同意を追跡する を参照してください。 既存のユーザーに同意を求める必要があり、既存のデータベースからユーザーを Auth0 に移行する場合は、Automatic User Migration 機能を利用できます。これを有効にすると、有効化後にユーザーが初めてログインした時点で、そのユーザーはパスワードをリセットすることなく Auth0 に作成されます。これを行うには、次の対応が必要です。
  • ユーザーのデータの利用方法、利用期間、ユーザーの権利などについて、ユーザーに表示する通知を作成し、あわせて UI のサインアップボックスをカスタマイズします。
  • 以前の利用規約や過去のプライバシー認証に基づいて、ユーザーに再同意が必要かどうかを判断します。
利用規約が変更されるたびに、ユーザーに再度同意を求める必要があります。 GDPR に基づき、ユーザーが自身の個人データの処理に同意したことを示せるようにしておく必要があります。 Auth0 では、ユーザーの同意情報を user_metadata の一部として保存できます。ユーザーが同意したかどうかを示すフラグだけを保存することも、同意情報や設定のセット (たとえば、ユーザーが同意した日付、同意した利用規約などを含む) を保存することもできます。その後、この情報には Management API を使用してアクセスし、必要に応じて操作できます。 Management API には、ユーザー検索に関する複数のオプションに加え、ユーザーメタデータを更新したり、ユーザーを一括エクスポートしたりするためのエンドポイントも用意されています。 Management API にアクセスするには、が必要です。Management API 用のアクセストークンを取得する方法については、Management API アクセストークンを参照してください。

​
メールアドレスでユーザーを検索する

メールアドレスでユーザーを検索するには、Search User by Email エンドポイントを使用します。 返されるフィールドを制限するには、リクエストパラメーター fields を user_metadata に設定します。これにより、完全なユーザープロファイルではなく、user_metadata のみが返されます。 リクエスト例: レスポンス例: 
[
  {},
  {
    "user_metadata": {
      "consent": {
	    "given": true,
	    "date": "01/23/2018",
	    "text_details": "some-url"
	  }
    }
  }
]

​
IDでユーザーを検索

ユーザーを ID で検索するには、Get a User エンドポイントを使用します。 返されるフィールドを制限するには、fields リクエストパラメーターを user_metadata に設定します。これにより、完全なユーザープロファイルではなく、user_metadata のみが返されます。 リクエスト例: レスポンス例: 
{
  "user_metadata": {
    "consent": {
	    "given": true,
	    "date": "01/23/2018",
	    "text_details": "some-url"
  	}
  }
}
ユーザーの user_metadata を更新するには、Update a User エンドポイントを使用します。 リクエストの構造は、メタデータをルートプロパティとして構成しているか、内部プロパティとして構成しているかによって異なります。 メタデータがルートプロパティとして保存されている場合: 
{
  "consentGiven": true,
  "consentDetails": "some-url"
}
メタデータが入れ子のプロパティに保存されている場合: 
{
  "consent": {
    "given": true,
    "text_details": "some-url"
  }
}

​
ルートプロパティの更新

ルートレベルのプロパティに対する更新はマージされるため、更新するフィールドの値だけを送信すれば十分です。たとえば、同意日を追加し、それを 01/23/2018 に設定するとします。 これにより、ユーザープロファイルに user_metadata.consentDate という新しいプロパティが追加され、顧客が同意した日付が格納されます。レスポンスには、ユーザープロファイル全体が返されます。更新後のメタデータは次のようになります。 
{
  "consentGiven": true,
  "consentDate": "01/23/2018",
  "consentDetails": "some-url"
}

​
ネストされたプロパティを更新する

ネストされたプロパティを更新するには、1 つのプロパティしか更新しない場合でも、metadata オブジェクト全体を送信する必要があります。オブジェクト全体を含めないと、Auth0 によって既存のプロパティが削除されます。 同意日付用のネストされたプロパティを追加し、その値を 01/23/2018 に設定しましょう。 これにより、ユーザープロファイルに user_metadata.consent.date, という新しいプロパティが追加され、顧客が同意した日付が保存されます。レスポンスには完全なユーザープロファイルが返されます。更新後のメタデータは次のようになります。 
{
  "consent": {
    "given": true,
    "date": "01/23/2018",
    "text_details": "some-url"
  }
}
Management API を使用してユーザーのリストをエクスポートするには、User Export endpoint を使用します。 このエンドポイントは、接続に関連付けられたすべてのユーザーをエクスポートするジョブを作成します。必要なのは接続の ID です。この ID を確認するには、Get Connections endpoint を使用します (この接続だけを取得するには、name パラメーターに接続の名前を設定できます) 。 接続 ID と Management API 用のアクセストークンを取得したら、ユーザーのエクスポートを開始できます。リクエストとレスポンスのサンプルについては、Import and Export Users を参照してください。Management API 用のアクセストークンを取得する方法については、Management API Access Tokens を参照してください。 さらに、以下も必要です。
  • 同意をどのように追跡するかを決定します。ユーザーが同意した日付だけでなく、ユーザーが同意した利用規約のバージョン情報も含めることを推奨します。また、同意を撤回したユーザーの情報を保持する配列を含めることも推奨します (ユーザーは同意と撤回を複数回行える点に注意してください) 。
  • 同意をどこに保存するかを選択します。Auth0 のデータベース、またはその他の場所に保存できます。
ユーザーがアプリから同意を撤回できるようにする必要があります。この選択肢は見つけやすく、他と明確に区別できるものでなければなりません。ユーザーが同意を撤回することを決めたら、必要な対応を行ってください。 まず、同意の撤回をどのように処理するかを決める必要があります。ユーザーを削除するのか、それとも削除済みとしてフラグを付けるのかを判断してください。

​
ユーザーを削除

ユーザーを削除するには、Delete a User エンドポイントを使用します。 このエンドポイントのレスポンス本文は空です。そのため、ユーザーが正常に削除されたことを確認するには、そのユーザーのメールアドレスを使用して取得を試みてください。エンドポイントからエラーが返された場合、ユーザーの削除リクエストは成功しています。

​
ユーザーを削除済みとしてマークする

ユーザーを削除したくない場合は、app_metadata エンドポイント を使用して、そのプロフィールを削除済みとしてマークします。次に、そのようにマークされたプロフィールを持つユーザーの認証が失敗するように、コードを追加します。 これにより、今後のために削除済みユーザーの記録を保持できます。

​
プロファイルにフラグを付ける

ユーザーを削除済みとしてフラグ付けするには、app_metadata を使用します。次の例では、app_metadata フィールドに deleted というプロパティを追加する方法を示します。これにより、このプロパティが true に設定されているすべてのユーザーを、認証プロセスで削除済みとして扱うように設定できます。 ユーザーのメタデータを更新するには、Update a User エンドポイントを使用します。

​
削除フラグが付いたユーザーのログインを無効にする

次に、削除済みとしてフラグが付けられたユーザーのログインを無効にする必要があります。そのために、ルール (認証パイプラインの一部として実行される JavaScript スニペット) を追加します。
  1. Auth0 Dashboard > Auth Pipeline > Rules に移動し、ルールを作成します。
  2. 以下のスクリプトをコピーします。 
    function (user, context, callback) {
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.deleted){
  	return callback(new UnauthorizedError('Access denied (deleted user)'));
  }
  callback(null, user, context);
}
    このスクリプトは次の処理を行います。
    1. deleted メタデータプロパティ (user.app_metadata.deleted) の値を確認します。
    2. user.app_metadata.deleted = true の場合、アプリに Access denied (deleted user) エラーを返します
  3. ルールに名前を付け、変更を保存します。
また、次のことも必要です。
  • 同意撤回の仕組みが十分にきめ細かいことを確認します。
  • 顧客が同意を撤回する箇所をアプリ内に設定します。

​
詳しく見る