2Auth0.js v9の参考情報

Auth0.jsは、Auth0クライアント側ライブラリーです。ユニバーサルログインと一緒に使用することをお勧めします（ユニバーサルログインは、可能な限り使用してください）。SPAでauth0.jsを使用すると、Auth0での認証・認可が簡単になります。

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

そのまま使えるサンプル

auth0.jsライブラリーのサンプルディレクトリは、そのまま使えるアプリで、auth0.jsを手軽に試してみたいときに役立ちます。実行するには、以下の簡単な手順に従います。

  1. nodeがインストールされていない場合は、ここでインストールします。

  2. このプロジェクトのルートディレクトリでnpm installを実行して、依存関係をダウンロードします。

  3. 最後に、このプロジェクトのルートからnpm startを実行し、ノードサーバー（通常はhttp://localhost:3000/example）で実行中のアプリに移動します。

セットアップと初期化

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

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

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

［Allowed Web Origins（許可されているWebオリジン）］フィールドにドメインを追加します。このフィールドがDashboardの［Application Settings（アプリケーションの設定）］に表示されます。

インストールオプション

プロジェクトでauth0.jsを使用するには、いくつかのオプションがあります。ニーズに合わせて以下のいずれかを選択します。

npmまたはyarnを使用してインストールする：

npm install auth0-js

yarn add auth0-js

Was this helpful?

/

auth0-jsモジュールをインストールしたら、それをすべての依存関係と一緒にバンドルするか、以下を使用してインポートする必要があります。

import auth0 from 'auth0-js';

Was this helpful?

/

別の方法として、CDNを介してスクリプトをインクルードすることもできます。

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

Was this helpful?

/

初期化

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

<script type="text/javascript">
  var webAuth = new auth0.WebAuth({
    domain:       '{yourDomain}',
    clientID:     '{yourClientId}'
  });
</script>

Was this helpful?

/

使用可能なパラメーター

webAuthをインスタンス化する際に、optionsオブジェクトで渡さなければならない必須のパラメーターが2つあります。さらにオプションで渡せるパラメーターもあります。

パラメーター 必須 説明
domain 必須 （文字列）Auth0のアカウントのドメインです（例：myaccount.auth0.com）。
clientID 必須 （文字列）Auth0のクライアントIDです。
redirectUri 任意* （文字列）デフォルトで使用されるredirectUriです。デフォルトでは空文字列（none）です。ここでグローバルなredirectUriの値を設定しない場合には、使用するそれぞれのメソッドでredirectUriの値を設定する必要があります。
scope 任意 （文字列）アプリケーションが使用するデフォルトのスコープです。スコープを使用すると、要求にある特定のフィールドで特定のクレームを返すことができます。詳細については、[スコープについてのドキュメント]（/scopes）をお読みください。
audience 任意 （文字列）APIへのアクセス要求にデフォルトで使用されるオーディエンスです。
responseType 任意* （文字列）デフォルトで使用されるresponseTypeです。code、token、id_tokenの値をスペースで区切った任意のリストです。デフォルトは'token'です。ただし、redirectUriが提供された場合には、'code'がデフォルトになります。グローバルなresponseTypeの値を設定しない場合には、使用するそれぞれのメソッドでresponseTypeの値を設定する必要があります。
responseMode 任意 （文字列）このオプションはデフォルトで省略されます。'form_post'に設定して、トークンやコードを'redirectUri'にPOSTで送信することもできます。対応されている値はquery、fragment、form_postです。
leeway 任意 （整数）IDトークンの有効期限に関連して、クロックスキューを許容するため余裕秒数の値です。
_disableDeprecationWarnings 任意 （ブール値）廃止警告を無効にします。デフォルトはfalseです。
クロックスキューの問題により、時折「The token was issued in the future（トークンが未来に発行された）」というエラーが発生することがあります。leewayパラメーターを使用して、IDトークンの有効期限までに数秒の余裕を持たせ、これを防ぎます。

Scope（スコープ）

auth0.js v9でのデフォルトのスコープ値は、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（同意が必要です。getSSODataを使用する場合、ユーザーはopenid profile emailのスコープで認証される必要があります）

このエラーは、アプリケーションを運用環境で実行している場合や、スコープにopenid profile emailを指定した場合には発生しません。詳細については、「ユーザーの同意とサードパーティーアプリケーション」をお読みください。

ログイン

