Authentication API Debugger Extension

User Data Storage Scenario

Auth0 provides a sample app, a mobile music application, that reflects the end-to-end user experience when using Auth0 with an custom external database. The sample app is an iOS app created using the Auth0 iOS seed project. The backend uses the Node.js API.

For a visualization of the application's overall structure, see the Mobile + API architecture scenario.

Install the Extension


Authorize the Extension

App metadata

The following data points from our mobile music application are appropriate to store in app_metadata:

  • User's subscription plan
  • User's right (or lack thereof) to edit featured playlists

These two data points should be stored in app_metadata instead of user_metadata because they should not be directly changeable by the user.

Basic Configuration

User metadata

The following data points from our mobile music application are appropriate to store in user_metadata:

  • Application preferences;
  • Any details chosen by the user to alter their experience of the app upon login.

Note that, unlike the data points for app_metadata, the user can easily and readily change those stored in user_metadata.

We can let the user change their displayName, which is the name the user sees upon logging in and is displayed to other users of the app.

To display the user's chosen identifier whenever they log in, we use a rule to get the user.user_metadata value.

Here's a look at the screen the user would use to change their displayName:

To save the changes to the database, the application makes a call to the Get a User endpoint of the Management API to identify the appropriate user:

This is followed by a call to the Update a User endpoint to update the user_metadata field:

You must replace YOUR_ACCESS_TOKEN with a Management API Access Token.

Execute the Flows

User data permission rules

Use rules to implement permissions on whether a user can edit featured playlists or not.

Assign Playlist Editor role

The first rule sends a request to our Node API, which then queries the database connected to Heroku to check how many plays the user’s playlist has. If the number is 100 or greater, we assign playlist_editor as a value in the roles array in app_metadata.

Scope parameter specifies role

The second rule gets the app_metadata field and assigns the roles array to a field in the user object so it can be accessed without calling app_metadata on the application. The scope parameter can then specify roles upon the user logging in without including everything in app_metadata in the user object:

After we've implemented these two rules, the app recognizes whether the user is a playlist editor or not and changes the welcome screen accordingly. If playlist_editor is in the roles array stored in the user's app_metadata, the user will be welcomed as an EDITOR after signing in:

Associate a user's music with the user

We need to associate a user's music with that user, but this information is not required for authentication. Here's how to store this information in a separate database that is integrated with the backend of the application.

The user's unique identifier is their user_id. Here is a sample row from the songs table in our database:

song_id songname user_id
1 Number One Hit google-oauth2

The Node.js backend authenticates requests to the URI associated with getting the user’s personal data from the database by validating a JSON Web Token.

Here is the code implementing JWT validation from the Node.js seed project:

We can add functionality to handle different data requests from our Application. For example, if we receive a GET request to /secured/getFavGenre, the API calls the queryGenre() function, which queries the database for and responds with the user’s favorite genre.

The function buildAPIRequest() takes the path and HTTP method of the request as parameters and builds a request using the base URL of our Node.js API that's hosted on Heroku.

In the Application, the getGenre() function makes a request to the API and changes the app's interface to display the request response to /genres/getFav. The backend retrieves the required data for this action using the queryGenre() function and returns the results to the Application:

Keep reading