Auth0
7
どのような問題がありますか?

この記事は最終更新日から1年以上が経過しています。

投稿日

更新日

Auth0のログインID(メールアドレス)を変更する方法を考えてみた

はじめに

Auth0のUniversal Loginにはパスワードリセットの機能はありますが、ログインID(メールアドレス)を変更する機能がなさそうなので、Auth0を利用するアプリからメールアドレスを変更する方法を考えてみました。

メールアドレスの変更手順

単純にユーザーに新しいメールアドレスを入力してもらって、Management APIでメールアドレスを更新!
とやってしまうと、誤ったメールアドレスが入力された場合その内容で更新されてしまうのでログインが出来なくなってしまう恐れがあります。
新しいメールアドレスの妥当性を確認しつつ更新するには以下のような手順を踏む必要があると考えました。

  1. ユーザーがアプリにログインする
  2. ユーザーに新メールアドレスを入力してもらう
  3. 新メールアドレスにメール送信
  4. ユーザーは新メールアドレスに届いたメールを確認
  5. 新メールアドレスでユーザー情報(メールアドレス)を更新

この中の4のメールの受信確認ですが、よくある手法として

  • slackのようにマジックリンクをメールに記載し、ユーザーにリンクを踏んでもらう
  • メールにワンタイムパスワード(OTP)を記載しておき、アプリの画面からユーザーにOTPを入力してもらう。

の2つがあると思います。
しかし、いざ実装しようとするとマジックリンクやOTPの生成方法や有効期限を考える必要があるので、自前で作るのは結構大変そうです。

できるだけ自前での実装はやりたくなかったので、Auth0のパスワードレス認証を利用してこの手順を実現してみました。

シーケンス図

大まかな流れをシーケンス図にするとこうなります。

change_email_address.png

  • ユーザーはログイン済みの状態から新しいメールアドレスを使ってパスワードレス認証(OTP)を行う。
    • マジックリンクでのパスワードレス認証はいろいろな都合でうまくいかなかったのでOTPを利用
  • パスワードレス認証の流れで新しいメールアドレスの有効性を確認。
  • Auth0を利用するクライアントアプリはパスワードレス認証の結果としてトークンを取得。
    • このとき、クライアントアプリは変更前のメールアドレスでログインしたときのトークンと、パスワードレス認証で取得したトークンの2つを保持する。
  • パスワードレス認証で取得したIDトークンを検証し、クレームから新しいメールアドレスを取得。
    • アクセストークンを使って GET /userinfoからメールアドレスを取得してもOK
  • Management APIを叩くためのアクセストークンを取得
    • update:usersdelete:usersのscopeが必要
  • パスワードレス認証で作成されたユーザーを削除し、現在ログインしているユーザーのメールアドレスを更新する。
  • メールアドレスの更新が成功したら、新旧両方のメールアドレスに通知を飛ばす。
    • 新しいメールアドレスで既にユーザー登録されていて更新がエラーとなった場合はその旨を通知。

こんな感じでやってみました。
一応、新しいメールアドレスが既に登録済みであることを示すメッセージは、メールアドレスの有効性確認後にしか表示しないようにして、登録済みかどうかはそのメールアドレスの所有者にしかわからないようにしています。

これでスクリーニング対策になってる…かな?

Auth0の設定

クライアントアプリの設定

DashBoardのApplicationsからクライアントアプリをRegular Web Applicationとして登録。
適当にCalback URLsなんかを設定して、普通にUniversal Loginが使えるようにします。
あと、忘れずにAdvanced SettingsのGrant TypeにあるPasswordless OTPにチェックを入れておきます。

M2Mアプリの設定

DashBoardのAPIsを開き、Auth0 Management APIを選択します。
Machine to Machine Applicationsのメニューを開き、先に設定したクライアントアプリのトグルボタンをONにし、APIのpermissions設定でupdate:usersdelete:usersのscopeにチェックを入れておきます。

これでクライアントアプリからManagement APIを叩けるようになります。

パスワードレス認証設定

DashBoard > Connections > Passwordlessを押して、Emailのパスワードレス認証を有効化し、SettingsのAuthentication Parametersを以下のように編集します。

{
  "scope": "openid email"
}

あとはApplicationsからクライアントアプリのパスワードレス認証を有効化すればOKです。

