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

2
00:00:04,869 --> 00:00:06,266
En las lecciones anteriores,

3
00:00:06,266 --> 00:00:10,110
hemos visto varios tipos diferentes de esquemas de autenticación.

4
00:00:10,110 --> 00:00:14,910
Comenzamos con la autenticación básica, luego analizamos cómo podemos usar las cookies para

5
00:00:14,910 --> 00:00:18,290
realizar la autenticación, e incluso las cookies firmadas

6
00:00:18,290 --> 00:00:22,090
, y luego analizamos la autenticación basada en sesión.

7
00:00:22,090 --> 00:00:27,070
Donde el servidor está realizando un seguimiento de la información sobre cada cliente, y

8
00:00:27,070 --> 00:00:30,680
luego la cookie se utilizará como una forma de indexar en la

9
00:00:30,680 --> 00:00:35,720
base de datos del lado del servidor para extraer información adicional, para validar al usuario.

10
00:00:35,720 --> 00:00:41,160
Ahora, las cookies y las autenticaciones basadas en sesión no son escalables,

11
00:00:41,160 --> 00:00:47,300
porque allí el servidor necesita realizar un seguimiento de todos los diferentes usuarios.

12
00:00:48,820 --> 00:00:53,120
Aunque, esto se hace fuera del protocolo HTTP en sí, pero

13
00:00:53,120 --> 00:00:56,160
aún así el hecho de que necesita realizar un seguimiento

14
00:00:56,160 --> 00:01:00,660
de toda la información de sección del sitio del servidor, lo hace no muy escalable.

15
00:01:00,660 --> 00:01:04,510
Así que aquí es donde la autenticación basada en tokens ha

16
00:01:04,510 --> 00:01:06,570
demostrado ser muy útil.

17
00:01:06,570 --> 00:01:11,260
veremos la autenticación base de tokens un poco más detallada en esta conferencia y el

18
00:01:11,260 --> 00:01:12,830
ejercicio que sigue.

19
00:01:14,680 --> 00:01:18,880
Una vez más, revisar rápidamente las cookies y la autenticación basada en sesión.

20
00:01:18,880 --> 00:01:20,580
Con la autenticación basada en cookies,

21
00:01:20,580 --> 00:01:25,240
notamos que las cookies se almacenan en el lado del cliente, y las cookies se incluyen

22
00:01:25,240 --> 00:01:29,510
en cada mensaje de solicitud saliente, por lo que, al servidor se le recuerda acerca de

23
00:01:29,510 --> 00:01:35,050
ese cliente específico, mediante la extracción de información de la cookie. La

24
00:01:35,050 --> 00:01:40,550
cookie se puede usar junto con las sesiones, por las que las cookies almacenan el ID de sesión

25
00:01:40,550 --> 00:01:44,650
y, a continuación, cuando el servidor recibe la solicitud entrante de la cookie,

26
00:01:44,650 --> 00:01:49,770
extrae el ID de sesión y lo utiliza como índice en el

27
00:01:49,770 --> 00:01:55,210
almacén de sesión del lado del servidor para recuperar la información de sesión para el cliente en particular.

28
00:01:55,210 --> 00:01:56,840
Ahora, este enfoque, como dije,

29
00:01:56,840 --> 00:02:01,234
no es muy escalable porque si tiene miles de sesiones, el servidor necesita realizar

30
00:02:01,234 --> 00:02:04,980
un seguimiento de todas estas miles de sesiones en el lado del servidor.

31
00:02:04,980 --> 00:02:10,820
Aunque se hace independiente de HTTP en un almacén,

32
00:02:10,820 --> 00:02:13,770
ya sea un almacén de archivos o una base de datos.

33
00:02:13,770 --> 00:02:14,610
Pero aún así,

34
00:02:14,610 --> 00:02:19,520
el hecho de que necesite realizar un seguimiento de toda esta información hace que no sea escalable.

35
00:02:19,520 --> 00:02:23,960
Entonces, de nuevo, para recordarle una vez más,

36
00:02:23,960 --> 00:02:27,201
¿por qué hablamos de autenticación basada en tokens?

37
00:02:27,201 --> 00:02:32,260
La autenticación basada en sesión, como hemos visto anteriormente, funciona perfectamente bien para

38
00:02:32,260 --> 00:02:39,910
aplicaciones web y puede ocuparse fácilmente de la autenticación del usuario.

39
00:02:39,910 --> 00:02:43,660
Pero entonces, la autenticación basada en sesión, mientras que es el principio de