ログインのメソッドは、アプリケーションで必要なauthの種類に従って選ぶことができます。

webAuth.authorize()

authorize()メソッドは、ユニバーサルログイン経由でユーザーをログインさせる場合や、以下の例に示すようにソーシャル接続経由でログインさせる場合に使用できます。このメソッドは、Authentication APIの/authorizeエンドポイントを呼び出し、optionsオブジェクト経由でさまざまなパラメーターを取ることができます。

パラメーター 必須 説明
audience 任意 （文字列）APIへのアクセス要求にデフォルトで使用されるオーディエンスです。
connection 任意 （文字列）アプリケーションに使用可能なすべての接続を提示するのではなく、使用するべき接続を指定します。
scope 任意 （文字列）認可を要求したいスコープです。スペースで区切る必要があります。ユーザーについてのあらゆる標準OIDCスコープ()を要求することができます。たとえば、profileやemail、[名前空間形式に準拠したカスタムクレーム](/tokens/guides/create-namespaced-custom-claims)、呼び出すAPIが対応しているスコープ（read:contactsなど）を要求することができます。<dfn data-key="refresh-token">リフレッシュトークン</dfn>を取得するには、offline_access`を含めます。
responseType 任意 （文字列）code、token、id_tokenの値をスペースで区切った任意のリストです。デフォルトは'token'です。ただし、redirectUriが提供された場合には、'code'がデフォルトになります。
clientID 任意 （文字列） Auth0のクライアントIDです。
redirectUri 任意 （文字列）ユーザーが認可された後に、Auth0がブラウザーをリダイレクトするURLです。
state 任意 （文字列） リダイレクト間で維持される任意の値です。CSRF攻撃の軽減や、認証プロセスが完了した後で必要になるかもしれない任意のコンテキスト情報（リターンURL）に便利です。詳細については、「状態パラメーター」を参照してください。指定されない場合、シングルページアプリケーションに限り、auth0.jsがstateの生成と検証を自動的に行います。
prompt 任意 （文字列）値にloginを指定すると、現在のセッションにかかわらず、ログインページの表示を強制します。値にnoneを指定すると、セッションが既に存在する場合はログインをバイパスしようとします。(詳細については、「サイレント認証」の説明を参照してください)。

ホスト型のログインでは、/authorize()メソッドを呼び出す必要があります。 webAuth.authorize({ //Any additional options can go here });

ソーシャルログインの場合、connectionパラメーターを指定する必要があります。 webAuth.authorize({ connection:'twitter' });

webAuth.popup.authorize()

ポップアップ認証の場合は、popup.authorizeメソッドを使用できます。ホスト型のログインページでは、ポップアップ認証は使用できません。通常、ポップアップ認証は、ページ全体のリダイレクト時に現在のステータスが失われないようにするために、シングルページアプリで使用します。

ポップアップを使ったデフォルト認可（ユーザーにAuth0のユニバーサルログインが表示されます）：

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://{yourApp}/popup_response_handler.html'
  //Any additional options can go here
}, function(err, authResult) {
  //do something
});

Was this helpful?

/

ポップアップを使用したソーシャルログインの場合は、authorizeを使用します。 

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://{yourApp}/popup_response_handler.html',
  connection: 'twitter'
}, function(err, authResult) {
  //do something
});

Was this helpful?

/

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

ポップアップ認証を使用する場合、redirectUriを指定する必要があります。ここでは、宛先のページがwebAuth.popup.callbackメソッドを使用して認可の結果をコールバックに知らせます。簡単な実装は、以下のようになります：

<!-- 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:       'YOUR_AUTH0_DOMAIN',
        clientID:     'YOUR_CLIENT_ID'
      });
      webAuth.popup.callback();
    </script>
  </body>
</html>

Was this helpful?

/
このような最小限の機能性のみを備えた（この応答を処理するためだけにアプリケーション全体を再読み込みしない）ハンドラーが理想的です。Dashboardのアプリケーション構成ページで、redirectUriをアプリケーションの［Allowed Callback URLs（許可されているコールバックURL）］リストに追加する必要があります。

webAuth.login()

loginメソッドでは、/co/authenticateを使用して、データベース接続のクロスオリジン認証を行うことができます。

パラメーター 必須 説明
username 任意 （文字列）認証用に提示するユーザー名。次のどちらかが必要です：usernameまたはemail
email 任意 （文字列）認証用に提示するメールアドレス。次のどちらかが必要です：usernameまたはemail
password 必須 （文字列）認証用に提示するパスワード。
realm 必須 （文字列）認証の対象となるデータベース接続の名前。 
webAuth.login({
  realm: 'tests',
  username: 'testuser',
  password: 'testpass',
});

Was this helpful?

/

webAuth.crossOriginVerification()

crossOriginVerification()メソッドは、ブラウザーでサードパーティのクッキーが無効になっている顧客にクロスオリジン認証を提供するために使用できます。この用途の詳細については、クロスオリジン認証のドキュメントをお読みください。

buildAuthorizeUrl(options)

buildAuthorizeUrlメソッドを使用して/authorize URLを構築し、新しいトランザクションを初期化することができます。ブラウザーベースの（パッシブ）認証を実装したいときは、このメソッドを使用します。

codeblockOld.header.login.configureSnippet
// Calculate URL to redirect to
var url = webAuth.client.buildAuthorizeUrl({
  clientID: '{yourClientId}', // string
  responseType: 'token id_token', // code
  redirectUri: 'https://{yourApp}/callback',
  state: '{yourState}',
  nonce: '{yourNonce}'
});

// Redirect to url
// ...

Was this helpful?

/

stateパラメーターは、Auth0が返す不透明な値です。このメソッドは、CSRF攻撃を防ぐのに有効なため、webAuth.authorize()を呼び出す代わりに自分でURLにリダイレクトを行う場合には指定する必要があります。詳細については、「Stateパラメーター」を参照してください。

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

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

  1. SSOを行おうとするアプリケーションの両方が、ファーストパーティーのアプリケーションでなくてはなりません。サードパーティーのアプリケーションではSSOが動作しません。

  2. カスタムドメインを使用していること、SSOを実装しようとしているアプリケーションとAuth0テナントが同じドメインにあることが必要です。従来、Auth0ドメインの形式はfoo.auth0.comですが、カスタムドメインを使用すると、該当するすべてのアプリケーションとAuth0テナントに同じドメインを使用してCSRF攻撃のリスクを回避できます。

埋め込みログインの実装では、SSOをセットアップする代わりに、ユニバーサルログインの使用をお勧めします。ユニバーサル ログインは、SSOを実行するための最も信頼性が高く安定した方法であり、アプリケーションに複数のドメインを使用する必要がある場合や、サードパーティアプリケーションを使用する必要がある場合に実行できる唯一の方法です。

パスワードレスログイン

パスワードレス認証は、ユーザーがメールやテキストメッセージでワンタイムパスワードを受信することにより、ログインできるようにします。それには、パスワードレス処理を開始し、コード（またはリンク内のコード）を生成してユーザーに送信し、検証方法を介してユーザーの資格情報を承認する必要があります。このプロセスは、ログイン画面の形で実行し、ユーザーにメールアドレス（または電話番号）とそこに送信したばかりのコードの入力を求めます。コードではなく、パスワードレスのリンクを送信することもできます。ユーザーは、メールやテキストに含まれているリンクをクリックするだけでエンドポイントに到達し、このデータが同じ検証方法を使って自動的に検証されます（ユーザーが手動でコードを入力しない点のみが異なります）。

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

codeblockOld.header.login.configureSnippet
var webAuth = new auth0.WebAuth({
  clientID: '{yourClientId}',
  domain: '{yourDomain}',
  redirectUri: 'http://example.com',
  responseType: 'token id_token'
});

Was this helpful?

/

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

auth0.jsを使用したパスワードレス認証の最初のステップはpasswordlessStartメソッドです。このメソッドにはいくつかのパラメーターがあり、そのoptionsオブジェクト内で渡すことができます。

パラメーター 必須 説明
connection 必須 （文字列）コード/リンクをユーザーに送信する方法を指定します。値はemailまたはsmsで指定する必要があります。
send 必須 （文字列）値はcodeまたはlinkで指定する必要があります。nullの場合、リンクが送信されます。
phoneNumber 任意 （文字列）SMS経由でコードまたはリンクを送るのに使用するユーザーの電話番号。
email 任意 （文字列）メール経由でコードまたはリンクを送信するのに使用するユーザーのメール。
パスワードレスのトランザクションを開始するには、オプションのphoneNumberとemailパラメーターのうち、必ず1つを送信する必要があることにご注意ください。 
webAuth.passwordlessStart({
    connection: 'email',
    send: 'code',
    email: 'foo@bar.com'
  }, function (err,res) {
    // handle errors or continue
  }
);

Was this helpful?

/

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

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

パラメーター 必須 説明
connection 必須 （文字列）コード/リンクをユーザーに送信する方法を指定します。値はemailまたはsmsのいずれかで、passwordlessStartに渡される値と同じでなければなりません。
verificationCode 必須 （文字列）ユーザーに送信されるコード（コードまたはリンク内に埋め込まれる）。
phoneNumber 任意 （文字列）SMS経由でコードまたはリンクが送られたユーザーの電話番号。
email 任意 （文字列）メール経由でコードまたはリンクが送られたユーザーのメール。

passwordlessStartと同様に、パスワードレスのトランザクションを確認するためには、オプションのphoneNumberとemailパラメーターのうち、必ず1つを送信する必要があります。

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

webAuth.passwordlessLogin({
    connection: 'email',
    email: 'foo@bar.com',
    verificationCode: '389945'
  }, function (err,res) {
    // handle errors or continue
  }
);

Was this helpful?

/

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

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

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

パラメーター 必須 説明
state 任意 （文字列）アプリケーションにリダイレクトされるときにAuth0が含める最初の要求にアプリケーションが追加する不透明型の値。この値は、CSRF攻撃を防ぐために、auth0.jsで使用されます。
nonce 任意 （文字列）IDトークンの検証に使用される
hash 任意 （文字列）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) {
    // Now you have the user's information
  });
});

Was this helpful?

/
上に示すように、client.userInfoメソッドは、返されたaccessTokenを渡して呼び出すことができます。その場合、/userinfoエンドポイントに要求が送られ、以下の例と同様の形式で、ユーザー情報が入ったuserオブジェクトが返されます。
{
    "sub": "auth0|123456789012345678901234",
    "nickname": "johnfoo",
    "name": "johnfoo@gmail.com",
    "picture": "https://gravatar.com/avatar/example.png",
    "updated_at": "2018-05-07T14:16:52.013Z",
    "email": "johnfoo@gmail.com",
    "email_verified": "false"
}

Was this helpful?

/

この情報を使って、アプリケーションのニーズに合わせ、何らかの処理を行うことができます。1つの例として、Management APIを使ってユーザーの全プロファイル情報を取得する方法をご紹介します。

nonceの使用

デフォルトでは（およびresponseTypeにid_tokenが含まれている場合）、auth0.jsはwebAuth.authorizeを呼び出す時にランダムな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を呼び出す場合は、checkSessionのオプションとしてカスタムnonceのみを指定する必要があります。 

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

Was this helpful?

/

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 不明な資格情報タイプのパラメーター。
400 invalid_request 不明な領域の存在しない接続。
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.（オリジンのhttps://test.appは許可されていません）

ログアウト

ユーザーをログアウトさせるには、logout()メソッドを使用します。このメソッドは、次のようなパラメータを含むoptionsオブジェクトを受け取ります。

clientIDパラメーターが含まれている場合、提供されたreturnTo URLは、Auth0 Dashboardのアプリケーションの［Allowed Logout URLs（許可されているログアウトURL）］に記載されている必要があります。ただし、clientIDパラメーターが含まれていない場合は、returnToのアカウントレベルの［Allowed Logout URLs（許可されているログアウトURL）］に記載されている必要があります。

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

Was this helpful?

/

サインアップ

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

パラメーター 必須 説明
email 必須 （文字列）ユーザーのメールアドレス
password 必須 （文字列） ユーザーが希望するパスワード
username 必須* （文字列） ユーザーが希望するユーザー名
*データベース接続を使用し、**［Requires Username（ユーザー名を必要とする）］**が有効な場合は必須
connection 必須 （文字列）ユーザーアカウントを作成しようとするアプリケーション上のデータベース接続名
user_metadata 任意 （JSONオブジェクト）ユーザー情報に使用される追加の属性。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>

Was this helpful?

/

checkSessionを使った新しいトークンの取得

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

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

webAuth.checkSession({}, function (err, authResult) {
  // err if automatic parseHash fails
  ...
});

Was this helpful?

/

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

また、audienceとscopeを指定することによって、webAuthの初期化の際に使用されたAPIとは異なるAPIのトークンを取得することもできます。 

webAuth.checkSession(
  {
    audience: `https://mydomain/another-api/˜`,
    scope: 'read:messages'
  }, function (err, authResult) {
  // err if automatic parseHash fails
  ...
});

