GDPRの第7条によると、明確かつ利用しやすい方法で、ユーザーの個人データの処理についてユーザーに同意を求める必要があります。また、ユーザーが同意したことを示さなければならず、いつでも同意を取り消すことができる簡単な方法を提供しなければなりません。
この記事では、これらの要件を実装するためのAuth0の機能の使い方について説明します。
これらの文書の内容は、法的な助言を意図したものではなく、法的支援の代替と見なされるべきではありません。 GDPRを理解し順守することの最終責任はお客様にあり、Auth0は可能な限りにおいて、お客様がGDPR要件を満たすことを支援します。
サインアップ時に、ユーザーに同意を求める必要があります。Auth0を使用すれば、ユーザーのメタデータにこの情報を保存できます。ユーザーを認証するときのAuth0の使い方によって、利用できるオプションがいくつかあります。メタデータを使用してソリューションをデザインする前に、制限があることにご注意ください。Auth0は、user_metadataの合計サイズを16 MB に制限しています。詳細については、メタデータのフィールド名とデータタイプ をご覧ください。
Auth0のメタデータはセキュリティ保護されたデータストアではないため、機密情報の保管に使用されるべきではありません。これには社会保障番号やクレジットカード番号など、高リスクの個人情報が含まれます。Auth0の顧客はメタデータに保管されているデータを評価して、IDとアクセスの管理に必要なものだけを保管することを強くお勧めします。
Lock UIをカスタマイズして、条件および/またはプライバシーステートメントのページ、またユーザーがサインアップするためにチェックする必要がある同意チェックボックスへのリンクを表示できます。これは、mustAcceptTermsのLockオプションで設定できます。このプロパティは、trueに設定されたとき、サインアップ前にチェックを入れる必要があるチェックボックスを条件と一緒に表示します。条件は、languageDictionaryオプションを使用して、指定できます。詳細については、「Lock構成オプション 」をお読みください。
ユーザーが承認してサインアップすると、最初のログイン時に実行するルールを使用して、user_metadataに同意情報を保存します。ルールの詳細については、「Auth0ルール 」をお読みください。
データベース接続でユーザーを認証し、サインアップ中にユーザーからより多くの情報を取得したい場合は、Lock UIにカスタムフィールドを追加できます。これは、additionalSignUpFieldsのLockオプションで設定できます。カスタムフィールドは、自動的にuser_metadataに追加されます。
ソーシャルログインを使用している場合は、カスタムフィールドを追加できませんが、同意と追加情報を求める別のページにユーザーをリダイレクトし、その後認証処理を終わらせるために再びリダイレクトして戻すことができます。これは、リダイレクトルールを使用します。詳細については、ルール内でユーザーをリダイレクトする をお読みください。サインアップのプロセスが完了したら、Management API 更新ユーザー エンドポイントuser_metadataに同意の情報を保存します。
これらのシナリオの実装方法については、GDPR:Lockで同意を追跡する をご覧ください。
データベース接続でカスタムサインアップフォームを使用する場合、ユーザーの同意を取得するために、サインアップ画面にフィールドを追加する必要があります。その後、Auth0にユーザーを作成するために、認証API サインアップ エンドポイントuser_metadataの一部として同意情報を設定できます。
または、SPAのAuth0.jsを使用する場合は、signupメソッド を使用 してAuth0にユーザーを作成し、user_metadataの一部として同意情報を設定できます。
ソーシャルプロバイダーのカスタムサインアップフォームを使用する場合は、サインアップ時にユーザーの同意情報を設定できませんが、ユーザーが作成されたらすぐに更新できます。Management API更新ユーザー エンドポイントuser_metadataに同意の情報を保存します。
これらのシナリオの実装方法については、「GDPR:カスタムUIで同意を追跡する 」をご覧ください。
既存のユーザーに同意を求める必要があり、ユーザーを既存のデータベースからAuth0に移行することを決めた場合は、自動ユーザー移行 機能を使用できます。これを有効にすると、ユーザーが初めてログインするたびに（これが有効になっているため）、パスワードをリセットする必要なく、Auth0で作成されます。これを行うには、
ユーザーのデータの使用方法、データが使用される期間、ユーザーの権利など、ユーザーに表示される通知を詳述し、ＵＩサインアップボックスをカスタマイズする必要があります。
旧条件および以前のプライバシー認証に応じて、ユーザーに対して再同意が必要かどうかを判断します。
条件を変更するたびに、再度ユーザーに同意を求める必要があります ので、ご注意ください。
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を使用してユーザーを検索するには、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 Uwer（ユーザーの更新）**エンドポイント を使用します。
要求をどのように構成するかは、メタデータの構成の仕方（ルートプロパティか、内部プロパティか）によって異なります。
メタデータがルートプロパティとして保存されている場合：
{ "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つのプロパティしか更新しない場合も、メタデータオブジェクト全体を送信する必要があります。オブジェクト全体を含めなかった場合、Auth0は既存のプロパティを削除します。
同意日の内部プロパティを追加し、01/23/2018に設定しましょう。
これにより、ユーザープロファイルに新しいプロパティuser_metadata.consentDate が追加され、 顧客が同意した日を保持します。応答は完全なユーザープロファイルです。更新されたメタデータは以下のようになります。
{ "consent" : { "given" : true , "date" : "01/23/2018" , "text_details" : "some-url" } }
Management APIを使用してユーザーのリストをエクスポートするには、User Export（ユーザーエクスポート） エンドポイント を使用します。
このエンドポイントは、接続に関するすべてのユーザーをエクスポートするジョブを作成します。接続のIDが必要です。このIDを見つけるには、 Get Connections（接続する） エンドポイントname パラメーターにこれを取得するためだけに接続名を設定することができます）。
接続IDとManagement APIのアクセストークンを取得したら、ユーザーのエクスポートを開始できます。要求と応答の例を見るには、「ユーザーのインポートとエクスポート 」をご覧ください。Management APIのアクセストークンの取得方法については、「Management APIのアクセストークン 」をご覧ください。
また以下を行う必要があります。
同意の追跡方法を決めます。ユーザーの同意日のみだけでなく、ユーザーが同意した条件のバージョンに関する情報も含めることをお勧めします。また、許可を撤回したユーザーについての情報を保持する配列も含めることをお勧めします（ユーザーは複数回、同意と撤回ができることをお忘れなく）。
同意を保存したい場所を選択します：Auth0のデータベースまたは他のどこか。
アプリを使用して同意を撤回するオプションをユーザーに提供する必要があります。このオプションは、簡単にアクセスでき、はっきりと見分けがつくようにする必要があります。ユーザーが同意の撤回を決定したら、対応する必要があります。
最初に、同意の撤回にどのように対処するか決める必要があります。ユーザーを削除しますか？それとも削除済みとしてフラグを付けますか？
ユーザーを削除するには、**Delete a User（ユーザーの削除）**エンドポイント を使用します。
このエンドポイントの応答本文は空白のため、ユーザーが正常に削除されたことを確認したい場合は、メールアドレスを使用してユーザーの取得を試みます。エンドポイントがエラーを返したら、ユーザーの削除が成功したことを意味します。
ユーザーを削除したくない場合は、app_metadata エンドポイント
これにより、今後の使用のために、削除済みのユーザーの記録を保持できます。
削除済みとしてユーザーにフラグを付けるには、app_metadataを使用します。以下の例では、**［deleted（削除済み）］**と呼ばれるプロパティを、app_metadata フィールドに追加する方法を示しています。これにより、このプロパティがtrueに設定されたユーザー全員を削除済みとして取り扱うように認証プロセスを構成できます。
ユーザーのメタデータを更新するには、**Update a User（ユーザーの更新）**エンドポイント を使用します。
次に、削除済みとフラグ付けされたユーザーのログインを無効にする必要があります。これを行うには、ルールを追加します（認証パイプラインの一部として実行するJavaScriptスニペット）。
［Auth0 Dashboard］>［Auth Pipeline（Authパイプライン）］>［Rules（ルール）］ に移動して、ルールを作成します。
以下のスクリプトをコピーします。
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 ); }
スクリプトは以下を実行します。
**deleted（削除済み）**メタデータプロパティ（user.app_metadata.deleted）の値を確認します。
user.app_metadata.deleted = trueの場合、アプリにAccess denied (deleted user)エラーを返します。
ルールに名前を付けて、変更を保存します。
また以下を行う必要があります。
同意の撤回が十分に詳述されていることを確認する。
顧客が同意を撤回できるエリアをアプリに設定する。
