Auth0.js v9 リファレンス

auth0.js v9 のインストール、初期化、使用方法

Auth0.js は、Auth0 用のクライアントサイド JavaScript ライブラリです。ホスト型ログインと埋め込みログイン の両方のユースケースをサポートしています。

このライブラリの完全な API ドキュメントはこちらです。

Web アプリケーションで埋め込みログインを使用する場合、テナントにカスタムドメインを設定していない限り、クロスオリジン認証が使用されます。クロスオリジン認証では、異なるオリジン間で安全な認証トランザクションを可能にするために、サードパーティ Cookie を使用します。

すぐに使えるサンプル

auth0.js ライブラリの example ディレクトリ には、auth0.js をすばやく簡単に試せる、すぐに使えるアプリが含まれています。実行するには、次の手順に従ってください。

1. node がインストールされていない場合は、先にインストールします
2. このプロジェクトのルートで npm install を実行して依存関係をダウンロードします
3. 最後に、このプロジェクトのルートで npm start を実行し、node サーバー上で動作しているアプリ (通常は http://localhost:3000/example) にブラウザでアクセスします。

セットアップと初期化

それでは、auth0.js をプロジェクトに組み込んでいきましょう。インストール方法、auth0.js の初期化、サインアップ、ログイン、ログアウト などについて説明します。

埋め込みログイン用に Auth0 アプリケーションを設定する

埋め込みログインを実装する際、このライブラリは認証を実行するため、非表示の iframe 内でクロスオリジン呼び出しを使用します。これを安全に行うには、アプリケーションをホストするドメインを Auth0 が認識している必要があります。

そのドメインを Allowed Web Origins フィールドに追加します。このフィールドは、Dashboard の Application Settings にあります。

インストール方法

プロジェクトで auth0.js を使用するには、いくつかの方法があります。要件に応じて、以下のいずれかを選択してください。

npm または yarn でインストールします。

npm install auth0-js

yarn add auth0-js

auth0-js モジュールをインストールしたら、関連するすべての依存関係とあわせてバンドルするか、次のようにインポートする必要があります。

import auth0 from 'auth0-js';

または、当社のCDN経由でスクリプトを読み込みます。

<script src="https://cdn.auth0.com/js/auth0/9.18/auth0.min.js"></script>

初期化

次のように、Auth0 アプリケーションの新しいインスタンスを初期化します。

利用可能なパラメーター

webAuth をインスタンス化する際、options オブジェクトには必須パラメーターを 2 つ渡す必要があります。そのほかに任意のパラメーターもあります。

パラメーター	必須	説明
domain	必須	(String) Auth0 アカウントのドメイン (例: myaccount.auth0.com)
clientID	必須	(String) Auth0 のクライアントID
redirectUri	任意*	(String) デフォルトで使用される redirectUri。デフォルトは空文字列 (未設定) です。ここでグローバルな redirectUri 値を指定しない場合は、使用する各メソッドごとに redirectUri 値を指定する必要があります。
scope	任意	(String) アプリケーションで使用するデフォルトの スコープ。スコープを使用すると、リクエスト内の特定のフィールドに対して特定のクレームを返すことができます。詳しくは、スコープに関するドキュメントを参照してください。
audience	任意	(String) API アクセスをリクエストする際に使用するデフォルトのオーディエンス。
responseType	任意*	(String) デフォルトで使用される responseType。code、token、id_token の値をスペース区切りで任意に組み合わせたリストを指定できます。デフォルトは 'token' ですが、redirectUri が指定されている場合は 'code' になります。グローバルな responseType 値を指定しない場合は、使用する各メソッドごとに responseType 値を指定する必要があります。
responseMode	任意	(String) このオプションはデフォルトでは省略されます。'form_post' に設定すると、トークンまたは code を POST で 'redirectUri' に送信できます。サポートされる値は query、fragment、form_post です。
leeway	任意	(Integer) 秒単位の値。IDトークンの有効期限に関するクロックスキューを許容するための猶予です。
_disableDeprecationWarnings	任意	(Boolean) 非推奨の警告を無効にします。デフォルトは false です。

クロックスキューの問題により、まれに The token was issued in the future というエラーが発生することがあります。これを防ぐには、leeway パラメーターを使用して IDトークンの有効期限に数秒の猶予を持たせることができます。

スコープ

auth0.js v9 のデフォルトの scope 値は openid profile email です。

Auth0.js をローカルで実行する

auth0.js の初期化時に少なくとも上記のスコープを指定せず、ウェブサイトを http://localhost または http://127.0.0.1 で実行している場合、getSSOData() メソッドを呼び出すと、ブラウザーのコンソールに次のエラーが表示されます。

Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email

本番環境でアプリケーションを実行している場合、または openid profile email スコープを指定している場合、これは発生しません。詳細については、ユーザーの同意とサードパーティアプリケーション を参照してください。

Login

アプリケーションで必要な認証の種類に応じて、ログイン方法を選択できます。

webAuth.authorize()

authorize() メソッドは、以下の例のように、Universal Login またはソーシャル接続を通じてユーザーをログインさせる際に使用できます。このメソッドは Authentication API の /authorize エンドポイントを呼び出し、options オブジェクトを通じてさまざまなパラメーターを受け取れます。

パラメーター	必須	説明
audience	任意	(String) API へのアクセスをリクエストする際に使用するデフォルトのオーディエンス。
connection	任意	(String) アプリケーションで利用可能なすべての接続を表示する代わりに、使用する接続を指定します。
scope	任意	(String) 認可をリクエストするスコープです。スペース区切りで指定する必要があります。profile や email など、ユーザーに関する標準の OIDC スコープ、名前空間付き形式に準拠する必要があるカスタムクレーム、または対象 API がサポートする任意のスコープ (たとえば read:contacts) をリクエストできます。リフレッシュトークン を取得するには、offline_access を含めます。
responseType	任意	(String) code、token、id_token の値をスペース区切りで組み合わせた任意のリストを指定できます。デフォルトは 'token' ですが、redirectUri が指定されている場合は 'code' になります。
clientID	任意	(String) Auth0 のクライアントID。
redirectUri	任意	(String) ユーザーへの認可が付与された後に、Auth0 がブラウザーをリダイレクトする URL。
state	任意	(String) リダイレクトをまたいで維持される任意の値です。CSRF 攻撃の軽減や、認証処理の完了後に必要になるコンテキスト情報 (たとえばリターン URL) の保持に役立ちます。詳細は State Parameter を参照してください。シングルページアプリケーションで使用する auth0.js は、state が指定されていない場合、その生成と検証を自動的に処理します。
prompt	任意	(String) login を指定すると、現在のセッションに関係なくログインページが必ず表示されます。none を指定すると、すでにセッションが存在する場合はログインプロンプトをスキップしようとします (詳細は silent authentication のドキュメントを参照してください) 。

ホスト型ログインでは、/authorize() メソッドを呼び出す必要があります。

webAuth.authorize({//ここに追加のオプションを指定できます});

ソーシャルログインでは、connection パラメーターを指定する必要があります。

webAuth.authorize({connection: 'twitter'});

webAuth.popup.authorize()

ポップアップ認証では、popup.authorize メソッドを使用できます。ポップアップ認証は、ホスト型ログインページ内では使用できません。通常、ポップアップ認証は、ページ全体のリダイレクトによって現在の状態が失われるのを避けるために、シングルページアプリで使用されます。

ポップアップを使用したデフォルトの認可 (Universal Login) :

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://{yourApp}/popup_response_handler.html'
  //追加オプションはここに記述できます
}, function(err, authResult) {
  //処理を記述する
});

また、authorize を使用してポップアップでソーシャルログインする場合:

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://{yourApp}/popup_response_handler.html',
  connection: 'twitter'
}, function(err, authResult) {
  //何らかの処理を行う
});