40
00:02:43,660 --> 00:02:48,280
servidores sin estado y también conduce a problemas de escalabilidad.

41
00:02:48,280 --> 00:02:52,727
El segundo problema es que las aplicaciones móviles no

42
00:02:52,727 --> 00:02:58,090
manejan muy bien las autenticaciones basadas en sesiones.

43
00:02:58,090 --> 00:03:01,742
Del mismo modo, las aplicaciones móviles tienen dificultades para tratar con cookies.

44
00:03:01,742 --> 00:03:08,048
Por lo tanto, en tales circunstancias en las que su servidor está sirviendo datos

45
00:03:08,048 --> 00:03:13,610
tanto para una aplicación web como para una aplicación móvil.

46
00:03:13,610 --> 00:03:19,275
Entonces, la autenticación basada en sesión no será muy útil, y

47
00:03:19,275 --> 00:03:25,139
aquí es donde la autenticación basada en token se vuelve mucho más fácil de usar.

48
00:03:25,139 --> 00:03:29,369
En una autenticación basada en token como el nombre en su lugar,

49
00:03:29,369 --> 00:03:34,589
el servidor emitirá un token a un usuario validado, y todas las

50
00:03:34,589 --> 00:03:40,803
solicitudes posteriores que provengan del lado del cliente, llevarán el token en la solicitud misma.

51
00:03:40,803 --> 00:03:48,992
Ya sea en forma de encabezado de solicitud o en el cuerpo del mensaje de solicitud.

52
00:03:48,992 --> 00:03:53,410
Además, la autenticación basada en tokens también nos ayuda a

53
00:03:53,410 --> 00:03:57,965
lidiar con lo que se llaman problemas CORS o CSRF.

54
00:03:57,965 --> 00:04:00,480
Problemas de intercambio de recursos de origen cruzado y así

55
00:04:00,480 --> 00:04:04,360
sucesivamente, hablaré brevemente sobre el costo en el siguiente módulo.

56
00:04:04,360 --> 00:04:07,540
Pero por el momento, la autenticación basada en tokens aborda algunos de

57
00:04:07,540 --> 00:04:13,430
los problemas que se encuentran con los automóviles y los problemas relacionados con la falsificación de solicitudes entre sitios.

58
00:04:13,430 --> 00:04:17,680
No solo eso, la autenticación basada en tokens es mucho más fácil para

59
00:04:17,680 --> 00:04:21,700
una aplicación compartir su autenticación con otra aplicación.

60
00:04:21,700 --> 00:04:24,610
Por supuesto, todo esto se hace de manera segura.

61
00:04:24,610 --> 00:04:28,867
Pero, con la autenticación basada en sesión, eso no es sencillo.

62
00:04:28,867 --> 00:04:32,272
¿ Cómo funciona la autenticación basada en tokens?

63
00:04:32,272 --> 00:04:34,260
En la autenticación basada en tokens,

64
00:04:34,260 --> 00:04:40,020
el usuario primero necesita validarse a sí mismo en el lado del servidor.

65
00:04:40,020 --> 00:04:44,040
Ahora, esta validación podría tomar las formas que hemos visto antes.

66
00:04:44,040 --> 00:04:48,519
Así que podemos usar una validación local usando nombre de usuario y contraseña.

67
00:04:48,519 --> 00:04:53,111
O incluso podemos usar la validación de terceros usando

68
00:04:53,111 --> 00:04:58,267
tecnologías como, oauth u oauth 2.0 o open ID.

69
00:04:58,267 --> 00:05:03,700
Hablaremos brevemente sobre oauth y oauth 2.0 en el siguiente módulo.

70
00:05:03,700 --> 00:05:08,790
Pero, independientemente de la forma en que el usuario se autentique, una vez que el usuario

71
00:05:08,790 --> 00:05:14,370
se autentica, inmediatamente después, su servidor puede simplemente emitir un token al usuario.

72
00:05:14,370 --> 00:05:18,790
Y toda la comunicación posterior entre el usuario y

73
00:05:18,790 --> 00:05:23,658
el servidor, se puede hacer simplemente usando este token.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token del que hablaremos, es uno de esos

75
00:05:29,240 --> 00:05:35,465
esquemas de autenticación basados en tokens, y hay servidor cuando crea este token, creará un token firmado.

76
00:05:35,465 --> 00:05:40,315
Usar un secreto en el sitio del servidor que solo el servidor conoce.

77
00:05:40,315 --> 00:05:43,965
Por lo tanto, incluso si un tercero en hacia y entre y

