1
00:00:00,000 --> 00:00:04,869
[MÚSICA]

2
00:00:04,869 --> 00:00:06,266
Nas lições anteriores,

3
00:00:06,266 --> 00:00:10,110
vimos vários tipos diferentes de esquemas de autenticação.

4
00:00:10,110 --> 00:00:14,910
Começamos com a autenticação básica, depois analisamos como podemos usar cookies para

5
00:00:14,910 --> 00:00:18,290
fazer autenticação e até mesmo cookies assinados e,

6
00:00:18,290 --> 00:00:22,090
posteriormente, analisamos a autenticação baseada em sessão.

7
00:00:22,090 --> 00:00:27,070
Onde o servidor está mantendo o controle de informações sobre cada cliente e,

8
00:00:27,070 --> 00:00:30,680
em seguida, o cookie será usado como uma forma de indexação no

9
00:00:30,680 --> 00:00:35,720
banco de dados do lado do servidor para extrair informações adicionais, para validar o usuário.

10
00:00:35,720 --> 00:00:41,160
Agora, o cookie e autenticações baseadas em sessão não são escaláveis,

11
00:00:41,160 --> 00:00:47,300
porque há servidor precisa manter o controle de todos os usuários diferentes.

12
00:00:48,820 --> 00:00:53,120
Mesmo assim, isso é feito fora do próprio protocolo HTTP, mas

13
00:00:53,120 --> 00:00:56,160
ainda assim o fato de que você precisa manter o controle

14
00:00:56,160 --> 00:01:00,660
de todas as informações da seção do site do servidor, torna não muito escalável.

15
00:01:00,660 --> 00:01:04,510
Então é aqui que a autenticação baseada em tokens

16
00:01:04,510 --> 00:01:06,570
provou ser muito útil.

17
00:01:06,570 --> 00:01:11,260
vamos olhar para autenticação de base de tokens um pouco mais detalhado nesta palestra e

18
00:01:11,260 --> 00:01:12,830
exercício que se segue.

19
00:01:14,680 --> 00:01:18,880
Novamente, revisando rapidamente os cookies e a autenticação baseada em sessão.

20
00:01:18,880 --> 00:01:20,580
Com a autenticação baseada em cookies,

21
00:01:20,580 --> 00:01:25,240
percebemos que os cookies são armazenados no lado do cliente, e os cookies são incluídos

22
00:01:25,240 --> 00:01:29,510
em todas as mensagens de solicitação de saída em que, o servidor é lembrado sobre

23
00:01:29,510 --> 00:01:35,050
esse cliente específico, extraindo informações do cookie.

24
00:01:35,050 --> 00:01:40,550
Cookie pode ser usado em conjunto com sessões, em que os cookies armazenam o ID da sessão

25
00:01:40,550 --> 00:01:44,650
e, em seguida, quando o servidor recebe a solicitação de entrada do cookie,

26
00:01:44,650 --> 00:01:49,770
ele extrai o ID da sessão e usa isso como um índice no

27
00:01:49,770 --> 00:01:55,210
armazenamento de sessão do lado do servidor para recuperar as informações da sessão para o cliente específico.

28
00:01:55,210 --> 00:01:56,840
Agora, essa abordagem, como eu disse,

29
00:01:56,840 --> 00:02:01,234
não é muito escalável porque se você tiver milhares de sessões, o servidor precisa

30
00:02:01,234 --> 00:02:04,980
acompanhar todos esses milhares de sessões no lado do servidor.

31
00:02:04,980 --> 00:02:10,820
Mesmo que seja feito independente de HTTP em um armazenamento, um armazenamento

32
00:02:10,820 --> 00:02:13,770
de arquivos ou um banco de dados.

33
00:02:13,770 --> 00:02:14,610
Mas ainda assim,

34
00:02:14,610 --> 00:02:19,520
o fato de que você precisa rastrear todas essas informações torna não escalável.

35
00:02:19,520 --> 00:02:23,960
Então, novamente, para lembrá-lo mais uma vez,

36
00:02:23,960 --> 00:02:27,201
por que falamos sobre autenticação baseada em tokens?

37
00:02:27,201 --> 00:02:32,260
A autenticação baseada em sessão, como vimos anteriormente, funciona perfeitamente bem para

38
00:02:32,260 --> 00:02:39,910
aplicativos da web e pode facilmente cuidar da autenticação do usuário.

