GDPR: 同意の条件

GDPRの「同意の条件」要件への準拠に役立つAuth0の機能について説明します。

GDPR第7条に基づき、個人データの処理について、明確で容易にアクセスできる形でユーザーの同意を得る必要があります。また、ユーザーが同意したことを示せるようにし、いつでも簡単に同意を撤回できる手段を提供しなければなりません。

この記事では、これらの要件を満たすためにAuth0の機能をどのように活用できるかを説明します。

これらの文書の内容は法的助言を目的としたものではなく、法的支援に代わるものでもありません。GDPRを理解し、これを遵守する最終的な責任はお客様にありますが、Auth0は可能な限りGDPR要件への対応を支援します。

​

同意を求める

サインアップ時には、ユーザーに同意を求める必要があります。Auth0 では、この情報をユーザーのメタデータに保存できます。利用できる方法はいくつかあり、Auth0 を使ってユーザーをどのように認証するかによって異なります。メタデータを使ったソリューションを設計する前に、制限事項を把握しておいてください。Auth0 では、user_metadata の合計サイズは 16 MB に制限されています。詳しくは、Metadata Field Names and Data Types を参照してください。

Auth0 のメタデータは安全なデータ保存場所ではないため、高リスクのシークレットや、社会保障番号やクレジットカード番号のような個人を特定できる情報 (PII) などの機微な情報の保存には使用しないでください。Auth0 をご利用のお客様には、メタデータに保存するデータを十分に見直し、アイデンティティ/アクセス管理の目的で必要なものだけを保存することを強くお勧めします。

​

Lock を使用する

Lock UI は、利用規約やプライバシーに関する声明ページへのリンクと、ユーザーがサインアップする際にチェックする必要がある同意チェックボックスを表示するようにカスタマイズできます。これは mustAcceptTerms Lock オプションで実現できます。このプロパティを true に設定すると、サインアップ前にチェック必須のチェックボックスが利用規約とあわせて表示されます。利用規約は languageDictionary オプションを使って指定できます。詳しくは、Lock Configuration Options をお読みください。

ユーザーが同意してサインアップしたら、初回ログイン時に実行される ルール を使って、user_metadata に同意情報を保存します。ルールの詳細については、Auth0 Rules をお読みください。

サインアップ時にユーザーからさらに多くの情報を取得したい場合で、データベース接続を使用してユーザーを認証しているなら、Lock UI にカスタムフィールドを追加できます。これは additionalSignUpFields Lock オプションで実現できます。カスタムフィールドはすべて自動的に user_metadata に追加されます。

ソーシャルログインを使用している場合、カスタムフィールドを追加することはできませんが、ユーザーを別のページにリダイレクトして、そこで同意や追加情報を求めたあと、認証トランザクションを完了するために再度リダイレクトして戻すことができます。これはリダイレクト ルールで実現できます。詳しくは、Redirect Users from Within Rules をお読みください。サインアップ処理が完了したら、Management API の Update User エンドポイント を呼び出して、user_metadata に同意情報を保存します。

これらのシナリオの実装方法については、GDPR: Track Consent with Lock をお読みください。

​

カスタムUIを使用する

データベース接続を使用するカスタムのサインアップフォームでは、ユーザーの同意を取得するために、サインアップ画面に追加のフィールドを設ける必要があります。その後、Auth0 にユーザーを作成するために、Authentication API の Signup エンドポイント を呼び出します。この時点で、同意情報を user_metadata の一部として設定できます。

または、SPA から auth0.js を使用している場合は、signup メソッドを使用して、Auth0 にユーザーを作成し、同意情報を user_metadata の一部として設定できます。

ソーシャルプロバイダーを使用するカスタムのサインアップフォームでは、サインアップ時にユーザーの同意情報を設定することはできませんが、ユーザーが作成されしだい更新できます。Management API の Update User エンドポイント を呼び出して、同意情報を user_metadata に保存してください。

これらのシナリオの実装方法については、GDPR: カスタムUIで同意を追跡する を参照してください。

​

再同意とユーザー移行

既存のユーザーに同意を求める必要があり、既存のデータベースから Auth0 へユーザーを移行することにした場合は、Automatic User Migration 機能を利用できます。これを有効化すると、有効化後に各ユーザーが初めてログインした際、パスワードをリセットしなくても Auth0 にユーザーが作成されます。これを行うには、次の対応が必要です。