Was this helpful?

/

checkSession()では、設定したルールがすべてトリガーされるため、使用する前にDashboardでルールを確認してください。

/authorizeへの実際のリダイレクトはiframe内で起こるため、アプリケーションの再読み込みやアプリケーションからのリダイレクトは行われません。

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

Dashboardのアプリケーションの［Settings（設定）］の下にあるAuth0アプリケーションの［Allowed Web Origins（許可されたWebオリジン）］リストに、認可要求の送信元となるURLを追加することを忘れないでください。

checkSession()でのポーリング

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

ポーリング間隔として、checkSession()の呼び出し間隔を15分以上に設定し、レート制限の問題が生じないようにします。

パスワードのリセット要求

パスワードリセット機能を設定しようとする場合は、changePasswordメソッドを使用し、optionsオブジェクトを渡します。このオブジェクトには、connectionパラメーターとemailパラメーターを含めます。

$('.change_password').click(function () {
    webAuth.changePassword({
      connection: 'db-conn',
      email:   'foo@bar.com'
    }, function (err, resp) {
      if(err){
        console.log(err.message);
      }else{
        console.log(resp);
      }
    });
  });

Was this helpful?

/
すると、ユーザーに、パスワードリセット用のリンクを含んだメールが届きます。

ユーザー管理