39
00:02:39,910 --> 00:02:43,660
Mas, em seguida, a autenticação baseada em sessão, embora seja o princípio dos

40
00:02:43,660 --> 00:02:48,280
servidores sem estado e também leva a problemas de escalabilidade.

41
00:02:48,280 --> 00:02:52,727
A segunda questão é, os aplicativos móveis não

42
00:02:52,727 --> 00:02:58,090
manipulam autenticações baseadas em sessão muito bem.

43
00:02:58,090 --> 00:03:01,742
Da mesma forma, os aplicativos móveis têm dificuldade em lidar com cookies.

44
00:03:01,742 --> 00:03:08,048
Então, em tais circunstâncias em que seu servidor está servindo dados

45
00:03:08,048 --> 00:03:13,610
tanto para um aplicativo web quanto para um aplicativo móvel.

46
00:03:13,610 --> 00:03:19,275
Em seguida, a autenticação baseada em sessão não será muito útil, e

47
00:03:19,275 --> 00:03:25,139
é aí que a autenticação baseada em token se torna muito mais fácil de usar.

48
00:03:25,139 --> 00:03:29,369
Em uma autenticação baseada em token como o nome no lugar,

49
00:03:29,369 --> 00:03:34,589
o servidor emitirá um token para um usuário validado, e todas as

50
00:03:34,589 --> 00:03:40,803
solicitações subsequentes provenientes do lado do cliente, terão o token na própria solicitação.

51
00:03:40,803 --> 00:03:48,992
Seja na forma de um cabeçalho de solicitação ou no corpo da mensagem de solicitação.

52
00:03:48,992 --> 00:03:53,410
Além disso, a autenticação baseada em tokens também nos ajuda a

53
00:03:53,410 --> 00:03:57,965
lidar com o que são chamados de problemas CORS ou CSRF.

54
00:03:57,965 --> 00:04:00,480
Problemas de compartilhamento de recursos de origem cruzada e assim por

55
00:04:00,480 --> 00:04:04,360
diante, falarei brevemente sobre o custo no próximo módulo.

56
00:04:04,360 --> 00:04:07,540
Mas, no momento, a autenticação baseada em tokens aborda alguns

57
00:04:07,540 --> 00:04:13,430
dos problemas que estão com carros e problemas relacionados à falsificação de solicitações entre sites.

58
00:04:13,430 --> 00:04:17,680
Não só isso, a autenticação baseada em tokens é muito mais fácil para

59
00:04:17,680 --> 00:04:21,700
um aplicativo compartilhar sua autenticação com outro aplicativo.

60
00:04:21,700 --> 00:04:24,610
Claro, tudo isso é feito de forma segura.

61
00:04:24,610 --> 00:04:28,867
Mas, com autenticação baseada em sessão, isso não é direto.

62
00:04:28,867 --> 00:04:32,272
Como funciona a autenticação baseada em tokens?

63
00:04:32,272 --> 00:04:34,260
Na autenticação baseada em tokens,

64
00:04:34,260 --> 00:04:40,020
o usuário primeiro precisa validar a si mesmo no lado do servidor.

65
00:04:40,020 --> 00:04:44,040
Agora, esta validação pode assumir as formas que vimos anteriormente.

66
00:04:44,040 --> 00:04:48,519
Então, podemos usar uma validação local usando nome de usuário e senha.

67
00:04:48,519 --> 00:04:53,111
Ou, podemos até usar validação de terceiros usando

68
00:04:53,111 --> 00:04:58,267
tecnologias como, oauth ou oauth 2.0 ou open ID.

69
00:04:58,267 --> 00:05:03,700
Vamos falar brevemente sobre oauth e oauth 2.0 no próximo módulo.

70
00:05:03,700 --> 00:05:08,790
Mas, independentemente da forma como o usuário autentica, uma vez que o usuário

71
00:05:08,790 --> 00:05:14,370
é autenticado, logo a seguir, seu servidor pode simplesmente emitir um token para o usuário.

72
00:05:14,370 --> 00:05:18,790
E toda a comunicação subsequente entre o usuário e

73
00:05:18,790 --> 00:05:23,658
o servidor, pode ser feita simplesmente usando este token.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token que vamos falar, é um

75
00:05:29,240 --> 00:05:35,465
esquema de autenticação baseado em token, e há servidor quando ele cria este token, ele irá criar um token assinado.

76
00:05:35,465 --> 00:05:40,315
Usando um segredo no site do servidor que só o servidor sabe.

