Skip to main content
ユーザーがどのようにサインアップするかを早い段階で決めておくことは重要です。ここでの判断は、その後に必要となる多くの判断に影響します。Auth0 の知見では、ユーザーをシステムに追加する方法には一般的ないくつかのパターンがあり、ワークフロー設計を検討する際に押さえておくべきポイントもあります。
Auth0 はさまざまなワークフローをサポートしていますが、サインアップに Auth0 の Universal Login を使用する Web ベースのワークフローは、最適な機能と高水準のセキュリティを実現できるため、業界および Auth0 のベストプラクティスとされています。
Auth0 は、さまざまな アイデンティティプロバイダー を通じたユーザーのサインアップをサポートしています。サインアップ時には、Auth0 が ユーザープロファイル を作成し、ユーザーのアカウント情報を格納します。機能やワークフローを検討する際には、考慮すべき点がいくつかあります。
  • Auth0 をアイデンティティストアとして使用すべきですか?
  • 独自の (レガシー) アイデンティティストアを Auth0 と併用できますか?
  • アイデンティティストアから Auth0 にユーザーアイデンティティをどのように移行しますか?
  • ユーザーは Google や Facebook など、既存のソーシャルアカウントを使ってサインアップできますか?
Auth0 には、ユーザーの認証情報を安全に保存できる組み込みのアイデンティティストレージがあります。詳しくは セルフサインアップ を参照してください。すでにレガシーアイデンティティストアがあり、その管理を Auth0 に移したい場合は、 ユーザー移行 機能でそのための複数の方法を利用できます。 一方で、レガシーアイデンティティストアを維持する必要がある場合、たとえば、まだ移行の準備ができていない、または移行できないアプリケーションがある場合には、 アイデンティティストアのプロキシ 機能を利用できます。また、顧客に「自分のアイデンティティを持ち込む」ことを許可するのも魅力的な選択肢です。導入当初からこれを採用するケースは多くありませんが、 Social サインアップ 機能を使って提供できます。

ユーザー移行

Auth0 は、ユーザープロファイル をホストするだけでなく、お客様独自の既存のアイデンティティストアを プロキシ したり、Auth0 がホストする安全な置き換え先を提供したりすることもできます。これら 2 つの機能はいずれも Auth0 の Database Connections を通じて利用できます。既存のアイデンティティストアの置き換え先として Auth0 を使用する場合は、ユーザー移行 によって、バルク移行で一括に、または自動移行で段階的にユーザーを移行できます。
多くのお客様は、まず自動移行を使ってできるだけ多くのユーザーを移行し、その後、残ったユーザーに対してバルク移行を使うという 2 段階のアプローチを選択します。詳細については、User Migration Scenarios を参照してください。
自動移行は、ユーザーを 1 人ずつ移行でき、さらにほとんどのケースで既存のパスワードも維持できるため、推奨されます。バルク移行については、最も単純なケースを除き、User Import/Export extension ではなく Management API を使用することを推奨します。これは、 のほうが、より高い柔軟性と制御性を備えているためです。 バルク移行では通常、移行完了後にユーザーは一度パスワードをリセットする必要があります。ただし、既存のアイデンティティストアでパスワードが bcrypt を使用してハッシュ化されて保存されている場合 (または bcrypt 形式で生成できる場合) は例外です。この場合、bcrypt アルゴリズムと使用しているソルトラウンド数によっては、バルク移行を利用しながら、プロセスの一部として ユーザーのパスワードを維持できる 可能性があります。詳細については、Bulk Import Database Schema Examples を参照してください。
Management API の呼び出しには、Auth0 のレート制限ポリシー が適用されます。この点を考慮する必要があります。また、その対応をしやすくするために、Auth0 では通常、API を直接呼び出すのではなく、開発環境に適した Auth0 SDK を使用することを推奨しています。

アイデンティティストアのプロキシ

Auth0 Database Connection タイプは、既存の (レガシーな) アイデンティティストアをプロキシするように設定することもできます。独自のレガシーなストアで定義されたユーザー ID を維持する必要がある場合、たとえば Auth0 に移行できない業務上重要なアプリケーションが 1 つ以上あり、それでもそれらの ID へのアクセスが必要な場合でも、Auth0 と簡単に統合できます。詳細については、Authenticate Users Using Your Database を参照してください。

セルフサインアップ

セルフサインアップでは、Auth0 Database Connections を使用して、サインアップ時に新規ユーザーから収集したユーザー ID、パスワード、 (任意で) ユーザー名などの識別情報を保存します。最小 ユーザー名の長さ や パスワードの強度と複雑さ などを定めるデータベース接続ポリシーは、 で設定できます。
Auth0 Universal LoginLock などの Auth0 ウィジェットは、Database Connections と連携し、サインアップに必要な包括的なユーザーインターフェース機能を標準で提供します。これらの UI はすべてリアクティブで、豊富な設定オプションと柔軟なカスタマイズにより、ユーザーのセルフサインアップ機能だけでなくログイン機能も実装できます。

Social サインアップ

Social サインアップは、ソーシャル認証によるサインインと同義です。ここでは厳密には両者に区別はなく、ユーザープロフィールは初回のソーシャルログイン時に自動的に作成されます。

プロジェクト計画ガイド

推奨する戦略の詳細をご確認いただけるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。 B2C IAM プロジェクト計画ガイド