Skip to main content
Auth0 では、テナントのユーザー情報をホスト型のクラウドデータベースに保存できます。また、カスタムの外部データベースにユーザーデータを保存することも可能です。 Auth0 が認証に使用する基本情報以外のユーザーデータを保存するには、Auth0 データストアまたはカスタムデータベースを使用できます。ただし、その追加データを認証目的でも使用する場合は、Auth0 Management Dashboard からユーザーデータを管理できるため、Auth0 データストアの使用をお勧めします。

外部データベースと Auth0 データストアの比較

Auth0 データストアは、認証データ向けに最適化されています。デフォルトのユーザー情報を超えるデータの保存は、限定的なケースでのみ行うべきです。その理由は次のとおりです。
  • 拡張性: Auth0 データストアの拡張性には限界があり、アプリケーションのデータが適切な上限を超える可能性があります。外部データベースを使用すれば、Auth0 データストアをシンプルに保ちながら、追加データはより効率的な外部データベースに保存できます。
  • パフォーマンス: 認証データは、他のデータに比べてアクセス頻度が低いことが一般的です。Auth0 データストアは高頻度の利用向けには最適化されていないため、より頻繁に取得する必要があるデータは別の場所に保存すべきです。
  • 柔軟性: Auth0 データストアはユーザープロファイルとそれに関連するメタデータのみを扱うように設計されているため、データベースに対して実行できる操作には制限があります。他のデータ用に別のデータベースを使用すれば、適切な方法でデータを管理でき、Auth0 のを使わずに直接呼び出すこともできます。
ユーザー認証を外部委託する場合、通常は独自のユーザー/パスワードテーブルを維持する必要はありません。それでも、認証済みユーザーにアプリケーションデータを関連付けたい場合はあります。
  • たとえば、Auth0 によって認証された各ユーザーを一覧化する Users テーブルを用意できます。ユーザーがログインするたびに、そのユーザーをテーブル内で検索します。ユーザーが存在しなければ新しいレコードを作成し、存在する場合はすべてのフィールドを更新して、実質的にすべてのユーザーデータのローカルコピーを維持できます。
  • あるいは、ユーザーに関連するデータを持つ各テーブル/コレクションにユーザー識別子を保存することもできます。これは、小規模なアプリケーションに適した、よりシンプルな実装です。

ユーザーデータ保存のシナリオ例

Auth0 では、カスタムの外部データベースと Auth0 を組み合わせて使用する際のエンドツーエンドのユーザー体験を示す、モバイル向け音楽アプリのサンプルを提供しています。このサンプルアプリは、Auth0 iOS seed project を使用して作成された iOS アプリです。バックエンドでは Node.js API を使用します。 アプリケーション全体の構造の可視化については、Mobile + API architecture scenario を参照してください。

メタデータ

アプリのメタデータ

モバイル音楽アプリケーションの次のデータ項目は、app_metadata に保存するのが適切です。
  • ユーザーのサブスクリプションプラン
  • 注目のプレイリストを編集する権限の有無
これら 2 つのデータ項目は、ユーザーが直接変更できるものではないため、user_metadata ではなく app_metadata に保存する必要があります。

ユーザーメタデータ

モバイル音楽アプリケーションでは、次のようなデータを user_metadata に保存するのが適切です。
  • アプリケーションの設定
  • ログイン時のアプリの利用体験を変えるために、ユーザーが選択した項目
app_metadata に保存するデータとは異なり、user_metadata に保存されたこれらの項目は、ユーザー自身が簡単に変更できます。 displayName は、ユーザーがログイン時に目にし、アプリのほかのユーザーにも表示される名前なので、ユーザー自身が変更できるようにできます。 ユーザーがログインするたびにそのユーザーが選んだ識別子を表示するには、user.user_metadata の値を取得するルールを使用します。
ユーザーが displayName を変更する際に使用する画面は、次のとおりです。
表示名を更新するオプションがある iOS アプリの設定画面。
変更内容をデータベースに保存するために、アプリケーションは該当するユーザーを特定するため、Management API の Get a User エンドポイントを呼び出します。 続いて、user_metadata フィールドを更新するために Update a User エンドポイントを呼び出します。 {yourAccessToken} は、Management API Access Token に置き換えてください。

ユーザーデータの権限制御ルール

ユーザーが注目のプレイリストを編集できるかどうかを制御する権限を実装するには、ルールを使用します。

Playlist Editorロールを割り当てる

最初のルールは Node API にリクエストを送り、Node API は Heroku に接続されたデータベースを参照して、ユーザーのプレイリストの再生回数を確認します。再生回数が 100 回以上であれば、app_metadataroles 配列に playlist_editor を値として割り当てます。

scope パラメーターでロールを指定する

2 つ目のルールでは、app_metadata フィールドを取得し、roles 配列をユーザーオブジェクト内のフィールドに割り当てます。これにより、アプリケーションで app_metadata を呼び出さなくてもアクセスできるようになります。すると、ユーザーのログイン時に scope パラメーターで roles を指定でき、app_metadata の内容をすべてユーザーオブジェクトに含める必要がなくなります。
これら2つのルールを実装すると、アプリはユーザーがプレイリストエディターかどうかを認識し、それに応じてウェルカム画面を切り替えます。ユーザーの app_metadata に保存されている roles 配列に playlist_editor が含まれている場合、サインイン後の表示は EDITOR になります。
エディターロールを持つユーザープロファイルページの例。

ユーザーの音楽をユーザーに関連付ける

ユーザーの音楽をそのユーザーに関連付ける必要がありますが、この情報は認証には必要ありません。ここでは、アプリケーションのバックエンドと連携する別のデータベースにこの情報を保存する方法を説明します。 ユーザーの一意の識別子は user_id で、authResult 内の idTokenPayload オブジェクトの sub プロパティです。以下は、データベース内の songs テーブルのサンプル行です。 Node.js バックエンドは、 を検証することで、データベースからユーザーの個人データを取得するための URI へのリクエストを認証します。 トークンベースの認証と、アプリケーションで JWT を実装する方法について学びましょう。 以下は、Node.js シードプロジェクトで JWT 検証を実装したコードです。
アプリケーションからのさまざまなデータ要求を処理する機能を追加できます。たとえば、/secured/getFavGenre への GET リクエストを受信すると、API は queryGenre() 関数を呼び出し、データベースを照会してユーザーのお気に入りのジャンルを返します。
関数 buildAPIRequest() は、リクエストのパスと HTTP メソッドをパラメーターとして受け取り、Heroku でホストされている Node.js API のベース URL を使ってリクエストを構築します。 アプリケーションでは、getGenre() 関数が API にリクエストを送信し、/genres/getFav へのリクエストに対するレスポンスが表示されるようにアプリのインターフェースを変更します。バックエンドは、queryGenre() 関数を使ってこの処理に必要なデータを取得し、その結果をアプリケーションに返します。

詳細はこちら