Stockage des données des utilisateurs

Découvrez les différences entre l’utilisation du stockage de données Auth0 et d’une base de données externe pour stocker les données des utilisateurs.

Auth0 stocke les renseignements sur les utilisateurs de votre tenant dans une base de données infonuagique hébergée, ou vous pouvez choisir de stocker les données utilisateur dans votre propre base de données externe personnalisée.

Pour stocker des données utilisateur au-delà des renseignements de base qu’Auth0 utilise pour l’authentification, vous pouvez utiliser le magasin de données Auth0 ou une base de données personnalisée. Toutefois, si vous utilisez ces données supplémentaires à des fins d’authentification, nous vous recommandons d’utiliser le magasin de données Auth0, car cela vous permet de gérer vos données utilisateur à partir du tableau de bord de gestion Auth0.

​

Base de données externe ou magasin de données Auth0

Le magasin de données Auth0 est conçu spécialement pour les données d’authentification. Il ne faut stocker autre chose que les renseignements utilisateur par défaut que dans des cas limités. Voici pourquoi :

• Évolutivité : Le magasin de données Auth0 présente des limites d’évolutivité, et les données de votre application pourraient dépasser les seuils appropriés. En utilisant une base de données externe, vous gardez votre magasin de données Auth0 simple, tandis qu’une base de données externe plus efficace stocke les données supplémentaires;
• Performance : Vos données d’authentification sont probablement consultées moins souvent que vos autres données. Le magasin de données Auth0 n’est pas optimisé pour une utilisation à fréquence élevée; les données qui doivent être récupérées plus souvent devraient donc être stockées ailleurs;
• Flexibilité : Comme le magasin de données Auth0 a été conçu pour prendre en charge uniquement les profils utilisateur et les métadonnées qui y sont associées, vous êtes limité quant aux actions que vous pouvez effectuer sur la base de données. En utilisant des bases de données distinctes pour vos autres données, vous pouvez les gérer comme bon vous semble et effectuer des appels directs sans passer par l’API de gestion d’Auth0.

Lorsqu’on confie l’authentification des utilisateurs à un fournisseur externe, il n’est généralement pas nécessaire de maintenir sa propre table utilisateurs/mots de passe. Cela dit, vous pourriez quand même vouloir associer les données de l’application aux utilisateurs authentifiés.

• Par exemple, vous pourriez avoir une table Users qui répertorie chaque utilisateur authentifié par Auth0. Chaque fois qu’un utilisateur ouvre une session, vous pourriez le rechercher dans la table. S’il n’existe pas, vous créeriez un nouvel enregistrement. S’il existe déjà, vous mettriez à jour tous les champs, ce qui reviendrait essentiellement à conserver une copie locale de toutes les données utilisateur.
• Autrement, vous pourriez stocker l’identifiant utilisateur dans chaque table ou collection qui contient des données associées à l’utilisateur. Il s’agit d’une approche plus simple, adaptée aux applications de plus petite taille.

​

Exemple de scénario de stockage des données utilisateur

Auth0 fournit une application de démonstration — une application musicale mobile — qui illustre l’expérience utilisateur de bout en bout lorsqu’on utilise Auth0 avec une base de données externe personnalisée. Cette application de démonstration est une appli iOS créée à partir du projet de démarrage Auth0 pour iOS. Le backend utilise l’API Node.js.

Pour obtenir une vue d’ensemble de la structure de l’application, consultez le scénario d’architecture Mobile + API.

​

Métadonnées

​

Métadonnées de l’application

Les éléments de données suivants de notre application mobile de musique peuvent être stockés dans app_metadata :

• Le forfait d’abonnement de l’utilisateur
• Le droit de l’utilisateur (ou non) de modifier les listes de lecture en vedette

Ces deux éléments devraient être stockés dans app_metadata plutôt que dans user_metadata, puisqu’ils ne devraient pas pouvoir être modifiés directement par l’utilisateur.

​

Métadonnées de l’utilisateur

Les types de données suivants de notre application mobile de musique peuvent être stockés dans user_metadata :

• Préférences de l’application
• Éléments choisis par l’utilisateur pour personnaliser son expérience de l’application à la connexion.

Notez que, contrairement aux données de app_metadata, l’utilisateur peut facilement modifier celles stockées dans user_metadata.

Nous pouvons permettre à l’utilisateur de modifier son displayName, c’est-à-dire le nom qu’il voit à la connexion et qui est affiché aux autres utilisateurs de l’application.

Pour afficher l’identifiant choisi par l’utilisateur chaque fois qu’il se connecte, nous utilisons une règle pour récupérer la valeur user.user_metadata.

function(user, context, callback){
  user.user_metadata = user.user_metadata || {};
  user.user_metadata.displayName = user.user_metadata.displayName || "user";

  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
    .then(function(){
      callback(null, user, context);
    })
    .catch(function(err){
      callback(err);
    });
}

Voici l’écran que l’utilisateur utiliserait pour modifier son displayName :

Pour enregistrer les modifications dans la base de données, l’application appelle le point de terminaison Get a User de l’API de gestion afin de repérer l’utilisateur concerné :

Cela est suivi d’un appel au point de terminaison Update a User pour mettre à jour le champ user_metadata :

Vous devez remplacer {yourAccessToken} par un jeton d’accès à l’API de gestion.

​

Règles d’autorisation pour les données utilisateur

Utilisez les règles pour définir si un utilisateur peut modifier ou non les listes de lecture en vedette.

​

Attribuer le rôle Playlist Editor