クライアントアプリの実装

クライアントアプリはNode.js(Express.js)で実装してみました。
以降のコードは主要部分のみの抜粋です。

パスワードレス認証の開始

シーケンス図の2と3に該当します。
ユーザーに新しいメールアドレスを入力してもらい、パスワードレス認証を開始します。

const axios = require('axios');

router.post('/change-email', async (req, res) => {
  // パスワードレス認証の開始
  await axios.post(
    'https://{Auth0のドメイン}/passwordless/start',
    {
      client_id: '{クライアントID}',
      client_secret: '{クライアントシークレット}',
      connection: 'email',
      email: '{新しいメールアドレス}',
      send: 'code',
    },
  );

  res.redirect('/otp'); // OTP入力画面にリダイレクト
});

OTPとトークンを交換

シーケンス図の6に該当します。
OTPを入力する画面ではCSRF対策をしたほうが良いと思います。

const axios = require('axios');
const querystring = require('querystring');

const response = await axios.post(
  'https://{Auth0のドメイン}/oauth/token',
  querystring.stringify({
    grant_type: 'http://auth0.com/oauth/grant-type/passwordless/otp',
    client_id: '{クライアントID}',
    client_secret: '{クライアントシークレット}',
    username: '{新しいメールアドレス}',
    realm: 'email',
    otp: '{OTP}',
  }),
);

IDトークンの検証

シーケンス図の9に該当します。
IDトークンの検証と同時にクレームを取得しています。

const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const userInfo = async (idToken) => new Promise((resolve, reject) => {
  const client = jwksClient({
    jwksUri: 'https://{Auth0のドメイン}/.well-known/jwks.json',
    cache: true,
    rateLimit: true,
    jwksRequestsPerMinute: 5,
  });
  const getKey = (header, callback) => {
    client.getSigningKey(header.kid, (err, key) => {
      const signingKey = key.publicKey || key.rsaPublicKey;
      callback(null, signingKey);
    });
  };
  const options = {
    algorithms: ['RS256'],
    audience: '{クライアントID}',
    issuer: 'https://{Auth0のドメイン}/',
  };

  jwt.verify(idToken, getKey, options, (error, decoded) => {
    if (error) {
      reject(error);
    } else {
      resolve(decoded);
    }
  });
});

Management API用のアクセストークンを取得

シーケンス図の10と11に該当します。
Management APIのアクセストークンはキャッシュしておいて、有効期限が切れたら再取得するようにしておくと良いです。

const axios = require('axios');

const params = new URLSearchParams();
params.append('audience', 'https://{Auth0のドメイン}/api/v2/');
params.append('scope', 'update:users delete:users');
params.append('grant_type', 'client_credentials');
params.append('client_id', '{クライアントID}');
params.append('client_secret', '{クライアントシークレット}');

const responseToken = await axios.post(
  'https://{Auth0のドメイン}/oauth/token', params
);

パスワードレス認証で作成されたユーザーを削除

シーケンス図の12に該当します。
先にパスワードレス認証で取得したIDトークンのsubクレームを指定してユーザーを削除

const axios = require('axios');

await axios.delete('https://{Auth0のドメイン}/api/v2/users/{IDトークンのsubクレーム}', {
  headers: { Authorization: 'Bearer {Management APIのアクセストークン}' },
  data: {},
});

メールアドレスの更新

シーケンス図の13に該当します。
更新対象のユーザーは元々ログインしているほうのユーザーなので間違えないようにしましょう。

await axios.patch(
  'https://{Auth0のドメイン}/api/v2/users/{現在ログインしているユーザーのsub}',
  querystring.stringify(
    {
      email: '{IDトークンのemailクレーム}',
      email_verified: true,
    },
  ),
  { headers: { Authorization: 'Bearer {Management APIのアクセストークン}' } },
)
  .catch(
    (error) => // エラーハンドリング
  );

変更後のメールアドレスが既に存在している場合、このAPIリクエストはエラーとなって以下のレスポンスが帰ってきます。

{ statusCode: 400,
  error: 'Bad Request',
  message: 'The specified new email already exists',
  errorCode: 'auth0_idp_error' }

このエラーが帰ってきたらユーザーに「このメールアドレスは既に登録されています。」などの通知を出すと良いと思います。

このメールアドレス変更手順の注意点