77
00:05:40,315 --> 00:05:43,965
Assim, mesmo que um terceiro em direção e entre e

78
00:05:43,965 --> 00:05:49,185
tente manipular o token, mesmo que ele capture o token e

79
00:05:49,185 --> 00:05:53,045
tente manipular o token, o token se tornará inválido.

80
00:05:53,045 --> 00:05:57,201
E assim, essa maneira de proteger o usuário é

81
00:05:57,201 --> 00:06:02,250
facilmente viável, todas as solicitações subsequentes

82
00:06:02,250 --> 00:06:07,430
do lado do cliente devem levar o token na solicitação

83
00:06:07,430 --> 00:06:11,870
, seja, como eu disse, no cabeçalho ou no corpo da mensagem de solicitação.

84
00:06:11,870 --> 00:06:16,120
Assim, quando o servidor recebe este token, o servidor irá verificar o token,

85
00:06:16,120 --> 00:06:20,810
para garantir que este é um token válido, e, em seguida, se for um token válido,

86
00:06:20,810 --> 00:06:25,430
o servidor irá então responder à solicitação de entrada.

87
00:06:25,430 --> 00:06:31,210
Como mencionei, JSON Web Tokens é um esquema de autenticação baseado em tokens.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token, é uma maneira muito simples de codificar

89
00:06:35,838 --> 00:06:41,174
informações em um token, em seguida, passá-lo para o site do cliente.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token é baseado em padrões,

91
00:06:45,702 --> 00:06:49,670
isso é baseado no IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF aqui, significa a Força-Tarefa de Engenharia da Internet.

93
00:06:53,499 --> 00:07:00,011
A organização que determina tudo sobre como funciona a internet,

94
00:07:00,011 --> 00:07:06,427
e lida com os protocolos e as políticas, relacionados à internet.

95
00:07:06,427 --> 00:07:10,391
O RFC, significa o documento de padrões,

96
00:07:10,391 --> 00:07:15,270
em termos IETF, RFC significa Solicitação de Comentários.

97
00:07:15,270 --> 00:07:18,650
E cada documento de padrões carrega um número.

98
00:07:18,650 --> 00:07:23,560
7519 neste caso refere-se ao documento,

99
00:07:23,560 --> 00:07:27,250
o documento padrão relacionado ao Token da Web JSON.

100
00:07:27,250 --> 00:07:31,420
O Token Web JSON em si é um token auto-contido, ele carrega todas

101
00:07:31,420 --> 00:07:37,250
as informações dentro de si mesmo, que é necessário para identificar o usuário.

102
00:07:37,250 --> 00:07:43,080
Não só isso, um JSON Web Token pode ser compartilhado entre dois aplicativos.

103
00:07:43,080 --> 00:07:46,930
Assim, por exemplo, um aplicativo quando ele autentica e, em seguida, se apossar de

104
00:07:46,930 --> 00:07:51,760
um JSON Web Token, pode passar esse JSON Web Token para e

105
00:07:51,760 --> 00:07:56,950
nesse aplicativo, que ele está disposto a autorizar a acessar o servidor em seu nome.

106
00:07:56,950 --> 00:08:00,200
Este compartilhamento do token é feito de uma maneira muito segura,

107
00:08:00,200 --> 00:08:03,460
então não se preocupe muito com a segurança lá dentro.

108
00:08:03,460 --> 00:08:04,990
Isso não é de forma segura,

109
00:08:04,990 --> 00:08:09,090
onde pelo compartilhamento do token entre um aplicativo para outro.

110
00:08:09,090 --> 00:08:13,250
Assim, a autorização é transferida para um segundo aplicativo, e

111
00:08:13,250 --> 00:08:17,740
o segundo aplicativo pode autorizar, em nome do primeiro aplicativo,

112
00:08:17,740 --> 00:08:18,990
a se comunicar com o servidor.

113
00:08:20,200 --> 00:08:24,200
Isso é viável com tokens.

114
00:08:24,200 --> 00:08:28,710
Agora, é claro, o engenheiro em você obviamente estará se perguntando o que exatamente está

115
00:08:28,710 --> 00:08:32,690
dentro de um JSON Web Token, e como ele é útil?

116
00:08:32,690 --> 00:08:39,120
Um JSON Web Token, como eu disse, é codificado em uma string longa e

117
00:08:39,120 --> 00:08:43,530
esta string em si pode ser interpretada como consistindo de três partes.