ポップアップ認証の結果の処理

ポップアップ認証を使用する場合は、遷移先のページで webAuth.popup.callback メソッドを使って認可結果をコールバックに返せるよう、redirectUri を指定する必要があります。シンプルな実装例は次のとおりです。

<!-- popup_response_handler.html -->
<html>
  <body>
    <script src="https://cdn.auth0.com/js/auth0/9.18/auth0.min.js"></script>
    <script type="text/javascript">
      var webAuth = new auth0.WebAuth({
        domain:       '{yourDomain}',
        clientID:     '{yourClientId}'
      });
      webAuth.popup.callback();
    </script>
  </body>
</html>

理想的なハンドラーには、この最小限の機能だけを含めるようにしてください (つまり、レスポンスを処理するためだけにアプリケーション全体を再読み込みしないようにします) 。

redirectUri は、Dashboard のアプリケーション設定ページにあるアプリケーションの Allowed Callback URLs リストに追加する必要があります。

webAuth.login()

Web アプリケーションの埋め込みログインでは、テナントにカスタムドメインを設定していない限り、クロスオリジン認証を使用します。クロスオリジン認証では、異なるオリジン間で安全な認証トランザクションを実行できるように、サードパーティ Cookie を使用します。

login メソッドは、/co/authenticate を使用して、データベース接続向けのクロスオリジン認証による埋め込みログインに使用できます。