Management APIの機能を使うと、異なるプロバイダーからの個別のユーザーアカウントをリンクしたり、リンクを解除したりして、1つのプロファイルにまとめることができます（詳細については「ユーザーアカウントのリンク」を参照してください）。また、ユーザーメタデータを更新することもできます。

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

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

var webAuth = new auth0.WebAuth({
  clientID: '{yourClientId}',
  domain: '{yourDomain}',
  redirectUri: 'http://example.com',
  audience: `https://{yourDomain}/api/v2/`,
  scope: 'read:current_user',
  responseType: 'token id_token'
});

Was this helpful?

/

また、checkSession()を使用してこれを行うこともできます。 

webAuth.checkSession(
  {
    audience: `https://{yourDomain}/api/v2/`,
    scope: 'read:current_user'
  }, function(err, result) {
     // use result.accessToken
  }
);

Was this helpful?

/

必要なスコープを指定しなければなりません。以下のスコープを要求することができます。

  • 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インスタンスを作成することができます。 

var auth0Manage = new auth0.Management({
  domain: '{yourDomain}',
  token: 'ACCESS_TOKEN'
});

Was this helpful?

/

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

ユーザープロファイルデータを取得するには、getUser()メソッドを使用します。このメソッドには、userIdとコールバックをパラメーターとして渡します。メソッドはユーザープロファイルを返します。ここで必要とされるuserIDは、client.userInfoメソッドから取得したものと同じであることにご注意ください。 auth0Manage.getUser(userId, cb);

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

