Database
 sql >> Base de Dados >  >> RDS >> Database

Fazendo login com serviços externos




Inserir um nome de usuário e senha é uma maneira de acessar uma conta, mas não é a única. Neste artigo, veremos como habilitar serviços externos (como Google ou Facebook) ao fazer login em um banco de dados.

O que são logins de serviço externo?


Dar a um usuário a opção de acessar suas contas do sistema por meio de serviços externos é uma tendência crescente entre os web designers. Essa opção pode fornecer vários benefícios, como dar aos usuários uma combinação a menos de nome e senha para lembrar. Também pode ajudar os administradores a personalizar as experiências do usuário.

Quando os aplicativos da Web oferecem um login de serviço externo, a tela de login se parece com a imagem abaixo. Um usuário pode inserir seu login e senha, ou pode clicar em um botão que o redirecionará para o serviço de sua escolha (Facebook, Twitter, Google, etc.) onde fará o login e será redirecionado para o aplicativo original.

Aqui está um exemplo de tela de login da Vertabelo Academy:


Como funcionam os logins externos


Adicionar serviços de login externos requer algum trabalho adicional dos desenvolvedores. Os serviços de mídia social mais populares usam um protocolo chamado OAuth 2.0 . Apenas o Twitter usa um protocolo mais antigo chamado OAuth 1.0 . O protocolo permite a leitura de informações do usuário como nome completo, e-mail, sexo, etc. As informações exatas disponíveis dependem do serviço de mídia social e do que o usuário forneceu. (Por exemplo, é possível ter uma conta do Facebook sem um endereço de e-mail anexado.) Independentemente disso, vamos nos concentrar em como implementar esse sistema no design de um banco de dados.

Como ponto de partida, usaremos nosso artigo anterior sobre recuperação de senha e confirmação por e-mail como base. Aqui estão as tabelas relacionadas ao usuário deste artigo.



Projetando um banco de dados para logins externos


Muitas informações na user_account table está relacionado ao tratamento de autenticação – além de recursos relacionados, como lembrete de senha e confirmação de e-mail – por conta própria. Não precisamos dessas colunas se o usuário se autenticar com um serviço externo. O lembrete de senha, confirmação de e-mail e outros recursos são tratados pelo serviço externo. A primeira etapa do nosso design é separar a user_account table em duas tabelas:user_account e user_profile .



A user_account table agora lida com toda a sua própria contabilidade de autenticação. O user_profile A tabela representa as informações reais do usuário:nome, e-mail, fuso horário, aceitação dos termos de serviço e assim por diante. Todas as tabelas de negócios agora devem estar relacionadas ao user_profile tabela.

Agora para as contas externas. O OAuth protocolo, no final, nos dá um identificador para o usuário em seu sistema. Este identificador não é o nome do usuário no sistema externo. É apenas um identificador para nossa aplicação. Temos que armazenar esse id interno em nosso banco de dados. Poderíamos adicionar colunas anuláveis ​​facebook_id , google_id , twitter_id , etc. para a tabela user_profile . Mas faremos algo diferente.

Adicionaremos novas tabelas:facebook_account , twitter_account , google_account , que armazenará o id externo. Dessa forma, se precisarmos, podemos adicionar informações adicionais especificamente para cada site social. Se quisermos adicionar uma possibilidade de login para outro site social, não precisaremos alterar o user_profile tabela. Só adicionaremos outra external_service_account tabela.



Cada uma das novas tabelas compartilha o mesmo formato de coluna. Um deles será int user_profile_id , que é uma chave estrangeira que faz referência à coluna id no user_profile tabela e a chave primária. (Isso pode servir como chave primária porque duas contas em nosso sistema não devem ser associadas a várias contas do mesmo serviço externo.)

A outra coluna será o id da conta externa – facebook_id , por exemplo. Há uma restrição exclusiva em cada um dos facebook_id , google_id e twitter_id colunas. Sabemos que duas contas não recebem o mesmo ID. Na verdade, quando o usuário é autenticado com um serviço externo, conhecemos seu facebook_id . Quando encontramos a linha correspondente na facebook_account tabela e encontre o user_profile , sabemos qual usuário acabou de fazer login no sistema. Se não houver nenhuma linha com este id, criamos uma nova linha no user_profile tabela e uma nova linha na tabela de contas apropriada.

Aqui está o modelo final: