1
00:00:00,930 --> 00:00:03,210
‫Instrutor: Portanto, temos nosso modelo de

2
00:00:03,210 --> 00:00:06,440
‫usuário configurado pronto para salvar usuários com senhas seguras.

3
00:00:06,440 --> 00:00:08,850
‫E a seguir, vamos realmente

4
00:00:08,850 --> 00:00:11,670
‫implementar a autenticação e autorização do usuário.

5
00:00:11,670 --> 00:00:14,230
‫Portanto, em termos simples, todo o fluxo

6
00:00:14,230 --> 00:00:16,530
‫de trabalho de usuários que efetuam

7
00:00:16,530 --> 00:00:19,360
‫login e permitem que eles interajam com determinados recursos

8
00:00:19,360 --> 00:00:22,163
‫protegidos que usuários não conectados não podem acessar.

9
00:00:23,100 --> 00:00:26,050
‫Agora, existem muitos métodos de autenticação por

10
00:00:26,050 --> 00:00:29,360
‫aí, mas o que vamos usar é uma

11
00:00:29,360 --> 00:00:34,360
‫abordagem muito moderna, simples e segura chamada Json Web Tokens ou JWT.

12
00:00:35,170 --> 00:00:38,100
‫Portanto, os Json Web Tokens são uma solução sem

13
00:00:38,100 --> 00:00:39,500
‫estado para autenticação.

14
00:00:39,500 --> 00:00:43,410
‫Portanto, não há necessidade de armazenar nenhum estado de sessão

15
00:00:43,410 --> 00:00:47,360
‫no servidor, o que é perfeito para APIs tranquilas como a

16
00:00:47,360 --> 00:00:48,580
‫que estamos construindo.

17
00:00:48,580 --> 00:00:53,080
‫Porque lembre-se, APIs restful devem sempre ser sem estado.

18
00:00:53,080 --> 00:00:56,300
‫E a alternativa mais amplamente usada para autenticação

19
00:00:56,300 --> 00:01:00,240
‫com JWTs é apenas armazenar o estado de login do

20
00:01:00,240 --> 00:01:02,420
‫usuário no servidor usando sessões.

21
00:01:02,420 --> 00:01:05,150
‫Mas é claro que não segue o

22
00:01:05,150 --> 00:01:08,700
‫princípio que diz que APIs restful devem ser sem estado e

23
00:01:08,700 --> 00:01:12,293
‫é por isso que estamos optando por uma solução como JWTs.

24
00:01:13,130 --> 00:01:15,960
‫Portanto, agora vamos dar uma olhada em como a

25
00:01:15,960 --> 00:01:18,660
‫autenticação realmente funciona com Json Web Tokens.

26
00:01:18,660 --> 00:01:21,600
‫E supondo que já tenhamos um usuário registrado em

27
00:01:21,600 --> 00:01:25,380
‫nosso banco de dados, é assim que um usuário faz login no aplicativo.

28
00:01:25,380 --> 00:01:28,700
‫Assim, o cliente do usuário começa fazendo uma solicitação de

29
00:01:28,700 --> 00:01:32,330
‫postagem com o nome de usuário ou e-mail e a senha.

30
00:01:32,330 --> 00:01:35,400
‫O aplicativo verifica se o usuário existe e

31
00:01:35,400 --> 00:01:37,430
‫se a senha está correta.

32
00:01:37,430 --> 00:01:40,340
‫E, se for o caso, um Json Web Token

33
00:01:40,340 --> 00:01:44,010
‫exclusivo para apenas aquele usuário é criado usando uma string secreta

34
00:01:44,010 --> 00:01:46,290
‫que é armazenada em um servidor.

35
00:01:46,290 --> 00:01:49,410
‫E um JWT em si é apenas uma string

36
00:01:49,410 --> 00:01:51,150
‫que se parece com isso.

37
00:01:51,150 --> 00:01:54,170
‫Mas falaremos mais sobre o próprio JWT

38
00:01:54,170 --> 00:01:55,770
‫no próximo slide.

39
00:01:55,770 --> 00:02:00,440
‫De qualquer forma, o servidor então envia aquele JWT de volta para o cliente

40
00:02:00,440 --> 00:02:04,160
‫que irá armazená-lo em um cookie ou no armazenamento local.

41
00:02:04,160 --> 00:02:06,930
‫E assim o usuário é autenticado

42
00:02:06,930 --> 00:02:09,570
‫e basicamente logado em nosso

43
00:02:09,570 --> 00:02:12,720
‫aplicativo sem deixar nenhum estado no servidor.