ユーザーメタデータを更新する際は、まずuserMetadataオブジェクトを作成し、その後patchUserMetadataメソッドを呼び出して、作成したuserMetadataオブジェクトとユーザーIDを渡す必要があります。このオブジェクトの値は、同じキーを持つ既存の値を上書きするか、ユーザーメタデータに値がない場合は新しい値を追加します。ユーザーメタデータの詳細については、メタデータのドキュメントを参照してください。 auth0Manage.patchUserMetadata(userId, userMetadata, cb);

ユーザーのリンク

ユーザーアカウントをリンクすると、ユーザーがどのアカウントからでも認証できるようになり、どのアカウントを使用してログインしても同じプロファイルが引き出されます。Auth0では、デフォルトですべてのアカウントが個別のプロファイルとして扱われるため、ユーザーのアカウントをリンクしたい場合は以下の手順が必要です。

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

アカウントをリンクすると、セカンダリーアカウントは、ユーザーデータベースの中で別途のアカウントとして存在しなくなり、プライマリーアカウントの一部としてしかアクセスできなくなります。アカウントがリンクされている場合、セカンダリ―アカウントのメタデータはプライマリーアカウントのメタデータと統合されません。また、リンクが解除されると、セカンダリーアカウントが再び独立した際にプライマリーアカウントのメタデータは保持されません。