‫Instrutor: Portanto, temos nosso modelo de
‫usuário configurado pronto para salvar usuários com senhas seguras.
‫E a seguir, vamos realmente
‫implementar a autenticação e autorização do usuário.
‫Portanto, em termos simples, todo o fluxo
‫de trabalho de usuários que efetuam
‫login e permitem que eles interajam com determinados recursos
‫protegidos que usuários não conectados não podem acessar.
‫Agora, existem muitos métodos de autenticação por
‫aí, mas o que vamos usar é uma
‫abordagem muito moderna, simples e segura chamada Json Web Tokens ou JWT.
‫Portanto, os Json Web Tokens são uma solução sem
‫estado para autenticação.
‫Portanto, não há necessidade de armazenar nenhum estado de sessão
‫no servidor, o que é perfeito para APIs tranquilas como a
‫que estamos construindo.
‫Porque lembre-se, APIs restful devem sempre ser sem estado.
‫E a alternativa mais amplamente usada para autenticação
‫com JWTs é apenas armazenar o estado de login do
‫usuário no servidor usando sessões.
‫Mas é claro que não segue o
‫princípio que diz que APIs restful devem ser sem estado e
‫é por isso que estamos optando por uma solução como JWTs.
‫Portanto, agora vamos dar uma olhada em como a
‫autenticação realmente funciona com Json Web Tokens.
‫E supondo que já tenhamos um usuário registrado em
‫nosso banco de dados, é assim que um usuário faz login no aplicativo.
‫Assim, o cliente do usuário começa fazendo uma solicitação de
‫postagem com o nome de usuário ou e-mail e a senha.
‫O aplicativo verifica se o usuário existe e
‫se a senha está correta.
‫E, se for o caso, um Json Web Token
‫exclusivo para apenas aquele usuário é criado usando uma string secreta
‫que é armazenada em um servidor.
‫E um JWT em si é apenas uma string
‫que se parece com isso.
‫Mas falaremos mais sobre o próprio JWT
‫no próximo slide.
‫De qualquer forma, o servidor então envia aquele JWT de volta para o cliente
‫que irá armazená-lo em um cookie ou no armazenamento local.
‫E assim o usuário é autenticado
‫e basicamente logado em nosso
‫aplicativo sem deixar nenhum estado no servidor.
‫Portanto, o servidor de fato não sabe quais usuários
‫estão realmente logados.
‫Mas é claro, o usuário sabe que
‫está conectado porque tem um Json Web Token válido, que é
‫um pouco como um passaporte para acessar partes protegidas do aplicativo.
‫Então, novamente, só para ter certeza de que você entendeu a ideia.
‫Um usuário é conectado assim que recebe de volta
‫seu Json Web Token válido e exclusivo, que não está salvo em nenhum
‫lugar do servidor.
‫E, portanto, esse processo é completamente sem estado.
‫Então, cada vez que um usuário deseja acessar uma rota protegida, como seus
‫dados de perfil de usuário, por exemplo,
‫ele envia seu Json Web Token junto com uma solicitação.
‫Então é um pouco como mostrar o passaporte para ter
‫acesso a essa rota, certo?
‫E essa é provavelmente a maneira melhor e mais fácil de
‫entender toda essa ideia.
‫Agora, quando a solicitação chegar ao
‫servidor, nosso aplicativo verificará se o Json Web Token
‫é realmente válido.
‫Portanto, se o usuário for realmente quem diz ser.
‫E mais sobre como essa etapa funciona
‫um pouco mais adiante neste vídeo.
‫Agora, se o token for realmente válido,
‫bem, os dados solicitados serão enviados ao cliente e,
‫se não, ocorrerá um erro informando ao usuário
‫que ele não tem permissão para acessar esse recurso.
‫E enquanto o usuário estiver logado,
‫é assim que funcionará cada vez que ele solicitar dados
‫de qualquer rota protegida.
‫Agora, o que é muito
‫importante notar aqui é que toda essa comunicação deve acontecer por https.
‫O http criptografado é seguro para evitar que
‫qualquer pessoa tenha acesso a senhas ou Json Web Tokens.
‫Só então teremos um sistema realmente seguro.
‫Mas falaremos sobre isso mais tarde na seção, ok.
‫Portanto, eu sei que isso pode parecer muito
‫confuso no início, quando
‫você tenta entender isso pela primeira
‫vez, mas na verdade o princípio em si é bastante simples, certo?
‫E isso é realmente tudo
‫que você precisa saber para implementar a autenticação usando JWT.
‫Mas agora vamos mergulhar um pouco
‫mais fundo em como o próprio JWT realmente funciona.
‫Portanto, um Json Web Token parece a parte esquerda desta captura de tela, que
‫foi tirada do depurador JWT em jwt. Io.
‫Então, essencialmente, é uma string de codificação
‫composta de três partes.
‫O cabeçalho, a carga útil e a assinatura.
‫Agora, o cabeçalho é apenas alguns metadados sobre o próprio token
‫e a carga útil são os dados
‫que podemos codificar no token, quaisquer dados realmente que desejarmos.
‫Portanto, quanto mais dados quisermos codificar
‫aqui, maior será o JWT.
‫De qualquer forma, essas duas partes são
‫apenas texto simples que serão codificados, mas não criptografados.
‫Assim, qualquer pessoa poderá decodificá-los e lê-los.
‫Portanto, não podemos armazenar dados confidenciais aqui.
‫Mas isso não é
‫um problema porque na terceira parte, então na assinatura,
‫é onde as coisas realmente ficam interessantes.
‫A assinatura é criada usando o cabeçalho, a carga útil
‫e o segredo que é salvo no servidor.
‫Lembre-se disso?
‫E todo esse processo é
‫então chamado de assinatura do Json Web Token.
‫Portanto, novamente, o algoritmo de assinatura usa o
‫cabeçalho, a carga útil e o segredo para criar uma assinatura exclusiva.
‫Portanto, apenas esses dados mais
‫o segredo podem criar essa assinatura, certo?
‫Então, junto com o cabeçalho e a
‫carga útil, essas assinaturas formam o JWT,
‫que é enviado ao cliente.
‫Agora, como mencionei brevemente, logo no primeiro slide,
‫uma vez que o servidor recebe um JWT para conceder
‫acesso a uma rota protegida, ele precisa verificá-lo
‫para determinar se o usuário realmente
‫é quem diz ser, certo?
‫Em outras palavras, ele verificará se ninguém alterou o cabeçalho
‫e os dados de carga do token.
‫Portanto, novamente, esta etapa de verificação verificará se
‫nenhum terceiro realmente alterou o cabeçalho ou
‫a carga do Json Web Token.
‫Então, como essa verificação realmente funciona?
‫Bem, na verdade, é bastante simples.
‫Assim, assim que o JWT for recebido, a
‫verificação pegará seu cabeçalho e sua carga útil e,
‫junto com o segredo que ainda
‫está salvo no servidor, basicamente criará uma assinatura de teste.
‫Mas a assinatura original gerada quando
‫o JWT foi criado pela primeira vez ainda está no token, certo?
‫E essa é a chave para essa verificação.
‫Porque agora tudo o que temos a
‫fazer é comparar a assinatura de teste com a assinatura original.
‫E se a assinatura de teste
‫for igual à assinatura original, isso significa que a
‫carga útil e o cabeçalho não foram modificados, certo?
‫Porque se eles tivessem sido
‫modificados, a assinatura de teste teria que ser diferente.
‫Portanto, neste caso em que não
‫houve alteração dos dados, podemos então autenticar o usuário.
‫E, claro, se as
‫duas assinaturas forem realmente diferentes, bem, isso
‫significa que alguém adulterou os dados.
‫Normalmente, tentando alterar a carga útil.
‫Mas esse terceiro que está manipulando a carga
‫útil, é claro, não tem acesso ao segredo, portanto,
‫eles não podem assinar o JWT.
‫Portanto, a assinatura original nunca corresponderá
‫aos dados manipulados.
‫E, portanto, a verificação sempre falhará
‫neste caso.
‫E essa é a chave para fazer todo o sistema funcionar.
‫É a magia que torna o JWT tão
‫simples, mas também extremamente poderoso.
‫Então, deixe-me resumir novamente.
‫Sem o segredo, ninguém será capaz de manipular os
‫dados JWT porque eles não podem criar uma
‫assinatura válida para os novos dados.
‫Quer dizer, eles poderiam manipular os dados,
‫é claro, mas sempre falhará na etapa de verificação.
‫Agora, não se preocupe, não vamos
‫implementar esses algoritmos JWT sozinhos.
‫Eles são muito complexos e
‫não vamos reinventar a roda aqui, certo?
‫Mas ainda é muito importante entender como todo
‫esse processo funciona nos bastidores.
‫E espero que esta palestra tenha feito exatamente isso para você.
‫Mas agora, vamos passar para a próxima aula para
‫realmente começar a usar tudo isso.