44
00:02:12,720 --> 00:02:16,310
‫Portanto, o servidor de fato não sabe quais usuários

45
00:02:16,310 --> 00:02:17,930
‫estão realmente logados.

46
00:02:17,930 --> 00:02:20,960
‫Mas é claro, o usuário sabe que

47
00:02:20,960 --> 00:02:25,040
‫está conectado porque tem um Json Web Token válido, que é

48
00:02:25,040 --> 00:02:29,270
‫um pouco como um passaporte para acessar partes protegidas do aplicativo.

49
00:02:29,270 --> 00:02:32,470
‫Então, novamente, só para ter certeza de que você entendeu a ideia.

50
00:02:32,470 --> 00:02:35,330
‫Um usuário é conectado assim que recebe de volta

51
00:02:35,330 --> 00:02:39,720
‫seu Json Web Token válido e exclusivo, que não está salvo em nenhum

52
00:02:39,720 --> 00:02:41,030
‫lugar do servidor.

53
00:02:41,030 --> 00:02:44,840
‫E, portanto, esse processo é completamente sem estado.

54
00:02:44,840 --> 00:02:49,300
‫Então, cada vez que um usuário deseja acessar uma rota protegida, como seus

55
00:02:49,300 --> 00:02:51,940
‫dados de perfil de usuário, por exemplo,

56
00:02:51,940 --> 00:02:55,360
‫ele envia seu Json Web Token junto com uma solicitação.

57
00:02:55,360 --> 00:02:58,480
‫Então é um pouco como mostrar o passaporte para ter

58
00:02:58,480 --> 00:03:00,450
‫acesso a essa rota, certo?

59
00:03:00,450 --> 00:03:03,870
‫E essa é provavelmente a maneira melhor e mais fácil de

60
00:03:03,870 --> 00:03:05,320
‫entender toda essa ideia.

61
00:03:05,320 --> 00:03:07,910
‫Agora, quando a solicitação chegar ao

62
00:03:07,910 --> 00:03:11,140
‫servidor, nosso aplicativo verificará se o Json Web Token

63
00:03:11,140 --> 00:03:12,580
‫é realmente válido.

64
00:03:12,580 --> 00:03:15,760
‫Portanto, se o usuário for realmente quem diz ser.

65
00:03:15,760 --> 00:03:17,710
‫E mais sobre como essa etapa funciona

66
00:03:17,710 --> 00:03:19,660
‫um pouco mais adiante neste vídeo.

67
00:03:19,660 --> 00:03:22,710
‫Agora, se o token for realmente válido,

68
00:03:22,710 --> 00:03:26,210
‫bem, os dados solicitados serão enviados ao cliente e,

69
00:03:26,210 --> 00:03:29,400
‫se não, ocorrerá um erro informando ao usuário

70
00:03:29,400 --> 00:03:32,600
‫que ele não tem permissão para acessar esse recurso.

71
00:03:32,600 --> 00:03:34,880
‫E enquanto o usuário estiver logado,

72
00:03:34,880 --> 00:03:38,230
‫é assim que funcionará cada vez que ele solicitar dados

73
00:03:38,230 --> 00:03:39,843
‫de qualquer rota protegida.

74
00:03:40,840 --> 00:03:43,000
‫Agora, o que é muito

75
00:03:43,000 --> 00:03:47,570
‫importante notar aqui é que toda essa comunicação deve acontecer por https.

76
00:03:47,570 --> 00:03:51,510
‫O http criptografado é seguro para evitar que

77
00:03:51,510 --> 00:03:55,840
‫qualquer pessoa tenha acesso a senhas ou Json Web Tokens.

78
00:03:55,840 --> 00:03:59,090
‫Só então teremos um sistema realmente seguro.

79
00:03:59,090 --> 00:04:02,430
‫Mas falaremos sobre isso mais tarde na seção, ok.

80
00:04:02,430 --> 00:04:05,120
‫Portanto, eu sei que isso pode parecer muito

81
00:04:05,120 --> 00:04:06,900
‫confuso no início, quando

82
00:04:06,900 --> 00:04:09,120
‫você tenta entender isso pela primeira

83
00:04:09,120 --> 00:04:13,490
‫vez, mas na verdade o princípio em si é bastante simples, certo?

84
00:04:13,490 --> 00:04:15,830
‫E isso é realmente tudo

85
00:04:15,830 --> 00:04:20,370
‫que você precisa saber para implementar a autenticação usando JWT.

86
00:04:20,370 --> 00:04:22,740
‫Mas agora vamos mergulhar um pouco