La première règle envoie une requête à notre API Node, qui interroge ensuite la base de données connectée à Heroku pour vérifier combien de lectures la liste de lecture de l’utilisateur a obtenues. Si ce nombre est de 100 ou plus, nous ajoutons playlist_editor comme valeur dans le tableau roles de app_metadata.

function (user, context, callback) {

  var request = require('request');

  user.app_metadata = user.app_metadata || {};
  user.app_metadata.roles = user.roles || [];

  var CLIENT_SECRET = configuration.AUTH0_CLIENT_SECRET;
  var CLIENT_ID = configuration.AUTH0_CLIENT_ID;

  var scope = {
    user_id: user.user_id,
    email: user.email,
    name: user.name
  };

  var options = {
    subject: user.user_id,
    expiresInMinutes: 600,
    audience: CLIENT_ID,
    issuer: 'https://example.auth0.com'
  };

  var id_token = jwt.sign(scope, CLIENT_SECRET, options);

  var auth = 'Bearer ' + id_token;

  request.get({
    url: 'https://example.com/playlists/getPlays',
    headers: {
       'Authorization': auth,
      'Content-Type': 'text/html'
    },
    timeout: 15000
  }, function(err, response, body){
    if (err)
      return callback(new Error(err));
    var plays = parseInt(body, 10);

    if (plays >= 100 && user.roles.indexOf('playlist_editor') < 0){
      user.app_metadata.roles.push('playlist_editor');
      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
        .then(function(){
          callback(null, user, context);
        })
        .catch(callback);
    }

    else if (plays < 100 && user.roles.indexOf('playlist_editor') >= 0){
      user.app_metadata.roles = [];
      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
        .then(function(){
          callback(null, user, context);
        })
        .catch(callback);
    }
    else{
      callback(null, user, context);
    }

  });

}

​

Le paramètre scope précise le rôle

La deuxième règle récupère le champ app_metadata et assigne le tableau roles à un champ de l’objet utilisateur afin qu’il soit accessible sans avoir à appeler app_metadata dans l’application. Le paramètre scope peut ensuite préciser roles au moment de la connexion de l’utilisateur, sans inclure tout le contenu de app_metadata dans l’objet utilisateur :

function(user, context, callback) {
   if (user.app_metadata) {
      user.roles = user.app_metadata.roles;
   }
   user.roles = user.roles || [];
   callback(null, user, context);
}

Après avoir mis en place ces deux règles, l’application détermine si l’utilisateur est un éditeur de playlists ou non et adapte l’écran d’accueil en conséquence. Si playlist_editor figure dans le tableau roles enregistré dans le app_metadata de l’utilisateur, celui-ci sera accueilli comme un ÉDITEUR après s’être connecté :

​

Associer la musique à un utilisateur

Nous devons associer la musique d’un utilisateur à celui-ci, mais cette information n’est pas requise pour l’authentification. Voici comment stocker cette information dans une base de données distincte intégrée au backend de l’application.

L’identifiant unique de l’utilisateur est user_id, et il correspond à la propriété sub de l’objet idTokenPayload dans un authResult. Voici un exemple de ligne de la table songs dans notre base de données :

song_id	songname	user_id
1	Number One Hit	google-oauth2

Le backend Node.js authentifie les requêtes vers l’URI utilisée pour récupérer les données personnelles de l’utilisateur depuis la base de données en validant un JSON Web Token.

Pour en savoir plus sur l’authentification par jeton et sur l’implémentation de JWT dans vos applications.

Voici le code qui implémente la validation des JWT dans le projet de démarrage Node.js :

var genres = require('./routes/genres');
var songs = require('./routes/songs');
var playlists = require('./routes/playlists');
var displayName = require('./routes/displayName');

var authenticate = jwt({
  secret: process.env.AUTH0_CLIENT_SECRET,
  audience: process.env.AUTH0_CLIENT_ID
});

app.use('/genres', authenticate, genres);
app.use('/songs', authenticate, songs);
app.use('/playlists', authenticate, playlists);
app.use('/displayName', authenticate, displayName);

Nous pouvons ajouter des fonctionnalités pour traiter différentes requêtes de données provenant de notre application. Par exemple, si nous recevons une requête GET à /secured/getFavGenre, l’API appelle la fonction queryGenre(), qui interroge la base de données et renvoie le genre préféré de l’utilisateur.

@IBAction func getGenre(sender: AnyObject) {
        let request = buildAPIRequest("/genres/getFav", type:"GET")
        let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {[unowned self](data, response, error) in
            let genre = NSString(data: data!, encoding: NSUTF8StringEncoding)
            dispatch_async(dispatch_get_main_queue(), {
                self.favGenre.text = "Favorite Genre:  \(genre!)"
            })
        }
        task.resume()
    }

La fonction buildAPIRequest() prend en paramètres le chemin d’accès et la méthode HTTP de la requête, puis construit celle-ci à partir de l’URL de base de notre API Node.js hébergée sur Heroku.

Dans l’application, la fonction getGenre() envoie une requête à l’API et modifie l’interface pour afficher la réponse à la requête envoyée à /genres/getFav. Le backend récupère les données nécessaires à cette action à l’aide de la fonction queryGenre() et renvoie les résultats à l’application :

function queryGenre(user_id, res){

  db.connect(process.env.DATABASE_URL, function(err, client) {
  if (err) throw err;

  client
    .query('SELECT fav_genre as value FROM user_data WHERE user_id = $1', [user_id], function(err, result) {

      if(err) {
        return console.error('error running query', err);
      }
      res.send(result.rows[0].value);
    });
  });

};

​

En savoir plus

• Profils d’utilisateurs normalisés
• Schéma de profil d’utilisateur normalisé
• Exemples de profils d’utilisateurs