118
00:08:43,530 --> 00:08:49,470
A string em si pode, ou a string codificada contém três partes,

119
00:08:49,470 --> 00:08:52,896
o cabeçalho, a carga útil e a assinatura.

120
00:08:52,896 --> 00:08:59,070
Isso traz informações suficientes sobre como esse token é codificado.

121
00:08:59,070 --> 00:09:03,780
O cabeçalho em si contém o algoritmo específico que é usado para

122
00:09:03,780 --> 00:09:08,460
codificar este Token da Web JSON e o tipo do próprio token.

123
00:09:08,460 --> 00:09:16,280
O algoritmo neste caso, seria HS256 que é um esquema de codificação de 256 bits,

124
00:09:16,280 --> 00:09:21,140
que é usado para hash as informações dentro do token.

125
00:09:21,140 --> 00:09:24,350
E neste caso, este é o Token da Web JSON e, portanto,

126
00:09:24,350 --> 00:09:27,870
o campo de tipo será definido como JWT.

127
00:09:27,870 --> 00:09:33,210
E então essa é a informação que é armazenada no cabeçalho do JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
A carga útil em si, transporta informações que ajudam você a identificar o usuário.

129
00:09:38,800 --> 00:09:41,440
No exercício que faremos,

130
00:09:41,440 --> 00:09:46,730
a carga horária só carrega o ID do usuário dentro da carga útil.

131
00:09:46,730 --> 00:09:48,720
Nenhuma outra informação é necessária.

132
00:09:48,720 --> 00:09:51,690
Esse ID pode ser usado no lado do servidor,

133
00:09:51,690 --> 00:09:58,350
para indexar no banco de dados Mongo para recuperar as informações completas do usuário, se necessário.

134
00:09:58,350 --> 00:10:02,050
Então, você verá que vamos codificar o ID e

135
00:10:02,050 --> 00:10:05,020
, em seguida, armazená-lo na carga dessa mensagem.

136
00:10:05,020 --> 00:10:09,470
Você pode armazenar informações adicionais na carga útil da mensagem, se necessário.

137
00:10:09,470 --> 00:10:11,410
Mas quanto mais informações você armazenou lá,

138
00:10:11,410 --> 00:10:15,720
maior o JSON Web Token correspondente vai para mim.

139
00:10:15,720 --> 00:10:20,010
Então, tente limitar a quantidade de informações que você armazenou na carga

140
00:10:20,010 --> 00:10:22,155
do token da Web JSON.

141
00:10:22,155 --> 00:10:27,545
Como veremos no exercício, temos um módulo de nó que nos permite

142
00:10:27,545 --> 00:10:30,875
codificar e criar um JSON Web Token,

143
00:10:30,875 --> 00:10:34,395
com base nas informações que queremos colocar na carga útil.

144
00:10:34,395 --> 00:10:38,735
Agora, quando você cria um JSON Web Token, você também fornece uma assinatura.

145
00:10:38,735 --> 00:10:44,929
Uma chave secreta no lado do servidor que é usada para codificar este JSON Web Token,

146
00:10:44,929 --> 00:10:51,044
e esse segredo também está incluído na parte de assinatura do JSON Web Token.

147
00:10:51,044 --> 00:10:55,232
A assinatura em si é incluída de tal forma que

148
00:10:55,232 --> 00:10:58,797
há um básico antes codificado cabeçalho e payload,

149
00:10:58,797 --> 00:11:04,750
que é então codificado usando o segredo específico que é usado pelo servidor.

150
00:11:04,750 --> 00:11:08,644
E isso codificado em, como eu disse o HMAC,

151
00:11:08,644 --> 00:11:14,144
que nos referimos em uma das lições anteriores e

152
00:11:14,144 --> 00:11:20,922
usando o 256 bit hashing, e que está incluído na assinatura.

153
00:11:20,922 --> 00:11:25,118
Então, quando este JSON Web Token é recebido no lado do servidor, e

154
00:11:25,118 --> 00:11:30,094
quando o servidor decodifica esse token, então o servidor é capaz de cruzar a verificação para

155
00:11:30,094 --> 00:11:34,525
se certificar de que este JSON Web Token não foi adulterado por ninguém,

156
00:11:34,525 --> 00:11:39,460
enquanto o token está sendo passado entre o cliente e o site do servidor.

157
00:11:39,460 --> 00:11:43,020
Então, se você sabe alguma coisa sobre segurança, intrusos,