• ユーザーデータの利用方法、利用期間、ユーザーの権利などについて、ユーザーに表示する通知を作成するとともに、UI のサインアップボックスをカスタマイズします。
• 以前の利用規約やこれまでのプライバシー認証を踏まえて、ユーザーに再同意が必要かどうかを判断します。

利用規約が変更されるたびに、ユーザーには必ず再度同意を求める必要がある点に注意してください。

​

同意を追跡する

GDPR によれば、ユーザーが自身の個人データの処理に同意したことを示せる必要があります。

Auth0 では、ユーザーの同意情報を user_metadata の一部として保存できます。同意したかどうかを示す flag のみを保存することも、同意情報と設定一式 (たとえば、ユーザーが同意した日付や同意した条件などを含む) を保存することもできます。その後、この情報には Management API を使用してアクセスし、操作できます。

Management API には、ユーザー検索、ユーザーのメタデータを更新するためのエンドポイント、ユーザーを一括エクスポートするための機能に関しても、いくつかの選択肢があります。

Management API にアクセスするには、アクセストークンが必要です。Management API 用のアクセストークンを取得する方法については、Management API Access Tokens を参照してください。

​

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

メールアドレスでユーザーを検索するには、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を更新するには、ユーザーを更新 エンドポイントを使用します。

リクエストの構成方法は、メタデータをルートプロパティとして持たせているか、内部プロパティとして持たせているかによって異なります。

メタデータがルートプロパティとして保存されている場合:

{
  "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.consent.date という新しいプロパティが追加され、顧客が同意した日付がそこに格納されます。レスポンスにはユーザープロファイル全体が返されます。更新後のメタデータは次のようになります。

{
  "consent": {
    "given": true,
    "date": "01/23/2018",
    "text_details": "some-url"
  }
}

​

同意情報をエクスポートする

Management API を使用してユーザー一覧をエクスポートするには、User Export エンドポイントを使用します。

このエンドポイントでは、接続に関連付けられたすべてのユーザーをエクスポートする job が作成されます。接続の ID が必要です。この ID を確認するには、Get Connections エンドポイントを使用します (name パラメーターに接続名を設定すると、その接続のみを取得できます) 。

接続 ID と Management API 用のアクセストークンを取得したら、ユーザーのエクスポートを開始できます。リクエストとレスポンスの例については、Import and Export Usersを参照してください。Management API 用のアクセストークンの取得方法については、Management API Access Tokensを参照してください。

また、次のことも必要です。

• 同意をどのように追跡するかを決めます。ユーザーが同意した日付だけでなく、ユーザーが同意した利用規約のバージョン情報も含めることをお勧めします。また、許可を撤回したユーザーに関する情報を保持するための配列を用意することもお勧めします (ユーザーは同意と撤回を複数回行う可能性があることに注意してください) 。
• 同意をどこに保存するかを決めます。Auth0 のデータベースに保存するか、それ以外の場所に保存するかを選択してください。

​

同意の撤回

ユーザーがアプリ上で同意を撤回できるようにしておく必要があります。この選択肢は見つけやすく、他と明確に区別できるようにしてください。ユーザーが同意を撤回することを決めたら、必要な対応を行う必要があります。

まず、同意の撤回をどのように処理するかを決める必要があります。ユーザーを削除するのか、それとも削除済みとしてフラグを付けるのかを決めてください。

​

ユーザーを削除する

ユーザーを削除するには、Delete a User エンドポイントを使用します。

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

​

ユーザーに削除済みフラグを付ける

ユーザーを削除したくない場合は、app_metadata endpoint を使用して、そのプロファイルに削除済みフラグを設定します。次に、そのフラグが設定されたユーザーの認証が失敗するように、コードを追加します。

これにより、将来利用するために削除済みユーザーの記録を保持できます。

​

プロファイルにフラグを設定する

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

ユーザーのメタデータを更新するには、ユーザーを更新 エンドポイントを使用します。

​

フラグが付けられたユーザーのログインを無効にする

次に、削除済みとしてフラグが付けられたユーザーがログインできないようにする必要があります。そのために、ルール (authentication パイプラインの一部として実行される 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. ルールに名前を付けて、変更を保存します。

また、次のことも必要です。

• 同意撤回の仕組みが十分に細かく設定されていることを確認します。
• 顧客が同意を撤回できる箇所をアプリ内に設けます。

​

詳細はこちら

• GDPR: データ最小化
• GDPR: データポータビリティ
• GDPR: ユーザーデータを保護し、安全性を確保する
• GDPR: データへのアクセス、訂正、削除の権利