Auth0.js

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

auth0.js は、Auth0 向けのクライアントサイドのJavaScriptライブラリです。ホスト型ログインと埋め込みログインの両方のユースケースに対応しています。この記事では、現行バージョンである v10 を扱います。

auth0.js の完全な API ドキュメントを参照してください。

v9 から v10 への移行

Auth0.js v10 には、CVE-2026-42280 に対するセキュリティ修正と、1 つの互換性のない変更が含まれています。

Affected	Details
RS256 を使用しているアプリ	互換性のない変更はありません
HS256 を使用しているアプリ	parseHash() は、これまでのように暗黙的に成功するのではなく、invalid_token エラーを返すようになりました。Auth0 Dashboard で RS256 に切り替えてください: アプリケーション > ご利用のアプリ > 設定 > Advanced Settings > OAuth > JsonWebToken Signature Algorithm > RS256

v9 の API リファレンスが必要な場合は、npm の auth0-js パッケージで使用している v9 のバージョンを選択するか、GitHub 上の v9 のソースコードと変更履歴を参照してください。

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

すぐに使えるサンプル

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

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

設定と初期化

以下のセクションでは、インストール方法、Auth0.js の初期化、サインアップ、ログイン、ログアウト などについて説明します。

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

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

そのドメインを Allowed Web Origins フィールドに追加します。このフィールドは、Auth0 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/10.0.0/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) アプリケーションで使用されるデフォルトの scope(s)。scope を使用すると、request 内の特定のフィールドに対して特定のクレームを返せるようになります。詳細は scopes に関するドキュメント をご覧ください。
audience	任意	(String) API Access をリクエストする際に使用されるデフォルトの audience。
responseType	任意*	(String) デフォルトで使用される responseType。code、token、id_token をスペース区切りで任意に組み合わせて指定できます。デフォルトは 'token' ですが、redirectUri が指定されている場合は 'code' になります。グローバルな responseType 値を指定しない場合は、使用する各メソッドごとに responseType 値を指定する必要があります。
responseMode	任意	(String) このオプションはデフォルトでは省略されます。トークンまたは code を POST で 'redirectUri' に送信するには、'form_post' に設定できます。サポートされる値は query、fragment、form_post です。
leeway	任意	(Integer) 秒単位の値。ID トークンの有効期限に関するクロックスキューを許容するための猶予です。
_disableDeprecationWarnings	任意	(Boolean) 非推奨化の警告を無効にします。デフォルトは false です。

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

スコープ

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

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

Auth0.js の初期化時に少なくとも上記のスコープを指定せず、Web サイトを 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 スコープを指定している場合には発生しません。詳しくは、ユーザーの同意とサードパーティアプリケーション のドキュメントを参照してください。

ログイン

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

webAuth.authorize()

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

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

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

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

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

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

webAuth.popup.authorize()

ポップアップ認証では、popup.authorize メソッドを使用できます。ポップアップ認証は、ホスト型ログインページ内では使用できません。通常、ポップアップ認証はシングルページアプリケーションで使用されます。これは、ページ全体のリダイレクトを行わずに、現在のstateが失われるのを防ぐためです。

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

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

また、authorize を使用して popup でソーシャルログインする場合は、次のとおりです。

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/10.0.0/auth0.min.js"></script>
    <script type="text/javascript">
      var webAuth = new auth0.WebAuth({
        domain:       'YOUR_DOMAIN',
        clientID:     'YOUR_CLIENT_ID'
      });
      webAuth.popup.callback();
    </script>
  </body>
</html>

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

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

webAuth.login()

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

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

パラメータ	必須	説明
username	任意	(文字列) 認証時に使用するユーザー名です。username または email のいずれかが必要です。
email	任意	(文字列) 認証時に使用するメールアドレスです。username または email のいずれかが必要です。
password	必須	(文字列) 認証時に使用するパスワードです。
realm	必須	(文字列) 認証に使用するデータベース接続の名前です。

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

webAuth.crossOriginVerification()

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

buildAuthorizeUrl(options)

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

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

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

組み込みログインは、アプリケーションが次のアーキテクチャを共有している場合、シングルサインオン (SSO) をサポートします。

1. SSO を行うアプリケーションは、ファーストパーティアプリケーションである必要があります。サードパーティアプリケーションとの間で組み込みセッションを共有することはサポートされていません。
2. アプリケーションと Auth0 テナントは、カスタムドメイン を通じてトップレベルドメインを共有している必要があります。従来の Auth0 ドメインは foo.auth0.com 形式ですが、カスタムドメインを使用すると、アプリケーションと Auth0 テナントで同じトップレベルドメインを共有できるため、CSRF 攻撃の防止にも役立ちます。

