web-dev-qa-db-fra.com

Fonctionnement de l'authentification personnalisée dans MongoDB Stitch

Après authentification personnalisée MongoDB , il est indiqué que tout JWT Token avec les champs minimaux ci-dessous fonctionne avec l'authentification de point MongoDB. De plus, le jeton doit être émis par External Authentication System

{
  "aud": "<stitch app id>"
  "sub": "<unique user id>",
  "exp": <NumericDate>,
}

J'ai testé ça et ça marche aussi

  1. A créé l'application Stitch et activé les utilisateurs avec Custom Authentication Provider
  2. Exemple de jeton généré via Jwt.io avec les entrées ci-dessous. (Utilisez le même algorithme et la même clé que ceux configurés lors de l'activation du fournisseur d'authentification personnalisé, le voici, HS256 et le)

enter image description here

Cela fonctionne dans le sens,

  • Il valide les utilisateurs de MongoDB Stich Users Collection avec l'unique value fourni dans sub: "sub": "<unique user id>" et si l'utilisateur est présent, il renvoie l'ID d'objet pour cet utilisateur.
  • Si l'utilisateur n'est pas présent, il en crée un par rapport à l'entrée et renvoie l'ID d'objet.

Les requêtes sont,

  1. Pourquoi crée-t-il un nouvel utilisateur au lieu de renvoyer un échec de connexion, qui à son tour fonctionne comme n'importe quel utilisateur peut se connecter avec des informations d'identification à la demande?
  2. Si MongoDB Stitch Custom Authentication implique External Authentication System pour émettre JWT, où les données utilisateur seront-elles réellement stockées lors de l'inscription de l'utilisateur? - MongoDB Stitch App Collection ou External Authentication API System?
mongodbjwtcustom-authenticationmongodb-stitch
4
mbharanidharan88

Voici la réponse de MongoDB Support

Pourquoi Stitch crée-t-il un nouvel "utilisateur"

Le point "utilisateur" créé dans ce scénario est un utilisateur interne. Cet "utilisateur" contient également les données utilisateur et les métadonnées fournies par le JWT et n'est pas stocké avec vos autres collections dans le cluster Atlas auquel votre application est liée. Notez que cet "utilisateur" n'est pas accessible à MongoDB sans utiliser un déclencheur ou une autre fonction pour le charger dans la base de données.

Pourquoi un échec de connexion n'est-il pas retourné

Un échec de connexion n'est pas renvoyé car le fournisseur d'authentification personnalisé vérifie uniquement le JWT signé du système externe par rapport à sa propre copie de la clé de signature. Si les signatures correspondent, la connexion est considérée comme réussie.

Il est de la responsabilité du fournisseur d'authentification externe d'échouer la connexion; pas Stitch.

Où les données utilisateur seront-elles réellement stockées

Les données utilisateur doivent être gérées dans votre base de données. Le moyen le plus efficace d'intégrer cela au fournisseur d'authentification personnalisée consiste à utiliser un déclencheur d'authentification sur les types d'opérations de création et/ou de connexion. Cela vous permettrait d'exécuter une fonction Stitch chaque fois qu'un événement d'authentification est déclenché.

Il existe un exemple d'utilisation de déclencheurs d'authentification sur le blog MongoDB qui peut aider à expliquer le processus plus en détail.

4
mbharanidharan88