ここまでAuth0のパスワードレス認証の仕組みを利用したメールアドレス変更手順を紹介してきましたが、いくつか注意点があります。

パスワードレス認証の使い方

そもそもパスワードレス認証はこんな使われた方を想定した機能ではないはずなので、何か不都合があるかもしれませんし、今後パスワードレス認証の仕様が変わったときに想定外の挙動をする可能性もあります。
もしもこの内容を試されるときは、そういった点を承知の上で実施してください。

RulesでLink Accounts with Same Email Addressを設定している場合

RulesのLink Accounts with Same Email Addressを設定して同一メールアドレスのアカウントリンクを実施していると
新しく入力されたメールアドレスが既に登録済みの場合に既存のアカウントと新しいメールアドレスで作成されたユーザーが統合され、既存アカウントごとユーザーが削除されてしまいます。

RulesでLink Accounts with Same Email Addressを設定している場合は、パスワードレス認証で作成されたユーザーはアカウントリンクの対象外にする必要があります。

Rulesの冒頭部分
function (user, context, callback) {
  const request = require('request');

  // Emailによるパスワードレス認証の場合はアカウントリンクの対象外となるように条件追加
  if (!user.email || !user.email_verified || context.connection === "email") {
    return callback(null, user, context);
  }

クライアントアプリのタイプ

このメールアドレス変更フローはクライアントアプリがConfidential Clientでないと成功しません。
SPAやNative AppのようなPublic Clientだと、Management APIのscope(update:usersdelete:users)が取れないので失敗します。

おわりに

Universal Loginの標準機能でログインIDを変更する機能が追加されると嬉しいんですが
現状そんな機能はないので、無理やりAuth0の機能を使って実装してみました。
もっと他にスマートなやり方があれば誰か教えて欲しいです。

ユーザー登録して、Qiitaをもっと便利に使ってみませんか。
  1. あなたにマッチした記事をお届けします
    ユーザーやタグをフォローすることで、あなたが興味を持つ技術分野の情報をまとめてキャッチアップできます
  2. 便利な情報をあとで効率的に読み返せます
    気に入った記事を「ストック」することで、あとからすぐに検索できます
ユーザー登録ログイン
この記事は以下の記事からリンクされています

コメント

同じ事で悩んでいるんですが、単純にログインしている事が前提である場合

  1. ユーザーがログインしている
  2. ログインした状態でブラウザを放置してしまう(ブラウザを開き直して、サイトにアクセスすればパスワード入力無しにログイン出来る状態など)
  3. 誰かがサイトにアクセスしてパスワード無しでログイン状態のページを開けてしまう
  4. メールアドレス変更をする
  5. 乗っ取られる

なんて事にはならないでしょうか?

https://www.youtube.com/watch?v=RMza7El7IwE
似たような解決方法の動画も見ましたが、メールアドレス変更時に特に現状のパスワードを入力するような流れにはなってませんでした。

0

因みにauth0.com自体はメールアドレス(ログインID)の変更は出来るようになっておらず、メールアドレスを変更したいなら

  1. auth0.comにログイン
  2. 別のメールアドレスをadministratorとして追加
  3. 完了したら古い方を消すなど ...

この方法でも既にブラウザを放置している状態だとどうにもならないんですが ...
メールアドレスを追加する一歩手前でパスワード認証出来るようになっていれば ... と思うんですが

0

ご指摘のとおり、ログイン済みの状態のブラウザを他者に利用されるケースだとメールアドレスを変更した後にパスワードリセットをかけることで乗っ取りが可能ですね。

そういったケースまで想定するのであれば、おっしゃるとおりメールアドレス変更処理の前に再認証を要求すればよいのではないでしょうか。
Client側の実装なりAuth0のRulesなりで対応可能かと思います。

0
どのような問題がありますか?
あなたもコメントしてみませんか :)
ユーザー登録
すでにアカウントを持っている方はログイン
7
どのような問題がありますか?
ユーザー登録して、Qiitaをもっと便利に使ってみませんか

この機能を利用するにはログインする必要があります。ログインするとさらに下記の機能が使えます。

  1. ユーザーやタグのフォロー機能であなたにマッチした記事をお届け
  2. ストック機能で便利な情報を後から効率的に読み返せる
ユーザー登録ログイン
ストックするカテゴリー