87
00:04:22,740 --> 00:04:25,880
‫mais fundo em como o próprio JWT realmente funciona.

88
00:04:25,880 --> 00:04:30,310
‫Portanto, um Json Web Token parece a parte esquerda desta captura de tela, que

89
00:04:30,310 --> 00:04:35,310
‫foi tirada do depurador JWT em jwt. Io.

90
00:04:35,940 --> 00:04:38,650
‫Então, essencialmente, é uma string de codificação

91
00:04:38,650 --> 00:04:40,430
‫composta de três partes.

92
00:04:40,430 --> 00:04:44,140
‫O cabeçalho, a carga útil e a assinatura.

93
00:04:44,140 --> 00:04:47,910
‫Agora, o cabeçalho é apenas alguns metadados sobre o próprio token

94
00:04:47,910 --> 00:04:50,910
‫e a carga útil são os dados

95
00:04:50,910 --> 00:04:54,470
‫que podemos codificar no token, quaisquer dados realmente que desejarmos.

96
00:04:54,470 --> 00:04:56,690
‫Portanto, quanto mais dados quisermos codificar

97
00:04:56,690 --> 00:04:58,890
‫aqui, maior será o JWT.

98
00:04:58,890 --> 00:05:01,750
‫De qualquer forma, essas duas partes são

99
00:05:01,750 --> 00:05:04,860
‫apenas texto simples que serão codificados, mas não criptografados.

100
00:05:04,860 --> 00:05:08,790
‫Assim, qualquer pessoa poderá decodificá-los e lê-los.

101
00:05:08,790 --> 00:05:11,730
‫Portanto, não podemos armazenar dados confidenciais aqui.

102
00:05:11,730 --> 00:05:13,460
‫Mas isso não é

103
00:05:13,460 --> 00:05:16,580
‫um problema porque na terceira parte, então na assinatura,

104
00:05:16,580 --> 00:05:19,370
‫é onde as coisas realmente ficam interessantes.

105
00:05:19,370 --> 00:05:22,990
‫A assinatura é criada usando o cabeçalho, a carga útil

106
00:05:22,990 --> 00:05:26,020
‫e o segredo que é salvo no servidor.

107
00:05:26,020 --> 00:05:27,080
‫Lembre-se disso?

108
00:05:27,080 --> 00:05:28,760
‫E todo esse processo é

109
00:05:28,760 --> 00:05:30,883
‫então chamado de assinatura do Json Web Token.

110
00:05:31,900 --> 00:05:35,590
‫Portanto, novamente, o algoritmo de assinatura usa o

111
00:05:35,590 --> 00:05:40,590
‫cabeçalho, a carga útil e o segredo para criar uma assinatura exclusiva.

112
00:05:40,650 --> 00:05:43,200
‫Portanto, apenas esses dados mais

113
00:05:43,200 --> 00:05:46,160
‫o segredo podem criar essa assinatura, certo?

114
00:05:46,160 --> 00:05:49,200
‫Então, junto com o cabeçalho e a

115
00:05:49,200 --> 00:05:52,310
‫carga útil, essas assinaturas formam o JWT,

116
00:05:52,310 --> 00:05:55,190
‫que é enviado ao cliente.

117
00:05:55,190 --> 00:05:58,320
‫Agora, como mencionei brevemente, logo no primeiro slide,

118
00:05:58,320 --> 00:06:02,000
‫uma vez que o servidor recebe um JWT para conceder

119
00:06:02,000 --> 00:06:05,010
‫acesso a uma rota protegida, ele precisa verificá-lo

120
00:06:05,010 --> 00:06:07,730
‫para determinar se o usuário realmente

121
00:06:07,730 --> 00:06:10,120
‫é quem diz ser, certo?

122
00:06:10,120 --> 00:06:13,890
‫Em outras palavras, ele verificará se ninguém alterou o cabeçalho

123
00:06:13,890 --> 00:06:16,580
‫e os dados de carga do token.

124
00:06:16,580 --> 00:06:20,030
‫Portanto, novamente, esta etapa de verificação verificará se

125
00:06:20,030 --> 00:06:23,350
‫nenhum terceiro realmente alterou o cabeçalho ou

126
00:06:23,350 --> 00:06:26,280
‫a carga do Json Web Token.

127
00:06:26,280 --> 00:06:29,650
‫Então, como essa verificação realmente funciona?

128
00:06:29,650 --> 00:06:32,560
‫Bem, na verdade, é bastante simples.

129
00:06:32,560 --> 00:06:35,410
‫Assim, assim que o JWT for recebido, a

