Tenho certeza que você tem uma ou mais contas de mídia social.
Seja Facebook, Twitter, YouTube, Google, GitHub,
ou muitos outros provedores de serviços, onde você registrou telefone e conta.
Agora, esses provedores de serviços, por sua vez,
estão dispostos a fornecer serviços de autenticação em seu nome.
Assim, por exemplo, você vê a proliferação de uma série de sites
e aplicativos móveis onde você tem permissão para fazer login
usando suas contas de mídia social.
Agora, como isso realmente funciona?
Muitos desses provedores de conta de mídia social atuam
como provedores de serviços de autenticação usando um protocolo chamado como OAuth.
Analisaremos o OAuth e como ele permite que esses provedores de autenticação terceirizados
forneçam autenticação em seu nome
e permitem que você faça login em outros serviços usando suas contas de mídia social.
Tenho certeza que você pode ter ouvido falar sobre OAuth 1 e OAuth 2,
e pode ter ouvido pessoas dizendo
que o Facebook fornece autenticação baseada em OAuth 2,
ou Google fornece autenticação baseada em OAuth 2 e assim por diante.
Tenho certeza que você deve estar se perguntando,
o que exatamente esses OAuth1 e OAuth 2 devem ser?
Agora, OAuth1 e OAuth 2 são estruturas de autorização
baseadas em padrões abertos.
E eles podem ser usados pela Internet para autenticar
sua identidade em muitos sites ou aplicativos móveis.
Agora, quando você usa esses serviços,
você está dependendo de uma das contas de mídia social, como Facebook,
Google, Twitter, Microsoft, Instagram,
GitHub, DigitalOcean e muitos mais,
que fornecem esses serviços de autenticação para outros fazerem uso.
Esses provedores de serviços
de autenticação prometem aos usuários desse serviço de autenticação que eles autenticarão a identidade
do usuário com base em seu envio de
suas credenciais para esses serviços de mídia social.
Agora, há um serviço complementar OpenID.
Mas, é claro, não relacionado ao OAuth, mas fornece tipo semelhante de serviço.
Mas a maioria dos provedores de serviços de mídia social padrão,
como você verá listado aqui,
fornece serviços baseados no OAuth 2 atualmente.
Agora, como mencionei, OAuth1 e OAuth 2 são protocolos de autenticação,
e OAuth 1 foi o primeiro protocolo que surgiu.
Isso foi evoluído a partir do Twitter,
Blaine Cook sendo a pessoa por trás dele,
e isso está documentado na Internet Engineering Task Force, RFC 5849.
Então, se você quiser ler os detalhes sangrentos de como esses protocolos funcionam,
esse é o lugar para encontrar isso. O
protocolo OAuth 2 evoluiu de OAuth 1 para torná-lo mais simples
e para fornecer uma maneira mais simples para o desenvolvimento do cliente.
E isso é documentado no IETF RFC 6749 e, posteriormente,
outro uso de token portador surgiu no IETF RFC 6750.
Agora, do nosso ponto de vista,
nós realmente não queremos entrar em detalhes de como esses protocolos realmente funcionam.
Em vez disso, tudo o que estamos interessados em que é,
como aproveitá-los para autenticação de usuário dentro de
nosso aplicativo web, ou dentro de nosso aplicativo móvel,
quando precisamos autenticar o usuário para
o servidor Express que temos vindo a construir até agora?
Agora, vamos nos concentrar principalmente no OAuth 2,
porque no exercício,
vamos olhar para o uso do Facebook como um provedor de serviços de autenticação OAuth 2
, e aqui, precisamos entender
alguns termos para ver como exatamente esse protocolo OAuth 2 funciona.
Pelo menos, os detalhes de como o próprio protocolo funciona.
Agora, no caso de OAuth 2,
sempre falamos sobre a propriedade de um recurso.
Agora, nesse caso,
o recurso ao qual estou me referindo não
é o recurso armazenado no servidor Express.
Em vez disso, o recurso a que estamos nos referindo aqui,
é a identidade do usuário.
Agora, qualquer servidor, como o servidor Express que temos vindo a construir,
quer ter acesso a este recurso,
que é a sua identidade.
Agora, onde está a sua identidade?
Sua identidade é armazenada em um
desses provedores de serviços de autenticação de mídia social, como o Facebook e assim por diante,
porque você já criou uma conta nesses sites de mídia social.
Assim, suas informações ou suas informações de identidade ou
suas informações de perfil são armazenadas no Facebook, por exemplo.
Agora, seu servidor Express deseja obter acesso à sua identidade e
verificar se é realmente você que está tentando acessar o servidor Express.
Então, neste caso,
o servidor Express que desenvolvemos,
atua como o aplicativo cliente.
Então, é aqui que o aplicativo cliente,
que é o site ou o aplicativo móvel que
deseja acessar o servidor de recursos para obter as informações sobre você.
O que é um servidor de recursos que estamos falando?
Este é o servidor de autenticação OAuth do Facebook,
que também fornece suas informações de perfil mediante solicitação.
Agora, é claro, você não vai continuar distribuindo suas informações de perfil aleatoriamente.
Em vez disso, você deseja ser capaz de verificar se você está fornecendo acesso às
informações do seu perfil para um provedor de serviços autenticado ou um servidor autenticado.
Agora, é aqui que seu aplicativo cliente ou o servidor Express aqui,
por exemplo, vai se registrar no Facebook com uma conta dizendo que eu estou operando um aplicativo,
e eu quero me registrar como uma fonte potencial que pode se
aproximar de você para autenticar usuários quando eles fornecem
acesso a seu perfil que está armazenado em seu site.
Assim, o servidor Express,
neste caso, atuando como o aplicativo cliente,
irá se registrar no Facebook e obter um ClientID e um segredo de cliente do Facebook.
Agora, quando o servidor Express se registrar no Facebook,
você precisa ter uma conta no Facebook,
uma conta autenticada no Facebook,
que você usará para configurar este aplicativo no Facebook.
Então, uma vez que você se registrar,
então você terá acesso a um ClientID e a um segredo de cliente.
Agora, o servidor de recursos,
como eu mencionei, é o servidor que está hospedando os dados protegidos.
Dados protegidos que significam o perfil do usuário que deseja acessar o servidor Express.
Então, o servidor Express deseja acessar esse servidor de recursos
e obter os dados de perfil do usuário que deseja acessar o servidor Express.
Então, você vê o relacionamento aqui.
Então, quando eu falo sobre um aplicativo cliente,
eu não me refiro a sua aplicação front-end,
mas seu servidor Express que está tentando fornecer
acesso a recursos que ele tem em seu site.
Mas o servidor Express,
a fim de permitir que você acesse,
precisará acessar seu servidor de recursos do Facebook, que
irá autenticá-lo e fornecer suas informações de perfil para o servidor Express.
Então, o servidor de recursos que estou falando aqui,
é o servidor de autenticação OAuth 2 do Facebook
mais o servidor de recursos que lhe dá acesso às informações de perfil do usuário.
E o servidor de autorização é o servidor que
autorizará alguém a acessar
o servidor de recursos para recuperar as informações do perfil.
Agora, o usuário é aquele que tem as informações de perfil no servidor de recursos.
O usuário deve autorizar o servidor Express a ir
para este servidor de recursos para buscar as informações do perfil.
Mas se o usuário precisa autorizar o servidor Express,
o usuário precisa fazer login na conta do Facebook
e, em seguida, obter informações do Facebook chamado como um token de acesso,
que o usuário então passará para o servidor Express.
Agora, quando o token de acesso é obtido do Facebook através do protocolo OAuth 2,
o token de acesso será emitido em termos
de permitir este aplicativo cliente ou o servidor Express,
que já está registrado no Facebook dizendo que
este servidor cliente eu autorizarei a
acessar suas informações de perfil de seu provedor de serviços OAuth do Facebook.
Então, novamente, isso é um pouco confuso.
Veremos um diagrama onde esse fluxo de
informações é explicado um pouco mais claramente para você.
Um ponto que acabei de mencionar é sobre um token OAuth ou o token de acesso.
O que é esse token de acesso?
O token de acesso é algo que o servidor de autorização emite para você.
Qual servidor de autorização?
Este é o servidor de autorização OAuth 2 de terceiros,
servidor do Facebook, neste exemplo.
Então eles são aplicativos de servidor Express.
Agora, você, como seu usuário front-end,
quer acessar algo do aplicativo Express Server.
O aplicativo de servidor Express irá dizer-lhe que você
autenticar-se do Facebook e, em seguida, obter token de acesso do Facebook.
Este token de acesso é emitido para
o usuário front-end do Facebook quando o usuário faz login em sua conta do Facebook.
Agora, este token de acesso é emitido em nome do aplicativo cliente, o
servidor Express, que já se registrou no Facebook.
Assim, para que o usuário acesse o Facebook para obter seu token de acesso,
o usuário requer o ID do cliente do aplicativo cliente ou do aplicativo Express.
Portanto, esse ID de cliente é incorporado
no aplicativo front-end que este servidor Express servirá para você.
Então, o servidor Express está servindo um site que você está acessando,
então esse site irá conter código onde
o ID do cliente desse servidor Express já está incorporado lá.
Mais uma informação que mencionei é um segredo de cliente.
Agora, no fluxo de autenticação que vou falar,
o segredo do cliente nunca será revelado a ninguém.
O segredo do cliente será apenas no lado do servidor Express.
Quando o servidor Express tenta autenticar e
obter acesso ao perfil do usuário do Facebook,
o aplicativo cliente, o servidor Express
enviará o ID do cliente e o segredo do cliente,
juntamente com o token de acesso que o usuário fornece para o Facebook.
E o Facebook, por sua vez,
autoriza seu aplicativo cliente a acessar
o servidor de recursos para obter os dados do perfil do usuário.
E uma vez que os dados do perfil do usuário são obtidos do servidor de recursos do Facebook,
então meu servidor Express vai criar uma conta
para esse usuário específico que os registrou com sua conta do Facebook.
E, posteriormente, forneça um token da Web JSON
ao usuário, que o usuário pode usar para acessar
os recursos armazenados no servidor Express.
Então, novamente, para resumir isso,
eu tenho um diagrama aqui para explicar isso para vocês em um pouco mais de detalhes.
Além disso,
há também um token de atualização.
Quando um token de acesso é emitido pelo servidor OAuth 2 do Facebook,
o token de acesso tem uma vida útil limitada.
Depois disso, o token de acesso se tornará inválido.
Então o token de acesso tem que ser mantido confidencial.
Então, toda essa troca de tokens entre os diferentes sites
será feita em uma matéria criptografada usando o protocolo HTTPS.
Portanto, certifique-se de que quando você estiver enviando seu token de acesso de
seu aplicativo front-end de usuário para o servidor Express,
você só enviará o token de acesso por HTTPS, não HTTP.
Isso é muito importante porque você não
quer que seu token de acesso seja revelado a ninguém, porque qualquer pessoa
que pode obter um de seu token de acesso pode fingir ser
seu aplicativo cliente e, em seguida, obter acesso ao seu perfil de usuário.
Portanto, isso é muito importante.
Agora, como o token de acesso tem uma vida útil limitada,
há também um token de atualização correspondente,
que pode ser usado para atualizar um token de acesso expirado.
Agora, no tipo de fluxo que vamos
usar com nosso aplicativo no exercício,
não seremos capazes de usar o token de atualização.
Sempre que o usuário quiser autorizar
o servidor Express para ir buscar as informações do perfil do Facebook,
o usuário terá
que fornecer explicitamente um novo token de acesso obtido do Facebook.
A única parte que acabei de mencionar brevemente,
mas não elaborei,
é como o aplicativo cliente, o servidor Express,
as escalas, como ele se registra no provedor de serviços OAuth 2?
Agora, é aqui que muitos dos provedores de serviços OAuth 2
fornecem uma maneira de registrar um aplicativo em seu site.
Assim, um aplicativo cliente,
os servidores Express em nosso exemplo,
irá se registrar como um aplicativo cliente no provedor de serviços OAuth.
Então, como você verá no exercício,
o primeiro passo que faremos é entrar no Facebook com
nossa conta e, em seguida, criar um aplicativo no site do Facebook.
Quando você fizer isso, o Facebook emitirá um ID de aplicativo cliente e um segredo de cliente.
Esse procedimento se aplica a muitos outros provedores de serviços OAuth porque
esse é o fluxo geral que o protocolo OAuth 2 fala sobre.
Assim, o ID do aplicativo cliente e o segredo do cliente são úteis para que possamos
provar nossa identidade para
o servidor OAuth quando estamos passando um token de acesso que obtemos do usuário.
Agora, há também um URL de redirecionamento que você precisa
registrar quando você está registrando o aplicativo cliente,
e você vai me ver realizando isso nas etapas que eu registrar
o aplicativo no site do Facebook.
Agora, para resumir o fluxo de informações sobre o
qual acabamos de falar brevemente no caso anterior,
deixe-me começar neste ponto.
O primeiro ponto a observar é o proprietário do recurso.
Então, o proprietário do recurso aqui
é o usuário que vai usar sua conta de mídia social.
O Facebook, neste exemplo,
tem a autenticação para o usuário.
Portanto, o proprietário do recurso é aquele que tem o perfil sobre o recurso.
E essas informações de perfil para cada conta do Facebook,
elas foram armazenadas no servidor do Facebook.
E assim o servidor do Facebook fornece o servidor de recursos aqui.
Então esse é o provedor de serviços OAuth que você vê
no lado direito desta imagem aqui.
Então imagine o servidor do Facebook no lado direito, esse aplicativo cliente,
que tem o servidor de API restante,
o servidor Express que implementamos,
é um aplicativo cliente neste caso,
e o proprietário do recurso é o usuário.
URL usuário front-end, que vai
autorizar você a ir para o Facebook para verificar a credencial do usuário.
Então, quando você quiser acessar informações no lado do cliente,
você terá que primeiro ir e
autorizar este aplicativo cliente para ser capaz de
obter acesso a suas informações de perfil.
Assim, o aplicativo cliente,
se ele está atuando como um aplicativo web,
ele irá fornecer um botão apropriado lá dizendo login usando Facebook.
E assim, quando você clica no botão,
essencialmente, o primeiro passo é iniciado.
A solicitação de autorização do usuário é iniciada.
Então seu aplicativo cliente,
através do agente do usuário,
o agente do usuário é basicamente o aplicativo cliente, o aplicativo front-end.
Pode ser o aplicativo Angular que desenvolvemos ou aquele aplicativo móvel,
seja Ionic ou se é
um aplicativo NativeScript que desenvolvemos nos cursos mais cedo
na especialização ou até mesmo um aplicativo nativo como um aplicativo iOS ou um aplicativo Android.
Todos eles atuam como o agente do usuário.
Então, o agente do usuário,
eles usam um processo de solicitação de autorização através
do agente do usuário para o servidor de autorização,
que é o servidor do Facebook.
Agora, quando isso for passado,
então o proprietário do recurso ou o usuário,
que está tentando dar acesso ao seu perfil para este aplicativo cliente,
terá que autorizar o Facebook
para poder compartilhar essas informações com o aplicativo cliente.
Na abordagem de concessão de fluxo implícito que estamos usando em
nosso exemplo aqui e também no exercício que se segue,
a abordagem de concessão de fluxo implícito é
a abordagem mais adequada quando você está implementando um aplicativo web usando
um framework como Angular ou o aplicativo móvel híbrido
com Ionic ou um NativeScript ou até mesmo um aplicativo nativo.
A abordagem de concessão de fluxo implícito é muito mais simples maneira de
operar o OAuth 2 para esse tipo de aplicações.
Então, o proprietário do recurso clica no botão de login,
então o servidor de autorização solicitará ao proprietário do recurso as informações dizendo:
“Este aplicativo cliente deseja acessar suas informações de perfil.
Você autoriza?”
E então isso será exibido pelo Facebook,
e então você clicará em um botão dizendo: “
Sim, autorizo este aplicativo cliente a acessar em meu nome.”
Então, nesse ponto,
o servidor de autorização no Facebook,
o servidor de autorização OAuth 2 no Facebook,
gerará um token de acesso.
Para gerar esse token de acesso,
ele fará uso do ID do cliente para este aplicativo cliente,
o aplicativo de servidor Express que registramos.
Portanto, o ID do cliente deve ser parte do agente de usuário que este usuário usa.
Portanto, este ID de cliente será incorporado no aplicativo Angular,
o Ionic ou o aplicativo NativeScript ou até mesmo um iOS ou um aplicativo Android.
Então, o ID do cliente será usado pelo
agente do usuário para transformar o servidor de autorização dizendo:
“Este aplicativo de cliente quer acesso ao meu perfil,
e estou disposto a autorizá-lo a permitir o acesso ao perfil.”
Então, nesse ponto,
o servidor de autorização enviará um token de acesso para o agente do usuário neste caso.
Então, lembre-se, este token de acesso entra no agente do usuário,
que é o aplicativo móvel ou seu aplicativo Angular que é implementado por nós.
Em seguida, este agente de usuário tomará este token de acesso e
, em seguida, passar este token de acesso para esse aplicativo cliente.
Portanto, o OAuth para fazer login,
mas o token de acesso será passado para o aplicativo cliente,
o servidor Express neste caso,
em uma rota específica no roteador do usuário,
a rota de autenticação no site do aplicativo cliente.
Agora, anteriormente, vimos o uso de autenticação local,
onde enviamos uma solicitação para cortar usuário barra login.
Agora, para que isso funcione em nosso aplicativo,
vamos configurar outro em usuários de barra,
barra Facebook, barra token, e assim por diante.
Então, outra URL em que fornecemos este token de acesso ao servidor Express.
Agora, quando esse token de acesso é obtido pelo servidor Express,
o servidor Express tomará esse token de acesso
e, em seguida, juntamente com seu ID de cliente e o segredo do cliente,
ele enviará essas informações para o servidor de autorização.
E o servidor de autorização permitirá que seu aplicativo cliente
acesse o servidor de recursos para obter as informações do perfil.
E assim, as informações do perfil serão enviadas de volta na etapa número seis, de
volta para o aplicativo cliente neste caso.
Assim, quando o aplicativo cliente obtém as informações de perfil para o usuário,
então o aplicativo cliente criará uma nova conta para
o usuário em cada site se uma conta não existir.
Se esse usuário já tiver feito login anteriormente usando seu ID do Facebook,
uma conta já existirá para que o aplicativo cliente e o servidor da API
Rest simplesmente verifiquem se essa conta de usuário já existe.
E, nesse ponto,
o usuário é autenticado para a funcionalidade de login de terceiros
fornecida pelo serviço de autenticação OAuth 2 do Facebook.
Nesse ponto, em seguida, o aplicativo cliente irá gerar um JSON Web Token,
no exemplo que vamos implementar e exercer,
e, em seguida, passar este JSON Web Token de volta para o agente do usuário ou o aplicativo front-end,
ou aplicativo Angular, ou o aplicativo Ionic,
ou o aplicativo NativeScript.
Em seguida, o JSON Web Token será posteriormente usado pelo usuário
para se autenticar sempre que ele ou ela quiser
acessar quaisquer recursos armazenados no servidor Express.
Então, uma vez que você obtém o JSON Web Token,
todas as operações subsequentes, você já viu como fazer isso com JSON Web Token.
Então, uma vez que você obtenha o JSON Web Token,
seu trabalho é feito,
e então você pode prosseguir com a operação normal a partir desse ponto em diante.
Agora, quando o JSON Web Token expira,
então você deve passar por todo o processo de re-autenticação e,
posteriormente, permitir que os usuários acessem informações em seu site.
Então, com essa compreensão rápida de como as operações OAuth 2 funcionam
, novamente, como você vê, há muitos detalhes aqui.
Mas, felizmente, não temos que lidar com todos esses detalhes porque vamos estar
usando um módulo de nó que cuida de muitos desses detalhes em nosso nome.
Uma vez que já configuramos o nosso servidor Express para usar Passport,
agora podemos usar outro código de módulo nó como módulo Passport-Facebook-Token.
O módulo Passport-Facebook-Token implementa essencialmente
a abordagem de concessão implícita que eu falei anteriormente.
E então você pode inicializar
uma nova estratégia em sua estratégia Passport, dentro de sua aplicação.
E para que o módulo Passport-Facebook-Token permita que você configure
uma nova estratégia de autenticação Passport para usar a API OAuth 2 baseada no Facebook.
E assim, para fazer uso deste módulo,
você instala isso dizendo passado npm install passport- facebook-token,
menos menos salvar, e então uma vez que você instalou isso,
então você irá configurar uma estratégia do Facebook dentro do seu aplicativo, e, depois disso,
fazer uso disso para configurar a estratégia para o seu Passport
utilizar se estivermos a utilizar a autenticação baseada em OAuth 2 para a nossa aplicação.
Com esta rápida compreensão de OAuth 2,
vamos passar para o exercício,
onde vamos configurar nosso servidor Express para realmente fazer uso
desta abordagem de concessão implícita para nos permitir
verificar nossa identidade para o servidor Express e,
depois disso, obter acesso aos recursos, pratos,
as promoções e as informações dos líderes armazenadas no nosso servidor Express.