パラメーター	必須	説明
username	任意	(String) 認証時に使用する username。username または email のいずれかを指定する必要があります。
email	任意	(String) 認証時に使用するメールアドレス。username または email のいずれかを指定する必要があります。
password	必須	(String) 認証時に使用するパスワード。
realm	必須	(String) 認証を行う対象のデータベース接続の名前。

webAuth.login({
  realm: 'tests',
  username: 'testuser',
  password: 'testpass',
});

webAuth.crossOriginVerification()

crossOriginVerification() メソッドは、ブラウザーでサードパーティ Cookie が無効になっているユーザーにクロスオリジン認証を提供する際に役立ちます。使用方法の詳細については、クロスオリジン認証 のドキュメントを参照してください。

buildAuthorizeUrl(options)

buildAuthorizeUrl メソッドは、新しいトランザクションを初期化するための /authorize URL を構築する際に使用できます。ブラウザベースの (パッシブな) 認証を実装する場合は、このメソッドを使用してください。

state パラメーターは、Auth0 から返される不透明な値です。これは CSRF 攻撃の防止に役立つ方法であり、webAuth.authorize() を呼び出さずに自分で URL にリダイレクトする場合は、このパラメーターを指定する必要があります。詳細については、State Parameter を参照してください。

埋め込み認証でのシングルサインオン

埋め込みログインを使用するアプリでシングルサインオン (SSO) を実現するには、次の2つの条件を満たす必要があります。

1. SSOを行おうとする両方のアプリケーションが、いずれもファーストパーティアプリケーションである必要があります。サードパーティアプリケーションとのSSOは機能しません。
2. カスタムドメインを使用し、SSOを行う両方のアプリケーションとAuth0テナントが同一ドメイン上にある必要があります。従来、Auth0のドメインは foo.auth0.com の形式ですが、カスタムドメインを使用すると、対象の各アプリケーションとAuth0テナントで同じドメインを使用できるため、CSRF攻撃のリスクを抑えられます。

埋め込みログインのシナリオでSSOを設定する代わりに、Universal Loginを使用することを推奨します。Universal LoginはSSOを実現する最も信頼性が高く安定した方法であり、アプリケーションで複数のドメインを使用する必要がある場合、またはサードパーティアプリケーションを使用する場合に、これを実現できる唯一の方法です。

パスワードレスログイン

パスワードレス認証では、ユーザーはメールアドレスまたはテキストメッセージでワンタイムパスワードを受け取ってログインできます。このプロセスでは、まずパスワードレス認証を開始し、ユーザーに code (またはリンクに含まれる code) を生成して送信したうえで、検証方法を通じて認証情報を受け付ける必要があります。これは、ユーザーの (メールアドレスまたは電話番号) と、送信した code の入力を求めるログイン画面として実装できます。また、ユーザーに code を送信する代わりに、パスワードレスリンクとして実装することもできます。その場合、ユーザーはメールアドレスまたはテキストメッセージ内のリンクをクリックするだけで、そのリンクがエンドポイントに送信され、同じ検証方法を使ってこのデータが自動的に検証されます (ユーザーが code を手動で入力しない点だけが異なります) 。