78
00:05:43,965 --> 00:05:49,185
trata de manipular el token, incluso si captura el token e

79
00:05:49,185 --> 00:05:53,045
intenta manipular el token, el token se volverá inválido.

80
00:05:53,045 --> 00:05:57,201
Y entonces, esa forma de proteger al usuario es

81
00:05:57,201 --> 00:06:02,250
fácilmente factible, todas las solicitudes posteriores

82
00:06:02,250 --> 00:06:07,430
del lado del cliente deben llevar el token en la solicitud

83
00:06:07,430 --> 00:06:11,870
, ya sea, como dije, en el encabezado o en el cuerpo del mensaje de solicitud.

84
00:06:11,870 --> 00:06:16,120
Por lo tanto, cuando el servidor recibe este token, el servidor verificará el token,

85
00:06:16,120 --> 00:06:20,810
para asegurarse de que este es un token válido, y luego si es un token válido,

86
00:06:20,810 --> 00:06:25,430
el servidor responderá a la solicitud entrante.

87
00:06:25,430 --> 00:06:31,210
Como mencioné, JSON Web Tokens es uno de esos esquemas de autenticación basados en tokens.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token, es una forma muy simple de codificar

89
00:06:35,838 --> 00:06:41,174
información en un token y luego pasarla al sitio del cliente.

90
00:06:41,174 --> 00:06:45,702
JSON Web Token en sí se basa en estándares,

91
00:06:45,702 --> 00:06:49,670
esto se basa en el IETF RFC 7519.

92
00:06:49,670 --> 00:06:53,499
IETF aquí, significa el Grupo de Trabajo de Ingeniería de Internet.

93
00:06:53,499 --> 00:07:00,011
La organización que ordena todo acerca de cómo funciona Internet,

94
00:07:00,011 --> 00:07:06,427
y se ocupa de los protocolos y las políticas, relacionadas con Internet.

95
00:07:06,427 --> 00:07:10,391
El RFC, significa el documento de estándares,

96
00:07:10,391 --> 00:07:15,270
en términos de IETF, RFC significa Request for Comments.

97
00:07:15,270 --> 00:07:18,650
Y cada documento de tales normas lleva un número.

98
00:07:18,650 --> 00:07:23,560
7519 en este caso se refiere al documento,

99
00:07:23,560 --> 00:07:27,250
el documento estándar relacionado con JSON Web Token.

100
00:07:27,250 --> 00:07:31,420
El Token Web JSON en sí es un token autónomo, lleva toda

101
00:07:31,420 --> 00:07:37,250
la información dentro de sí mismo, que es necesaria para identificar al usuario.

102
00:07:37,250 --> 00:07:43,080
No solo eso, un token web JSON se puede compartir entre dos aplicaciones.

103
00:07:43,080 --> 00:07:46,930
Entonces, por ejemplo, una aplicación cuando se autentica y luego se apodera de

104
00:07:46,930 --> 00:07:51,760
un JSON Web Token, puede pasar ese JSON Web Token a y en

105
00:07:51,760 --> 00:07:56,950
esa aplicación, que está dispuesto a autorizar para acceder al servidor en su nombre.

106
00:07:56,950 --> 00:08:00,200
Este intercambio del token se realiza de una manera muy segura,

107
00:08:00,200 --> 00:08:03,460
así que no se preocupe demasiado por la seguridad allí.

108
00:08:03,460 --> 00:08:04,990
Esto no es de una manera segura,

109
00:08:04,990 --> 00:08:09,090
donde compartiendo el token entre una aplicación a otra.

110
00:08:09,090 --> 00:08:13,250
Por lo tanto, la autorización se transfiere a una segunda aplicación, y

111
00:08:13,250 --> 00:08:17,740
la segunda aplicación puede autorizar en nombre de la primera aplicación,

112
00:08:17,740 --> 00:08:18,990
a comunicarse con el servidor.

113
00:08:20,200 --> 00:08:24,200
Esto es factible con tokens.

114
00:08:24,200 --> 00:08:28,710
Ahora, por supuesto, el ingeniero en usted obviamente se preguntará qué hay exactamente

115
00:08:28,710 --> 00:08:32,690
dentro de un JSON Web Token, y ¿cómo es útil?

116
00:08:32,690 --> 00:08:39,120
Un token web JSON, como dije, está codificado en una cadena larga y

117
00:08:39,120 --> 00:08:43,530
esta cadena en sí puede interpretarse como que consta de tres partes.

