Database
 sql >> Base de données >  >> RDS >> Database

Connexion avec des services externes

La saisie d'un nom d'utilisateur et d'un mot de passe est un moyen d'accéder à un compte, mais ce n'est pas le seul. Dans cet article, nous verrons comment activer des services externes (comme Google ou Facebook) lors de la connexion à une base de données.

Que sont les identifiants de service externe ?

Donner à un utilisateur la possibilité d'accéder à ses comptes système via des services externes est une tendance croissante parmi les concepteurs de sites Web. Cette option peut offrir plusieurs avantages, comme donner aux utilisateurs une combinaison nom-mot de passe de moins à retenir. Cela peut également aider les administrateurs à personnaliser les expériences utilisateur.

Lorsque les applications Web proposent une connexion à un service externe, l'écran de connexion ressemble à l'image ci-dessous. Un utilisateur peut saisir son identifiant et son mot de passe, ou il peut cliquer sur un bouton qui le redirigera vers le service de son choix (Facebook, Twitter, Google, etc.) où il se connectera et sera redirigé vers l'application d'origine.

Voici un exemple d'écran de connexion de la Vertabelo Academy :

Fonctionnement des connexions externes

L'ajout de services de connexion externes nécessite un travail supplémentaire de la part des développeurs. Les services de médias sociaux les plus populaires utilisent un protocole appelé OAuth 2.0 . Seul Twitter utilise un ancien protocole appelé OAuth 1.0 . Le protocole permet la lecture des informations de l'utilisateur telles que son nom complet, son adresse e-mail, son sexe, etc. Les informations exactes disponibles dépendent du service de réseau social et de tout ce que l'utilisateur a fourni. (Par exemple, il est possible d'avoir un compte Facebook sans adresse e-mail jointe.) Quoi qu'il en soit, nous nous concentrerons sur la manière d'implémenter ce système dans la conception d'une base de données.

Comme point de départ, nous utiliserons notre article précédent sur la récupération de mot de passe et la confirmation par e-mail comme base. Voici les tables relatives aux utilisateurs de cet article.




Concevoir une base de données pour les connexions externes

Beaucoup d'informations dans le user_account table est liée à la gestion de l'authentification - ainsi que des fonctionnalités connexes telles que le rappel de mot de passe et la confirmation par e-mail - par nous-mêmes. Nous n'avons pas besoin de ces colonnes si l'utilisateur s'authentifie auprès d'un service externe. Le rappel de mot de passe, la confirmation par e-mail et d'autres fonctionnalités sont gérés par le service externe. La première étape de notre conception consiste à séparer le user_account table en deux tables :user_account et user_profile .

Le user_account table gère désormais toute sa propre comptabilité d'authentification. Le user_profile Le tableau représente les informations réelles de l'utilisateur :nom, adresse e-mail, fuseau horaire, acceptation des conditions de service, etc. Toutes les tables d'entreprise doivent maintenant être liées au user_profile tableau.

Passons maintenant aux comptes externes. Le OAuth protocole, à la fin, nous donne un identifiant pour l'utilisateur dans leur système. Cet identifiant n'est pas le nom de l'utilisateur dans le système externe. C'est juste un identifiant pour notre application. Nous devons stocker cet identifiant interne dans notre base de données. Nous pourrions ajouter des colonnes nullables facebook_id , google_id , twitter_id , etc. à la table user_profile . Mais nous ferons quelque chose de différent.

Nous allons ajouter de nouveaux tableaux :facebook_account , twitter_account , google_account , qui stockera l'identifiant externe. De cette façon, si nous en avons besoin, nous pouvons ajouter des informations supplémentaires spécifiquement pour chaque site Web social. Si nous voulons ajouter une possibilité de connexion à un autre site Web social, nous n'aurons pas à modifier le user_profile table. Nous n'ajouterons qu'un autre external_service_account tableau.

Chacune des nouvelles tables partage le même format de colonne. L'un d'eux sera int user_profile_id , qui est à la fois une clé étrangère référençant la colonne id dans le user_profile table et la clé primaire. (Cela peut servir de clé primaire car deux comptes de notre système ne doivent pas être associés à plusieurs comptes du même service externe.)

L'autre colonne sera l'identifiant du compte externe - facebook_id , par exemple. Il y a une contrainte unique sur chacun des facebook_id , google_id , et twitter_id Colonnes. Nous savons que deux comptes ne reçoivent pas le même identifiant. En fait, lorsque l'utilisateur est authentifié auprès d'un service externe, nous connaissons son facebook_id . Lorsque nous trouvons la ligne correspondante dans le facebook_account table et trouvez le bon user_profile , nous savons quel utilisateur vient de se connecter au système. S'il n'y a pas de ligne avec cet identifiant, nous créons une nouvelle ligne dans le user_profile table et une nouvelle ligne dans la table de compte appropriée.

Voici le modèle final :