Passwordless を使用するには、redirectUri を指定して auth0.js を初期化し、responseType: 'token' を設定する必要があります。

パスワードレス認証を開始する

auth0.js でパスワードレス認証を開始する最初のステップは、passwordlessStart メソッドです。このメソッドでは、options オブジェクト内で複数のパラメーターを渡せます。

Parameter	Required	Description
connection	required	(String) ユーザーに code または link を送信する方法を指定します。値は email または sms のいずれかである必要があります。
send	required	(String) 値は code または link のいずれかである必要があります。null の場合は、link が送信されます。
phoneNumber	optional	(String) SMS で code または link を送信するためのユーザーの電話番号です。
email	optional	(String) メールで code または link を送信するためのユーザーのメールアドレスです。

パスワードレストランザクションを開始するには、オプションの phoneNumber パラメーターと email パラメーターのうち、必ずどちらか一方だけを送信する必要があることに注意してください。

webAuth.passwordlessStart({
    connection: 'email',
    send: 'code',
    email: '[e-mail]'
  }, function (err,res) {
    // エラーを処理するか、続行する
  }
);

パスワードレス認証を完了する

code を送信する場合は、次にユーザーにその code の入力を求める必要があります。code の処理とユーザーの認証は passwordlessLogin メソッドで行います。このメソッドには、options オブジェクトで渡せる複数のパラメーターがあります。

Parameter	Required	Description
connection	required	(String) ユーザーに code またはリンクを送信する方法を指定します。値は email または sms のいずれかで、passwordlessStart に渡した値と同じである必要があります。
verificationCode	required	(String) ユーザーに送信された code です。code として送信される場合と、リンクに埋め込まれて送信される場合があります。
phoneNumber	optional	(String) code またはリンクの送信先となった、ユーザーの電話番号です (SMS) 。
email	optional	(String) code またはリンクの送信先となった、ユーザーのメールアドレスです (メール) 。

passwordlessStart と同様に、パスワードレスのトランザクションを検証するには、省略可能な phoneNumber と email のうち、どちらか一方のみを指定する必要があります。

passwordlessLogin を使用するには、WebAuth の初期化時に redirectUri オプションと responseType オプションを指定する必要があります。

webAuth.passwordlessLogin({
    connection: 'email',
    email: '[e-mail]',
    verificationCode: '389945'
  }, function (err,res) {
    // エラーを処理するか続行する
  }
);

authResult を取り出してユーザー情報を取得する

認証後は、parseHash メソッドを使用して、ユーザーがアプリケーションにリダイレクトされたときの URL ハッシュフラグメントを解析し、Auth0 の認証レスポンス結果を取り出せます。状況に応じて、これをコールバックページで処理してからメインアプリケーションにリダイレクトすることも、そのページ内で処理することもできます。

parseHash メソッドは、次のパラメーターを含む options オブジェクトを受け取ります。

パラメーター	必須	説明
state	optional	(String) アプリケーションが最初のリクエストに追加し、アプリケーションへのリダイレクト時に Auth0 が含める不透明な値です。この値は、CSRF 攻撃を防ぐために auth0.js で使用されます。
nonce	optional	(String) IDトークンの検証に使用されます
hash	optional	(String) URL ハッシュ (指定しない場合は、デフォルトで window.location.hash が使用されます)

parseHash が返す authResult オブジェクトの内容は、使用した認証パラメーターによって異なります。次の項目が含まれる場合があります。

項目	説明
accessToken	audience で指定した API の アクセストークン
expiresIn	accessToken の有効期限 (秒) を含む文字列
idToken	ユーザープロファイル情報を含む IDトークン JWT

webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) {
  if (err) {
    return console.log(err);
  }

  webAuth.client.userInfo(authResult.accessToken, function(err, user) {
    // ユーザーの情報を取得できました
  });
});