アーキテクチャがこれらの条件を満たしている場合は、Auth0.js を使用した組み込み SSO が適しています。Universal Login は、複数のドメインにまたがる SSO や、サードパーティアプリケーションとの SSO を、セッションレイヤーを通じて自動的に処理します。また、この 2 つは同じアプリ内で共存させることもできます。たとえば、メインのサインインには Universal Login を使用し、認証要素の組み込み登録やステップアップフローには Auth0.js を使用するといった使い方が可能です。トレードオフを比較するには、ホスト型ログインと埋め込みログイン をご覧ください。

パスワードレスログイン

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

パスワードレス認証を使用するには、redirectUri を指定して Auth0.js を初期化し、responseType: 'token' を設定します。

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

Auth0.js でパスワードレス認証を始める最初のステップは、passwordlessStart メソッドです。このメソッドには、options オブジェクトを通じて渡せる複数のパラメータがあります。

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

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

webAuth.passwordlessStart({
    connection: 'email',
    send: 'code',
    email: '[e-mail]'
  }, function (err,res) {
    // エラーを処理するか、次のステップに進む
  }
);

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

コードを送信する場合は、続いてユーザーにそのコードの入力を求める必要があります。コードの処理とユーザーの認証には passwordlessLogin メソッドを使用します。このメソッドには、options オブジェクトで渡せるパラメータがいくつかあります。

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

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) アプリケーションが最初の request に追加し、Auth0 がアプリケーションへリダイレクトして戻すときに含める opaque な値です。この値は、Auth0.js が CSRF 攻撃を防ぐために使用します。
nonce	optional	(String) ID トークンの検証に使用します
hash	optional	(String) URL ハッシュ (指定しない場合は、デフォルトで window.location.hash が使用されます)

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

項目	説明
accessToken	audience で指定された API 用の Access Token
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) {
    // これでユーザーの情報が取得できました
  });
});

上記のとおり、client.userInfo メソッドは、返された accessToken を渡して呼び出せます。これにより /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 が含まれている場合) 、webAuth.authorize を呼び出すと Auth0.js がランダムな nonce を生成し、それをローカルストレージに保存したうえで、webAuth.parseHash で取り出します。通常はデフォルトの動作でほとんどのケースに対応できますが、ユースケースによっては、開発者が nonce を制御する必要があります。 開発者が生成した nonce を使用する場合は、webAuth.authorize と webAuth.parseHash の両方にオプションとして指定する必要があります。

webAuth.authorize({nonce: '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 エンドポイントが使われ、次のエラーが発生することがあります。

エラーの説明は、人が読んで理解できることを意図したものです。説明はコードで解析しないでください。また、内容は随時変更される可能性があります。

ステータス	コード	説明
400	invalid_request	無効なリクエストボディです。必須なのは client_id、credential_type、username、otp、realm のみです。
401	unauthorized_client	クロスオリジンログインは許可されていません。
400	unsupported_credential_type	不明な credential_type パラメータです。
400	invalid_request	不明なレルム 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	必須	(String) ユーザーのメールアドレス
password	必須	(String) ユーザーが設定するパスワード
username	必須*	(String) ユーザーが設定するユーザー名。 *データベース接続を使用し、Requires Username を有効にしている場合は必須です
connection	必須	(String) ユーザーアカウントの作成先となる、アプリケーション上のデータベース接続名
user_metadata	任意	(JSON object) ユーザー情報に使用する追加属性。user_metadata に保存されます

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

<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 に送信する有効な OAuth 2.0 パラメータを任意に指定できます。これらを省略した場合は、Auth0 の初期化時に指定したものが使用されます。

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

webAuth.checkSession({}, function (err, authResult) {
  // 自動parseHashが失敗した場合はerrに格納
  ...
});

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

また、audience と scope を指定すると、webAuth の初期化時に使用したものとは別の API 向けに token を取得することもできます：

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

checkSession() は、設定済みの ルール をすべてトリガーする点に注意してください。使用する前に、Auth0 Dashboard でルールの内容を確認しておくことをおすすめします。

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

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

認可リクエストの送信元となる URL を、Auth0 Dashboard のアプリケーションの 設定 にある、Auth0アプリケーションの Allowed Web Origins リストに追加することを忘れないでください。

接続がソーシャル接続で、Auth0 の開発用キーを使用している場合、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 では、異なるプロバイダーに属する別々のユーザーアカウントをリンクまたはリンク解除し、ユーザーのメタデータを更新できます。詳しくは、ユーザーアカウントのリンク を参照してください。

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

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

また、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 オブジェクトを渡す必要があります。このオブジェクト内の値は、同じ キー を持つ既存の値を上書きし、ユーザーのメタデータにまだ存在しないものは新たに追加されます。詳しくは、メタデータ を参照してください。 auth0Manage.patchUserMetadata(userId, userMetadata, cb);

ユーザーをリンク

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

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

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