130
00:06:35,410 --> 00:06:38,920
‫verificação pegará seu cabeçalho e sua carga útil e,

131
00:06:38,920 --> 00:06:41,540
‫junto com o segredo que ainda

132
00:06:41,540 --> 00:06:45,440
‫está salvo no servidor, basicamente criará uma assinatura de teste.

133
00:06:45,440 --> 00:06:48,390
‫Mas a assinatura original gerada quando

134
00:06:48,390 --> 00:06:53,390
‫o JWT foi criado pela primeira vez ainda está no token, certo?

135
00:06:53,930 --> 00:06:56,550
‫E essa é a chave para essa verificação.

136
00:06:56,550 --> 00:06:59,180
‫Porque agora tudo o que temos a

137
00:06:59,180 --> 00:07:02,590
‫fazer é comparar a assinatura de teste com a assinatura original.

138
00:07:02,590 --> 00:07:05,050
‫E se a assinatura de teste

139
00:07:05,050 --> 00:07:08,460
‫for igual à assinatura original, isso significa que a

140
00:07:08,460 --> 00:07:11,760
‫carga útil e o cabeçalho não foram modificados, certo?

141
00:07:11,760 --> 00:07:13,690
‫Porque se eles tivessem sido

142
00:07:13,690 --> 00:07:16,720
‫modificados, a assinatura de teste teria que ser diferente.

143
00:07:16,720 --> 00:07:19,600
‫Portanto, neste caso em que não

144
00:07:19,600 --> 00:07:22,990
‫houve alteração dos dados, podemos então autenticar o usuário.

145
00:07:22,990 --> 00:07:24,940
‫E, claro, se as

146
00:07:24,940 --> 00:07:27,520
‫duas assinaturas forem realmente diferentes, bem, isso

147
00:07:27,520 --> 00:07:29,870
‫significa que alguém adulterou os dados.

148
00:07:29,870 --> 00:07:32,780
‫Normalmente, tentando alterar a carga útil.

149
00:07:32,780 --> 00:07:35,470
‫Mas esse terceiro que está manipulando a carga

150
00:07:35,470 --> 00:07:38,750
‫útil, é claro, não tem acesso ao segredo, portanto,

151
00:07:38,750 --> 00:07:41,370
‫eles não podem assinar o JWT.

152
00:07:41,370 --> 00:07:44,320
‫Portanto, a assinatura original nunca corresponderá

153
00:07:44,320 --> 00:07:46,050
‫aos dados manipulados.

154
00:07:46,050 --> 00:07:49,160
‫E, portanto, a verificação sempre falhará

155
00:07:49,160 --> 00:07:50,700
‫neste caso.

156
00:07:50,700 --> 00:07:53,850
‫E essa é a chave para fazer todo o sistema funcionar.

157
00:07:53,850 --> 00:07:57,190
‫É a magia que torna o JWT tão

158
00:07:57,190 --> 00:07:59,790
‫simples, mas também extremamente poderoso.

159
00:07:59,790 --> 00:08:01,560
‫Então, deixe-me resumir novamente.

160
00:08:01,560 --> 00:08:04,830
‫Sem o segredo, ninguém será capaz de manipular os

161
00:08:04,830 --> 00:08:07,920
‫dados JWT porque eles não podem criar uma

162
00:08:07,920 --> 00:08:10,960
‫assinatura válida para os novos dados.

163
00:08:10,960 --> 00:08:13,570
‫Quer dizer, eles poderiam manipular os dados,

164
00:08:13,570 --> 00:08:16,870
‫é claro, mas sempre falhará na etapa de verificação.

165
00:08:16,870 --> 00:08:19,900
‫Agora, não se preocupe, não vamos

166
00:08:19,900 --> 00:08:22,660
‫implementar esses algoritmos JWT sozinhos.

167
00:08:22,660 --> 00:08:24,830
‫Eles são muito complexos e

168
00:08:24,830 --> 00:08:27,060
‫não vamos reinventar a roda aqui, certo?

169
00:08:27,060 --> 00:08:29,910
‫Mas ainda é muito importante entender como todo

170
00:08:29,910 --> 00:08:32,110
‫esse processo funciona nos bastidores.

171
00:08:32,110 --> 00:08:35,570
‫E espero que esta palestra tenha feito exatamente isso para você.

172
00:08:35,570 --> 00:08:38,370
‫Mas agora, vamos passar para a próxima aula para

173
00:08:38,370 --> 00:08:40,433
‫realmente começar a usar tudo isso.