上記のように、返された accessToken を渡して client.userInfo メソッドを呼び出すことができます。これにより /userinfo エンドポイントへのリクエストが実行され、以下の例と同様の形式でユーザー情報を含む user オブジェクトが返されます。

{
    "sub": "auth0|123456789012345678901234",
    "nickname": "johnfoo",
    "name": "[e-mail]",
    "picture": "https://gravatar.com/avatar/example.png",
    "updated_at": "2018-05-07T14:16:52.013Z",
    "email": "[e-mail]",
    "email_verified": "false"
}

これで、アプリケーションの要件に応じて、この情報を使って別の処理を行えるようになります。たとえば、以下で説明するように、Management API を使用して、ユーザーのユーザープロファイル情報一式を取得できます。

nonce の使用

デフォルトでは (responseType に id_token が含まれている場合) 、auth0.js は webAuth.authorize の呼び出し時にランダムな nonce を生成し、ローカルストレージに保存したうえで、webAuth.parseHash でそれを取り出します。通常はこのデフォルトの動作で問題ありませんが、ユースケースによっては開発者が nonce を制御する必要がある場合もあります。 開発者が生成した nonce を使用する場合は、webAuth.authorize と webAuth.parseHash の両方にオプションとして指定する必要があります。 webAuth.authorize({<Tooltip tip="Nonce: リプレイ攻撃を検出して防止するため、認証プロトコルで一度だけ発行される任意の数値。" cta="用語集を表示" href="/docs/glossary?term=nonce">nonce</Tooltip>: '1234', responseType: 'token id_token'}); webAuth.parseHash({nonce: '1234'}, callback);

webAuth.authorize の代わりに webAuth.checkSession を呼び出す場合は、カスタム nonce を checkSession のオプションとして指定するだけで済みます。

webAuth.checkSession({
  nonce: '1234',
}, function (err, authResult) {
    ...
});

webAuth.checkSession メソッドは、返された IDトークン の nonce クレームが、オプションで指定した値と同じであることを自動的に検証します。

エラーコードと説明

埋め込みログインで Auth0.js を使用する場合、/co/authenticate エンドポイントが使われ、次のエラーが発生することがあります。

エラーの説明は、人間が読んで理解できることを目的としています。説明はコードで解析しないでください。また、内容は予告なく変更される場合があります。

Status	Code	Description
400	invalid_request	無効なリクエスト本文です。必要なパラメーターは client_id、credential_type、username、otp、realm のみです。
401	unauthorized_client	クロスオリジンログインは許可されていません。
400	unsupported_credential_type	不明な credential_type パラメーターです。
400	invalid_request	不明な realm non-existent-connection です。
403	access_denied	メールアドレスまたはパスワードが正しくありません。
403	access_denied	認証エラー
403	blocked_user	ブロックされたユーザー
401	password_leaked	現在使用しているパスワードが、過去に発生したデータ侵害 (このアプリケーション外) で漏えいしていたため、このログイン試行はブロックされました。
429	too_many_attempts	ログイン試行が連続して複数回行われたため、アカウントがブロックされました。ブロックの解除方法については、ご希望の連絡方法で通知を送信しました。
429	too_many_attempts	不審なログイン動作が検出されたため、以後の試行はブロックされます。管理者に連絡してください。

また、error または error_description プロパティを含まない、汎用的な 403 エラーが返される場合もあります。レスポンス本文には、次のような内容だけが含まれます。 Origin https://test.app is not allowed.

ログアウト

ユーザーをログアウトするには、logout() メソッドを使用します。このメソッドは options オブジェクトを受け取り、次のパラメーターを含めることができます。

clientID パラメーターが含まれている場合、指定する returnTo URL は、Auth0 Dashboard のアプリケーションにある Allowed Logout URLs に登録されている必要があります。一方、clientID パラメーターが含まれていない場合、returnTo URL は Auth0 Dashboard のアカウントレベルにある Allowed Logout URLs に登録されている必要があります。