118
00:08:43,530 --> 00:08:49,470
La cadena en sí puede, o la cadena codificada contiene tres partes,

119
00:08:49,470 --> 00:08:52,896
el encabezado, la carga útil y la firma.

120
00:08:52,896 --> 00:08:59,070
Eso lleva suficiente información sobre cómo se codifica este token.

121
00:08:59,070 --> 00:09:03,780
El encabezado en sí contiene el algoritmo específico que se utiliza para

122
00:09:03,780 --> 00:09:08,460
codificar este token web JSON y el tipo del token en sí.

123
00:09:08,460 --> 00:09:16,280
El algoritmo en este caso, sería HS256, que es un esquema de codificación de 256 bits,

124
00:09:16,280 --> 00:09:21,140
que se utiliza para hash la información dentro del token.

125
00:09:21,140 --> 00:09:24,350
Y en este caso, esto sucede que es el token web JSON, y por lo tanto

126
00:09:24,350 --> 00:09:27,870
el campo de tipo se establecerá en JWT.

127
00:09:27,870 --> 00:09:33,210
Y entonces esa es la información que se almacena en el encabezado de JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
La carga útil en sí, lleva información que le ayuda a identificar al usuario.

129
00:09:38,800 --> 00:09:41,440
En el ejercicio que vamos a hacer,

130
00:09:41,440 --> 00:09:46,730
la carga útil de horas sólo lleva el ID del usuario dentro de la carga útil.

131
00:09:46,730 --> 00:09:48,720
No es necesaria ninguna otra información.

132
00:09:48,720 --> 00:09:51,690
Este ID se puede utilizar en el lado del servidor,

133
00:09:51,690 --> 00:09:58,350
para indexar en la base de datos de Mongo para recuperar la información completa del usuario si es necesario.

134
00:09:58,350 --> 00:10:02,050
Por lo tanto, verá que codificaremos el ID y

135
00:10:02,050 --> 00:10:05,020
luego lo almacenaremos en la carga útil de ese mensaje.

136
00:10:05,020 --> 00:10:09,470
Puede almacenar información adicional en la carga útil del mensaje si lo desea.

137
00:10:09,470 --> 00:10:11,410
Pero cuanta más información almacene allí,

138
00:10:11,410 --> 00:10:15,720
mayor será el token web JSON correspondiente.

139
00:10:15,720 --> 00:10:20,010
Por lo tanto, intente limitar la cantidad de información que almacenó en la carga útil

140
00:10:20,010 --> 00:10:22,155
del token web JSON.

141
00:10:22,155 --> 00:10:27,545
Como veremos en el ejercicio, tenemos un módulo de nodo que nos permite

142
00:10:27,545 --> 00:10:30,875
codificar y crear un JSON Web Token,

143
00:10:30,875 --> 00:10:34,395
basado en la información que queremos poner en la carga útil.

144
00:10:34,395 --> 00:10:38,735
Ahora, cuando crea un token web JSON, también proporciona una firma.

145
00:10:38,735 --> 00:10:44,929
Una clave secreta en el lado del servidor que se utiliza para codificar este token web JSON,

146
00:10:44,929 --> 00:10:51,044
y ese secreto también se incluye en la parte de firma del token web JSON.

147
00:10:51,044 --> 00:10:55,232
La firma en sí se incluye de tal manera que

148
00:10:55,232 --> 00:10:58,797
hay unos conceptos básicos antes de la cabecera codificada y la carga útil,

149
00:10:58,797 --> 00:11:04,750
que luego se codifica utilizando el secreto específico que es utilizado por el servidor.

150
00:11:04,750 --> 00:11:08,644
Y esto codificado en, como dije el HMAC,

151
00:11:08,644 --> 00:11:14,144
que nos hemos referido en una de las lecciones anteriores y

152
00:11:14,144 --> 00:11:20,922
usando el hash de 256 bits, y que se incluye en la firma.

153
00:11:20,922 --> 00:11:25,118
Por lo tanto, cuando este token web JSON se recibe en el lado del servidor, y

154
00:11:25,118 --> 00:11:30,094
cuando el servidor decodifica este token, entonces el servidor puede verificar cruzada para

155
00:11:30,094 --> 00:11:34,525
asegurarse de que este token web JSON no haya sido manipulado por nadie,

156
00:11:34,525 --> 00:11:39,460
mientras el token se pasa entre el cliente y el sitio del servidor.

