[MÚSICA]
Nas lições anteriores,
vimos vários tipos diferentes de esquemas de autenticação.
Começamos com a autenticação básica, depois analisamos como podemos usar cookies para
fazer autenticação e até mesmo cookies assinados e,
posteriormente, analisamos a autenticação baseada em sessão.
Onde o servidor está mantendo o controle de informações sobre cada cliente e,
em seguida, o cookie será usado como uma forma de indexação no
banco de dados do lado do servidor para extrair informações adicionais, para validar o usuário.
Agora, o cookie e autenticações baseadas em sessão não são escaláveis,
porque há servidor precisa manter o controle de todos os usuários diferentes.
Mesmo assim, isso é feito fora do próprio protocolo HTTP, mas
ainda assim o fato de que você precisa manter o controle
de todas as informações da seção do site do servidor, torna não muito escalável.
Então é aqui que a autenticação baseada em tokens
provou ser muito útil.
vamos olhar para autenticação de base de tokens um pouco mais detalhado nesta palestra e
exercício que se segue.
Novamente, revisando rapidamente os cookies e a autenticação baseada em sessão.
Com a autenticação baseada em cookies,
percebemos que os cookies são armazenados no lado do cliente, e os cookies são incluídos
em todas as mensagens de solicitação de saída em que, o servidor é lembrado sobre
esse cliente específico, extraindo informações do cookie.
Cookie pode ser usado em conjunto com sessões, em que os cookies armazenam o ID da sessão
e, em seguida, quando o servidor recebe a solicitação de entrada do cookie,
ele extrai o ID da sessão e usa isso como um índice no
armazenamento de sessão do lado do servidor para recuperar as informações da sessão para o cliente específico.
Agora, essa abordagem, como eu disse,
não é muito escalável porque se você tiver milhares de sessões, o servidor precisa
acompanhar todos esses milhares de sessões no lado do servidor.
Mesmo que seja feito independente de HTTP em um armazenamento, um armazenamento
de arquivos ou um banco de dados.
Mas ainda assim,
o fato de que você precisa rastrear todas essas informações torna não escalável.
Então, novamente, para lembrá-lo mais uma vez,
por que falamos sobre autenticação baseada em tokens?
A autenticação baseada em sessão, como vimos anteriormente, funciona perfeitamente bem para
aplicativos da web e pode facilmente cuidar da autenticação do usuário.
Mas, em seguida, a autenticação baseada em sessão, embora seja o princípio dos
servidores sem estado e também leva a problemas de escalabilidade.
A segunda questão é, os aplicativos móveis não
manipulam autenticações baseadas em sessão muito bem.
Da mesma forma, os aplicativos móveis têm dificuldade em lidar com cookies.
Então, em tais circunstâncias em que seu servidor está servindo dados
tanto para um aplicativo web quanto para um aplicativo móvel.
Em seguida, a autenticação baseada em sessão não será muito útil, e
é aí que a autenticação baseada em token se torna muito mais fácil de usar.
Em uma autenticação baseada em token como o nome no lugar,
o servidor emitirá um token para um usuário validado, e todas as
solicitações subsequentes provenientes do lado do cliente, terão o token na própria solicitação.
Seja na forma de um cabeçalho de solicitação ou no corpo da mensagem de solicitação.
Além disso, a autenticação baseada em tokens também nos ajuda a
lidar com o que são chamados de problemas CORS ou CSRF.
Problemas de compartilhamento de recursos de origem cruzada e assim por
diante, falarei brevemente sobre o custo no próximo módulo.
Mas, no momento, a autenticação baseada em tokens aborda alguns
dos problemas que estão com carros e problemas relacionados à falsificação de solicitações entre sites.
Não só isso, a autenticação baseada em tokens é muito mais fácil para
um aplicativo compartilhar sua autenticação com outro aplicativo.
Claro, tudo isso é feito de forma segura.
Mas, com autenticação baseada em sessão, isso não é direto.
Como funciona a autenticação baseada em tokens?
Na autenticação baseada em tokens,
o usuário primeiro precisa validar a si mesmo no lado do servidor.
Agora, esta validação pode assumir as formas que vimos anteriormente.
Então, podemos usar uma validação local usando nome de usuário e senha.
Ou, podemos até usar validação de terceiros usando
tecnologias como, oauth ou oauth 2.0 ou open ID.
Vamos falar brevemente sobre oauth e oauth 2.0 no próximo módulo.
Mas, independentemente da forma como o usuário autentica, uma vez que o usuário
é autenticado, logo a seguir, seu servidor pode simplesmente emitir um token para o usuário.
E toda a comunicação subsequente entre o usuário e
o servidor, pode ser feita simplesmente usando este token.
JSON Web Token que vamos falar, é um
esquema de autenticação baseado em token, e há servidor quando ele cria este token, ele irá criar um token assinado.
Usando um segredo no site do servidor que só o servidor sabe.
Assim, mesmo que um terceiro em direção e entre e
tente manipular o token, mesmo que ele capture o token e
tente manipular o token, o token se tornará inválido.
E assim, essa maneira de proteger o usuário é
facilmente viável, todas as solicitações subsequentes
do lado do cliente devem levar o token na solicitação
, seja, como eu disse, no cabeçalho ou no corpo da mensagem de solicitação.
Assim, quando o servidor recebe este token, o servidor irá verificar o token,
para garantir que este é um token válido, e, em seguida, se for um token válido,
o servidor irá então responder à solicitação de entrada.
Como mencionei, JSON Web Tokens é um esquema de autenticação baseado em tokens.
JSON Web Token, é uma maneira muito simples de codificar
informações em um token, em seguida, passá-lo para o site do cliente.
JSON Web Token é baseado em padrões,
isso é baseado no IETF RFC 7519.
IETF aqui, significa a Força-Tarefa de Engenharia da Internet.
A organização que determina tudo sobre como funciona a internet,
e lida com os protocolos e as políticas, relacionados à internet.
O RFC, significa o documento de padrões,
em termos IETF, RFC significa Solicitação de Comentários.
E cada documento de padrões carrega um número.
7519 neste caso refere-se ao documento,
o documento padrão relacionado ao Token da Web JSON.
O Token Web JSON em si é um token auto-contido, ele carrega todas
as informações dentro de si mesmo, que é necessário para identificar o usuário.
Não só isso, um JSON Web Token pode ser compartilhado entre dois aplicativos.
Assim, por exemplo, um aplicativo quando ele autentica e, em seguida, se apossar de
um JSON Web Token, pode passar esse JSON Web Token para e
nesse aplicativo, que ele está disposto a autorizar a acessar o servidor em seu nome.
Este compartilhamento do token é feito de uma maneira muito segura,
então não se preocupe muito com a segurança lá dentro.
Isso não é de forma segura,
onde pelo compartilhamento do token entre um aplicativo para outro.
Assim, a autorização é transferida para um segundo aplicativo, e
o segundo aplicativo pode autorizar, em nome do primeiro aplicativo,
a se comunicar com o servidor.
Isso é viável com tokens.
Agora, é claro, o engenheiro em você obviamente estará se perguntando o que exatamente está
dentro de um JSON Web Token, e como ele é útil?
Um JSON Web Token, como eu disse, é codificado em uma string longa e
esta string em si pode ser interpretada como consistindo de três partes.
A string em si pode, ou a string codificada contém três partes,
o cabeçalho, a carga útil e a assinatura.
Isso traz informações suficientes sobre como esse token é codificado.
O cabeçalho em si contém o algoritmo específico que é usado para
codificar este Token da Web JSON e o tipo do próprio token.
O algoritmo neste caso, seria HS256 que é um esquema de codificação de 256 bits,
que é usado para hash as informações dentro do token.
E neste caso, este é o Token da Web JSON e, portanto,
o campo de tipo será definido como JWT.
E então essa é a informação que é armazenada no cabeçalho do JSON Web Token.
A carga útil em si, transporta informações que ajudam você a identificar o usuário.
No exercício que faremos,
a carga horária só carrega o ID do usuário dentro da carga útil.
Nenhuma outra informação é necessária.
Esse ID pode ser usado no lado do servidor,
para indexar no banco de dados Mongo para recuperar as informações completas do usuário, se necessário.
Então, você verá que vamos codificar o ID e
, em seguida, armazená-lo na carga dessa mensagem.
Você pode armazenar informações adicionais na carga útil da mensagem, se necessário.
Mas quanto mais informações você armazenou lá,
maior o JSON Web Token correspondente vai para mim.
Então, tente limitar a quantidade de informações que você armazenou na carga
do token da Web JSON.
Como veremos no exercício, temos um módulo de nó que nos permite
codificar e criar um JSON Web Token,
com base nas informações que queremos colocar na carga útil.
Agora, quando você cria um JSON Web Token, você também fornece uma assinatura.
Uma chave secreta no lado do servidor que é usada para codificar este JSON Web Token,
e esse segredo também está incluído na parte de assinatura do JSON Web Token.
A assinatura em si é incluída de tal forma que
há um básico antes codificado cabeçalho e payload,
que é então codificado usando o segredo específico que é usado pelo servidor.
E isso codificado em, como eu disse o HMAC,
que nos referimos em uma das lições anteriores e
usando o 256 bit hashing, e que está incluído na assinatura.
Então, quando este JSON Web Token é recebido no lado do servidor, e
quando o servidor decodifica esse token, então o servidor é capaz de cruzar a verificação para
se certificar de que este JSON Web Token não foi adulterado por ninguém,
enquanto o token está sendo passado entre o cliente e o site do servidor.
Então, se você sabe alguma coisa sobre segurança, intrusos,
e assim por diante, você entende por que é importante codificar o token e
verificar a autenticidade do token no site do servidor.
Como mencionei, se você precisa lidar com JSON Web Tokens em seu aplicativo de nó.
Há um módulo de nó específico chamado como o módulo de nó jsonwebtoken.
Este módulo de nó implementa os padrões relacionados ao Token da Web JSON e
pode ser incluído em seu aplicativo de nó.
Este módulo em si, fornece um método chamado sinal que permite que você assine e
emitir o token para o cliente a partir do lado do servidor.
Ele também contém um método de verificação.
Que pode ser usado para verificar a autenticidade ou
para garantir a autenticidade do token da Web JSON de entrada,
então estaremos fazendo uso do módulo de token da Web JSON, em nosso exercício.
Juntamente com o módulo JSON Web Token,
também usamos o módulo Passport-JWT, módulo de nó.
Que fornece as estratégias baseadas em jwt para o nosso módulo de autenticação de passaporte.
Então, isso fornece uma estratégia de passaporte para autenticação usando JSON Web Token.
Então, isso permite que você autentique endpoint RESTful usando o JWT como o método para
dong a validação, sem exigir que o servidor use sessões.
Agora, o módulo de passaporte JWT,
suporta um método de até mesmo extrair o token JWT
da mensagem de solicitação de entrada e, em seguida, até mesmo verificar o token em seu nome.
O estagiário do módulo Passport-JWT usa o módulo JSON Web Token para
fazer a verificação desse JSON Web Token.
O token em si pode ser carregado no cabeçalho da solicitação de entrada,
no cabeçalho, mesmo no cabeçalho de autenticação da solicitação de entrada,
que é o que estaremos fazendo no exercício.
O token também pode ser transportado no corpo da solicitação de entrada, caso em que,
temos que extrair o token do corpo da solicitação de entrada e
, em seguida, fazer uso dele.
O módulo Passport-JWT, suporta isso também se você optar por
usar isso como forma de passar o token de volta do cliente para o site do servidor.
O JSON Web Token, também pode ser incluído nos parâmetros de consulta URL se você assim
escolher, e pode ser extraído de lá b Passport-JWT e
usado para autenticação.
Agora, com este rápido entendimento de JSON Web Tokens e
como eles são úteis, vamos passar para o exercício onde vamos usar
o módulo Passport-JWT, juntamente com o módulo JSON Web Token,
e configurar nosso servidor de API Express Rest para usar JSON Web Tokens.
[ MUSIC]