webAuth.logout({
  returnTo: 'some url here',
  clientID: 'some client ID here'
});

サインアップ

ユーザーをサインアップするには、signup メソッドを使用します。このメソッドは options オブジェクトを受け取り、次のパラメーターを含めることができます。

パラメーター	必須	説明
email	required	(String) ユーザーのメールアドレス
password	required	(String) ユーザーが設定するパスワード
username	required*	(String) ユーザーが設定する username。*データベース接続を使用し、Requires Username を有効にしている場合は必須です
connection	required	(String) ユーザーアカウントの作成先となる、アプリケーション上のデータベース接続名
user_metadata	optional	(JSON object) ユーザー情報に使用する追加属性です。user_metadata に保存されます

サインアップはデータベース接続に対して行う必要があります。以下に、signup メソッドの例と、フォーム用のサンプルコードを示します。

<h2>Signup Database Connection</h2>
<input class="signup-email" />
<input type="password" class="signup-password" />
<input type="button" class="signup-db" value="Signup!" />
<script type="text/javascript">
    $('.signup-db').click(function (e) {
        e.preventDefault();
        webAuth.signup({
            connection: 'Username-Password-Authentication',
            email: $('.signup-email').val(),
            password: $('.signup-password').val(),
            user_metadata: { plan: 'silver', team_id: 'a111' }
        }, function (err) {
            if (err) return alert('Something went wrong: ' + err.message);
            return alert('success signup without login!')
        });
    });
</script>

checkSession を使用して新しいトークンを取得する

checkSession メソッドを使用すると、あなたのドメインに対してすでに Auth0 で認証されているユーザー向けに、Auth0 から新しいトークンを取得できます。このメソッドには、通常 authorize に送信する有効な OAuth2 パラメーターを任意に指定できます。省略した場合は、Auth0 の初期化時に指定したパラメーターが使用されます。

checkSession の呼び出しは、webAuth の初期化時に オーディエンス として指定した API の新しいトークンを取得するために使用できます。

webAuth.checkSession({}, function (err, authResult) {
  // 自動parseHashが失敗した場合のエラー
  ...
});

authResult の形式については、AuthResult を抽出してユーザー情報を取得する を参照してください。

また、audience と scope を指定すれば、webAuth の初期化時に使用した API とは別の API 向けのトークンを取得できます。

webAuth.checkSession(
  {
    audience: `https://mydomain/another-api/˜`,
    scope: 'read:messages'
  }, function (err, authResult) {
  // parseHash の自動実行に失敗した場合のエラー
  ...
});

checkSession() を呼び出すと、設定済みの Rules がすべてトリガーされます。そのため、使用する前に Dashboard で Rules を確認してください。

実際の /authorize へのリダイレクトは iframe 内で行われるため、アプリケーションが再読み込みされたり、アプリケーション外にリダイレクトされたりすることはありません。

ただし、ブラウザーでサードパーティ Cookie が必ず有効になっている必要があります。そうでない場合、checkSession() は現在のユーザーのセッションにアクセスできません (つまり、ユーザーに何も表示せずに新しいトークンを取得することはできません) 。ユーザーが Safari の ITP を有効にしている 場合も同様です。

認可リクエストの送信元 URL を、Dashboard で対象アプリケーションの Settings にある Auth0 アプリケーションの Allowed Web Origins リストに追加してください。

接続がソーシャル接続で、Auth0 dev keys を使用している場合、checkSession の呼び出しは常に login_required を返します。

checkSession() によるポーリング

一部のマルチアプリケーション環境では、シングルログアウトが必要になる場合があります (あるアプリケーションでユーザーがログアウトした際に、他のアプリケーションでもログアウトさせる必要がある場合) 。このような場合は、アプリケーションを設定して checkSession() を使って定期的に Auth0 をポーリングし、セッションが存在するかどうかを確認できます。セッションが存在しない場合は、そのユーザーをアプリケーションからログアウトできます。同じポーリング方法を使用して、シングルサインオン (SSO) シナリオ向けのサイレント認証を実装することもできます。