157
00:11:39,460 --> 00:11:43,020
Por lo tanto, si sabe algo sobre seguridad, intrusos,

158
00:11:43,020 --> 00:11:47,670
etc., entiende por qué es importante codificar el token y

159
00:11:47,670 --> 00:11:53,250
verificar la autenticidad del token en el sitio del servidor.

160
00:11:53,250 --> 00:11:58,640
Como mencioné, si necesita lidiar con JSON Web Tokens en su aplicación de nodo.

161
00:11:58,640 --> 00:12:02,810
Hay un módulo de nodo específico llamado como el módulo de nodo jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
Este módulo de nodo implementa los estándares relacionados con JSON Web Token, y

163
00:12:07,830 --> 00:12:10,640
se puede incluir en su aplicación de nodo.

164
00:12:10,640 --> 00:12:15,190
Este módulo en sí, proporciona un método llamado signo que le permite firmar y

165
00:12:15,190 --> 00:12:18,910
emitir el token al cliente desde el lado del servidor.

166
00:12:18,910 --> 00:12:21,820
También contiene un método de verificación.

167
00:12:21,820 --> 00:12:27,040
Que se puede usar para verificar la autenticidad o

168
00:12:27,040 --> 00:12:33,380
para garantizar la autenticidad del token web JSON entrante,

169
00:12:33,380 --> 00:12:38,620
por lo que haremos uso del módulo de token web JSON, en nuestro ejercicio.

170
00:12:38,620 --> 00:12:42,010
Junto con el módulo JSON Web Token,

171
00:12:42,010 --> 00:12:47,450
también usamos el módulo Passport-JWT, módulo nodo.

172
00:12:47,450 --> 00:12:54,547
Lo que proporciona las estrategias basadas en jwt para nuestro módulo de autenticación de pasaporte.

173
00:12:54,547 --> 00:12:59,441
Por lo tanto, esto proporciona una estrategia de pasaporte para autenticarse usando JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
Por lo tanto, esto le permite autenticar el endpoint RESTful usando el JWT como el método para

175
00:13:06,153 --> 00:13:12,240
dong la validación, sin requerir que el servidor use sesiones.

176
00:13:12,240 --> 00:13:17,300
Ahora, el módulo de pasaporte JWT,

177
00:13:17,300 --> 00:13:21,710
admite un método para incluso extraer el token JWT

178
00:13:21,710 --> 00:13:26,970
del mensaje de solicitud entrante, e incluso verificar el token en su nombre.

179
00:13:26,970 --> 00:13:31,470
El pasante del módulo Passport-JWT, utiliza el módulo JSON Web Token para

180
00:13:31,470 --> 00:13:34,550
hacer la verificación de ese JSON Web Token.

181
00:13:34,550 --> 00:13:40,300
El token en sí se puede llevar en el encabezado de la solicitud entrante,

182
00:13:40,300 --> 00:13:44,350
en el encabezado, incluso en el encabezado de autenticación de la solicitud entrante,

183
00:13:44,350 --> 00:13:46,940
que es lo que haremos en el ejercicio.

184
00:13:46,940 --> 00:13:51,420
El token también se puede llevar en el cuerpo de la solicitud entrante, en cuyo caso,

185
00:13:51,420 --> 00:13:54,610
tenemos que extraer el token del cuerpo de la solicitud entrante y

186
00:13:54,610 --> 00:13:56,352
luego hacer uso de él.

187
00:13:56,352 --> 00:14:01,170
El módulo Passport-JWT, soporta eso también si elige

188
00:14:01,170 --> 00:14:06,580
usarlo como forma de pasar el token de vuelta del cliente al sitio del servidor.

189
00:14:06,580 --> 00:14:11,600
El token web JSON, también se puede incluir en los parámetros de consulta URL si así lo

190
00:14:11,600 --> 00:14:16,440
decide, y puede extraerse de allí b Passport-JWT y

191
00:14:16,440 --> 00:14:18,370
utilizarse para la autenticación.

192
00:14:18,370 --> 00:14:22,783
Ahora, con esta rápida comprensión de JSON Web Tokens y

193
00:14:22,783 --> 00:14:27,915
cómo son útiles, pasaremos al ejercicio donde usaremos el módulo

194
00:14:27,915 --> 00:14:33,230
Passport-JWT, junto con el módulo JSON Web Token,

195
00:14:33,230 --> 00:14:38,211
y configuraremos nuestro servidor Express Rest API para usar JSON Web Tokens.

196
00:14:38,211 --> 00:14:41,589
[ MÚSICA]