158
00:11:43,020 --> 00:11:47,670
e assim por diante, você entende por que é importante codificar o token e

159
00:11:47,670 --> 00:11:53,250
verificar a autenticidade do token no site do servidor.

160
00:11:53,250 --> 00:11:58,640
Como mencionei, se você precisa lidar com JSON Web Tokens em seu aplicativo de nó.

161
00:11:58,640 --> 00:12:02,810
Há um módulo de nó específico chamado como o módulo de nó jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
Este módulo de nó implementa os padrões relacionados ao Token da Web JSON e

163
00:12:07,830 --> 00:12:10,640
pode ser incluído em seu aplicativo de nó.

164
00:12:10,640 --> 00:12:15,190
Este módulo em si, fornece um método chamado sinal que permite que você assine e

165
00:12:15,190 --> 00:12:18,910
emitir o token para o cliente a partir do lado do servidor.

166
00:12:18,910 --> 00:12:21,820
Ele também contém um método de verificação.

167
00:12:21,820 --> 00:12:27,040
Que pode ser usado para verificar a autenticidade ou

168
00:12:27,040 --> 00:12:33,380
para garantir a autenticidade do token da Web JSON de entrada,

169
00:12:33,380 --> 00:12:38,620
então estaremos fazendo uso do módulo de token da Web JSON, em nosso exercício.

170
00:12:38,620 --> 00:12:42,010
Juntamente com o módulo JSON Web Token,

171
00:12:42,010 --> 00:12:47,450
também usamos o módulo Passport-JWT, módulo de nó.

172
00:12:47,450 --> 00:12:54,547
Que fornece as estratégias baseadas em jwt para o nosso módulo de autenticação de passaporte.

173
00:12:54,547 --> 00:12:59,441
Então, isso fornece uma estratégia de passaporte para autenticação usando JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
Então, isso permite que você autentique endpoint RESTful usando o JWT como o método para

175
00:13:06,153 --> 00:13:12,240
dong a validação, sem exigir que o servidor use sessões.

176
00:13:12,240 --> 00:13:17,300
Agora, o módulo de passaporte JWT,

177
00:13:17,300 --> 00:13:21,710
suporta um método de até mesmo extrair o token JWT

178
00:13:21,710 --> 00:13:26,970
da mensagem de solicitação de entrada e, em seguida, até mesmo verificar o token em seu nome.

179
00:13:26,970 --> 00:13:31,470
O estagiário do módulo Passport-JWT usa o módulo JSON Web Token para

180
00:13:31,470 --> 00:13:34,550
fazer a verificação desse JSON Web Token.

181
00:13:34,550 --> 00:13:40,300
O token em si pode ser carregado no cabeçalho da solicitação de entrada,

182
00:13:40,300 --> 00:13:44,350
no cabeçalho, mesmo no cabeçalho de autenticação da solicitação de entrada,

183
00:13:44,350 --> 00:13:46,940
que é o que estaremos fazendo no exercício.

184
00:13:46,940 --> 00:13:51,420
O token também pode ser transportado no corpo da solicitação de entrada, caso em que,

185
00:13:51,420 --> 00:13:54,610
temos que extrair o token do corpo da solicitação de entrada e

186
00:13:54,610 --> 00:13:56,352
, em seguida, fazer uso dele.

187
00:13:56,352 --> 00:14:01,170
O módulo Passport-JWT, suporta isso também se você optar por

188
00:14:01,170 --> 00:14:06,580
usar isso como forma de passar o token de volta do cliente para o site do servidor.

189
00:14:06,580 --> 00:14:11,600
O JSON Web Token, também pode ser incluído nos parâmetros de consulta URL se você assim

190
00:14:11,600 --> 00:14:16,440
escolher, e pode ser extraído de lá b Passport-JWT e

191
00:14:16,440 --> 00:14:18,370
usado para autenticação.

192
00:14:18,370 --> 00:14:22,783
Agora, com este rápido entendimento de JSON Web Tokens e

193
00:14:22,783 --> 00:14:27,915
como eles são úteis, vamos passar para o exercício onde vamos usar

194
00:14:27,915 --> 00:14:33,230
o módulo Passport-JWT, juntamente com o módulo JSON Web Token,

195
00:14:33,230 --> 00:14:38,211
e configurar nosso servidor de API Express Rest para usar JSON Web Tokens.

196
00:14:38,211 --> 00:14:41,589
[ MUSIC]