checkSession() の確認間隔は、今後この呼び出しでレート制限に関する問題が発生しないよう、少なくとも 15 分空けてください。

パスワードリセットのリクエスト

パスワードリセット機能を実装するには、changePassword メソッドを使用し、connection パラメーターと email パラメーターを含む options オブジェクトを渡します。

$('.change_password').click(function () {
    webAuth.changePassword({
      connection: 'db-conn',
      email:   '[e-mail]'
    }, function (err, resp) {
      if(err){
        console.log(err.message);
      }else{
        console.log(resp);
      }
    });
  });

その後、ユーザーには、パスワードをリセットするためのリンクが記載されたメールアドレスが送信されます。

ユーザー管理

Management API には、異なるプロバイダーにまたがる別々のユーザーアカウントのリンクとリンク解除、およびユーザーメタデータの更新を行う機能があります。詳細については、User Account Linkingを参照してください。

開始するには、まず Management API の呼び出しに使用できる アクセストークン を取得する必要があります。これは、auth0.js の初期化時に https://{yourDomain}/api/v2/ を audience として指定することで行えます。この場合、認証フローの一部としてアクセストークンを取得できます。

カスタムドメイン を使用している場合、Management API の呼び出しは Auth0 のドメインでのみ動作するため、カスタムドメインではなく Auth0 ドメインを使用して webAuth の新しいインスタンスを作成する必要があります。

checkSession() を使用して実行することもできます。

必要なスコープを明示的に指定する必要があります。要求できるスコープは次のとおりです。

• read:current_user
• update:current_user_identities
• create:current_user_metadata
• update:current_user_metadata
• delete:current_user_metadata
• create:current_user_device_credentials
• delete:current_user_device_credentials

アクセストークンを取得したら、アカウントの Auth0 ドメインとアクセストークンを渡して、新しい auth0.Management インスタンスを作成できます。

ユーザープロファイルの取得

ユーザープロファイルデータを取得するには、userId とコールバックをパラメーターに指定して getUser() メソッドを使用します。このメソッドはユーザープロファイルを返します。ここで必要な userID は、client.userInfo メソッドで取得したものと同じです。 auth0Manage.getUser(userId, cb);

ユーザープロファイルの更新

ユーザーメタデータを更新するには、まず userMetadata オブジェクトを作成し、次に patchUserMetadata メソッドを呼び出して、ユーザー id と作成した userMetadata オブジェクトを渡します。このオブジェクト内の値は、同じキーを持つ既存の値を上書きし、ユーザーメタデータにまだ存在しないキーについては新たに追加されます。詳細については、Metadata を参照してください。 auth0Manage.patchUserMetadata(userId, userMetadata, cb);

ユーザーのリンク

ユーザーアカウントをリンクすると、ユーザーはどのアカウントからでも認証でき、どのアカウントを使ってもログイン時に同じユーザープロファイルを表示できるようになります。Auth0 では、これらのアカウントはデフォルトですべて別々のユーザープロファイルとして扱われるため、ユーザーのアカウントをリンクする場合はこの方法を使用します。

linkUser メソッドは 2 つのパラメーター、プライマリの userId とセカンダリユーザーの IDトークン (この ID でログインした後に取得されるトークン) を受け取ります。ここでいう user ID は、プライマリユーザーアカウントの一意の識別子です。このメソッドを使用する場合、ID は auth0|1234567890 または facebook|1234567890 のように、プロバイダーのプレフィックス付きで渡す必要があります。詳細については、User Account Linking を参照してください。 auth0Manage.linkUser(userId, secondaryUserToken, cb);

アカウントをリンクすると、2 つ目のアカウントはユーザーデータベース内で別個のエントリとしては存在しなくなり、プライマリアカウントの一部としてのみアクセス可能になります。 アカウントがリンクされても、セカンダリアカウントのメタデータがプライマリアカウントのメタデータにマージされることはありません。また、後でリンクを解除した場合も、再び別個のアカウントとなったセカンダリアカウントにプライマリアカウントのメタデータが保持されることはありません。