1 00:00:00,930 --> 00:00:03,210 ‫Instructor: Tenemos nuestro modelo de 2 00:00:03,210 --> 00:00:06,440 ‫usuario configurado listo para guardar usuarios con contraseñas seguras. 3 00:00:06,440 --> 00:00:08,850 ‫Y a continuación, realmente implementaremos 4 00:00:08,850 --> 00:00:11,670 ‫la autenticación y autorización de usuarios. 5 00:00:11,670 --> 00:00:14,230 ‫Entonces, en términos simples, todo el flujo de 6 00:00:14,230 --> 00:00:16,530 ‫trabajo de iniciar sesión a los 7 00:00:16,530 --> 00:00:19,360 ‫usuarios y permitirles interactuar con ciertos recursos protegidos a 8 00:00:19,360 --> 00:00:22,163 ‫los que los usuarios no registrados no pueden acceder. 9 00:00:23,100 --> 00:00:26,050 ‫Ahora hay muchos métodos de autenticación, 10 00:00:26,050 --> 00:00:29,360 ‫pero el que usaremos es un enfoque muy 11 00:00:29,360 --> 00:00:34,360 ‫moderno, simple y seguro llamado Json Web Tokens o JWT para abreviar. 12 00:00:35,170 --> 00:00:38,100 ‫Por lo tanto, los tokens web de Json son una solución 13 00:00:38,100 --> 00:00:39,500 ‫sin estado para la autenticación. 14 00:00:39,500 --> 00:00:43,410 ‫Por lo tanto, no es necesario almacenar ningún estado de sesión en 15 00:00:43,410 --> 00:00:47,360 ‫el servidor, lo que, por supuesto, es perfecto para API tranquilas como la 16 00:00:47,360 --> 00:00:48,580 ‫que estamos construyendo. 17 00:00:48,580 --> 00:00:53,080 ‫Porque recuerde, las API de descanso siempre deben ser sin estado. 18 00:00:53,080 --> 00:00:56,300 ‫Y la alternativa más utilizada a la autenticación con 19 00:00:56,300 --> 00:01:00,240 ‫JWT es simplemente almacenar el estado de inicio de sesión del 20 00:01:00,240 --> 00:01:02,420 ‫usuario en el servidor mediante sesiones. 21 00:01:02,420 --> 00:01:05,150 ‫Pero, por supuesto, no sigue el principio 22 00:01:05,150 --> 00:01:08,700 ‫que dice que las API tranquilas deben ser apátridas y es 23 00:01:08,700 --> 00:01:12,293 ‫por eso que estamos optando por una solución como los JWT. 24 00:01:13,130 --> 00:01:15,960 ‫Así que ahora echemos un vistazo a cómo funciona realmente 25 00:01:15,960 --> 00:01:18,660 ‫la autenticación con los tokens web de Json. 26 00:01:18,660 --> 00:01:21,600 ‫Y asumiendo que ya tenemos un usuario registrado en nuestra 27 00:01:21,600 --> 00:01:25,380 ‫base de datos, así es como un usuario inicia sesión en la aplicación. 28 00:01:25,380 --> 00:01:28,700 ‫Entonces, el cliente del usuario comienza haciendo una solicitud de 29 00:01:28,700 --> 00:01:32,330 ‫publicación con el nombre de usuario o correo electrónico y la contraseña. 30 00:01:32,330 --> 00:01:35,400 ‫La aplicación luego verifica si el usuario existe y 31 00:01:35,400 --> 00:01:37,430 ‫si la contraseña es correcta. 32 00:01:37,430 --> 00:01:40,340 ‫Y si es así, se crea un Json 33 00:01:40,340 --> 00:01:44,010 ‫Web Token exclusivo para ese usuario utilizando una cadena secreta 34 00:01:44,010 --> 00:01:46,290 ‫que se almacena en un servidor. 35 00:01:46,290 --> 00:01:49,410 ‫Y un JWT en sí mismo es en realidad solo una 36 00:01:49,410 --> 00:01:51,150 ‫cadena que se parece a esto. 37 00:01:51,150 --> 00:01:54,170 ‫Pero hablaremos más sobre el propio JWT en 38 00:01:54,170 --> 00:01:55,770 ‫la siguiente diapositiva. 39 00:01:55,770 --> 00:02:00,440 ‫De todos modos, el servidor envía ese JWT de vuelta al cliente, que 40 00:02:00,440 --> 00:02:04,160 ‫lo almacenará en una cookie o en el almacenamiento local. 41 00:02:04,160 --> 00:02:06,930 ‫Y así, el usuario se autentica y 42 00:02:06,930 --> 00:02:09,570 ‫básicamente inicia sesión en nuestra 43 00:02:09,570 --> 00:02:12,720 ‫aplicación sin dejar ningún estado en el servidor. 44 00:02:12,720 --> 00:02:16,310 ‫Por tanto, el servidor no sabe qué usuarios 45 00:02:16,310 --> 00:02:17,930 ‫han iniciado sesión. 46 00:02:17,930 --> 00:02:20,960 ‫Pero, por supuesto, el usuario sabe que ha 47 00:02:20,960 --> 00:02:25,040 ‫iniciado sesión porque tiene un Json Web Token válido, que es un 48 00:02:25,040 --> 00:02:29,270 ‫poco como un pasaporte para acceder a las partes protegidas de la aplicación. 49 00:02:29,270 --> 00:02:32,470 ‫Así que de nuevo, solo para asegurarnos de que entendiste la idea. 50 00:02:32,470 --> 00:02:35,330 ‫Un usuario inicia sesión tan pronto como recupera 51 00:02:35,330 --> 00:02:39,720 ‫su token web Json válido único que no se guarda en ningún 52 00:02:39,720 --> 00:02:41,030 ‫lugar del servidor. 53 00:02:41,030 --> 00:02:44,840 ‫Por tanto, este proceso es completamente apátrida. 54 00:02:44,840 --> 00:02:49,300 ‫Luego, cada vez que un usuario desea acceder a una ruta protegida, como los 55 00:02:49,300 --> 00:02:51,940 ‫datos de su perfil de usuario, por 56 00:02:51,940 --> 00:02:55,360 ‫ejemplo, envía su Json Web Token junto con una solicitud. 57 00:02:55,360 --> 00:02:58,480 ‫Entonces es un poco como mostrar su pasaporte para 58 00:02:58,480 --> 00:03:00,450 ‫acceder a esa ruta, ¿verdad? 59 00:03:00,450 --> 00:03:03,870 ‫Y esa es probablemente la mejor y más fácil forma de 60 00:03:03,870 --> 00:03:05,320 ‫entender toda esta idea. 61 00:03:05,320 --> 00:03:07,910 ‫Ahora, una vez que la solicitud llega al 62 00:03:07,910 --> 00:03:11,140 ‫servidor, nuestra aplicación verificará si el Json Web Token 63 00:03:11,140 --> 00:03:12,580 ‫es realmente válido. 64 00:03:12,580 --> 00:03:15,760 ‫Entonces, si el usuario es realmente quien dice ser. 65 00:03:15,760 --> 00:03:17,710 ‫Y más sobre cómo funciona este paso 66 00:03:17,710 --> 00:03:19,660 ‫un poco más adelante en este video. 67 00:03:19,660 --> 00:03:22,710 ‫Ahora bien, si el token es realmente válido, 68 00:03:22,710 --> 00:03:26,210 ‫entonces los datos solicitados se enviarán al cliente y, de lo 69 00:03:26,210 --> 00:03:29,400 ‫contrario, habrá un error que le indicará al usuario 70 00:03:29,400 --> 00:03:32,600 ‫que no tiene permiso para acceder a ese recurso. 71 00:03:32,600 --> 00:03:34,880 ‫Y mientras el usuario esté conectado, 72 00:03:34,880 --> 00:03:38,230 ‫así es como funcionará cada vez que solicite datos 73 00:03:38,230 --> 00:03:39,843 ‫de cualquier ruta protegida. 74 00:03:40,840 --> 00:03:43,000 ‫Ahora, lo que es muy importante 75 00:03:43,000 --> 00:03:47,570 ‫tener en cuenta aquí es que toda esta comunicación debe ocurrir a través de https. 76 00:03:47,570 --> 00:03:51,510 ‫HTTP cifrado tan seguro para evitar que cualquier 77 00:03:51,510 --> 00:03:55,840 ‫persona pueda acceder a contraseñas o tokens web Json. 78 00:03:55,840 --> 00:03:59,090 ‫Solo entonces tendremos un sistema realmente seguro. 79 00:03:59,090 --> 00:04:02,430 ‫Pero hablaremos de eso más adelante en la sección, está bien. 80 00:04:02,430 --> 00:04:05,120 ‫Entonces sé que esto puede parecer bastante 81 00:04:05,120 --> 00:04:06,900 ‫confuso al principio cuando 82 00:04:06,900 --> 00:04:09,120 ‫intentas entenderlo por primera vez, 83 00:04:09,120 --> 00:04:13,490 ‫pero en realidad el principio en sí es bastante simple, ¿de acuerdo? 84 00:04:13,490 --> 00:04:15,830 ‫Y esto es realmente todo 85 00:04:15,830 --> 00:04:20,370 ‫lo que necesita saber para poder implementar la autenticación mediante JWT. 86 00:04:20,370 --> 00:04:22,740 ‫Pero ahora profundicemos un poco 87 00:04:22,740 --> 00:04:25,880 ‫más en cómo funciona realmente el JWT. 88 00:04:25,880 --> 00:04:30,310 ‫Entonces, un Json Web Token parece la parte izquierda de esta captura de pantalla que 89 00:04:30,310 --> 00:04:35,310 ‫fue tomada del depurador JWT en jwt. io. 90 00:04:35,940 --> 00:04:38,650 ‫Básicamente, es una cadena de codificación compuesta 91 00:04:38,650 --> 00:04:40,430 ‫de tres partes. 92 00:04:40,430 --> 00:04:44,140 ‫El encabezado, la carga útil y la firma. 93 00:04:44,140 --> 00:04:47,910 ‫Ahora, el encabezado es solo algunos metadatos sobre el token en 94 00:04:47,910 --> 00:04:50,910 ‫sí y la carga útil son los datos 95 00:04:50,910 --> 00:04:54,470 ‫que podemos codificar en el token, cualquier dato que realmente queramos. 96 00:04:54,470 --> 00:04:56,690 ‫Entonces, cuantos más datos queramos codificar 97 00:04:56,690 --> 00:04:58,890 ‫aquí, mayor será el JWT. 98 00:04:58,890 --> 00:05:01,750 ‫De todos modos, estas dos partes son solo 99 00:05:01,750 --> 00:05:04,860 ‫texto sin formato que se codificará, pero no se cifrará. 100 00:05:04,860 --> 00:05:08,790 ‫Entonces cualquiera podrá decodificarlos y leerlos. 101 00:05:08,790 --> 00:05:11,730 ‫Por lo tanto, no podemos almacenar ningún dato sensible aquí. 102 00:05:11,730 --> 00:05:13,460 ‫Pero eso no es un 103 00:05:13,460 --> 00:05:16,580 ‫problema en absoluto porque en la tercera parte, así que en 104 00:05:16,580 --> 00:05:19,370 ‫la firma, es donde las cosas se ponen realmente interesantes. 105 00:05:19,370 --> 00:05:22,990 ‫La firma se crea utilizando el encabezado, la carga útil y 106 00:05:22,990 --> 00:05:26,020 ‫el secreto que se guarda en el servidor. 107 00:05:26,020 --> 00:05:27,080 ‫¿Recuérdalo? 108 00:05:27,080 --> 00:05:28,760 ‫Y todo este proceso 109 00:05:28,760 --> 00:05:30,883 ‫se llama firmar el Json Web Token. 110 00:05:31,900 --> 00:05:35,590 ‫Entonces, nuevamente, el algoritmo de firma toma el 111 00:05:35,590 --> 00:05:40,590 ‫encabezado, la carga útil y el secreto para crear una firma única. 112 00:05:40,650 --> 00:05:43,200 ‫Entonces, solo estos datos más el 113 00:05:43,200 --> 00:05:46,160 ‫secreto pueden crear esta firma, ¿de acuerdo? 114 00:05:46,160 --> 00:05:49,200 ‫Luego, junto con el encabezado y la 115 00:05:49,200 --> 00:05:52,310 ‫carga útil, estas firmas forman el JWT, 116 00:05:52,310 --> 00:05:55,190 ‫que luego se envía al cliente. 117 00:05:55,190 --> 00:05:58,320 ‫Ahora, como mencioné brevemente, justo en la primera 118 00:05:58,320 --> 00:06:02,000 ‫diapositiva, una vez que el servidor recibe un JWT para 119 00:06:02,000 --> 00:06:05,010 ‫otorgar acceso a una ruta protegida, necesita verificarlo 120 00:06:05,010 --> 00:06:07,730 ‫para determinar si el usuario realmente 121 00:06:07,730 --> 00:06:10,120 ‫es quien dice ser, ¿verdad? 122 00:06:10,120 --> 00:06:13,890 ‫En otras palabras, verificará si nadie cambió el encabezado y 123 00:06:13,890 --> 00:06:16,580 ‫los datos de carga útil del token. 124 00:06:16,580 --> 00:06:20,030 ‫Entonces, nuevamente, este paso de verificación verificará si 125 00:06:20,030 --> 00:06:23,350 ‫ningún tercero realmente alteró el encabezado o la 126 00:06:23,350 --> 00:06:26,280 ‫carga útil del Json Web Token. 127 00:06:26,280 --> 00:06:29,650 ‫Entonces, ¿cómo funciona realmente esta verificación? 128 00:06:29,650 --> 00:06:32,560 ‫Bueno, en realidad es bastante sencillo. 129 00:06:32,560 --> 00:06:35,410 ‫Entonces, una vez que se recibe el JWT, 130 00:06:35,410 --> 00:06:38,920 ‫la verificación tomará su encabezado y carga útil y, 131 00:06:38,920 --> 00:06:41,540 ‫junto con el secreto que aún 132 00:06:41,540 --> 00:06:45,440 ‫está guardado en el servidor, básicamente creará una firma de prueba. 133 00:06:45,440 --> 00:06:48,390 ‫Pero la firma original que se generó 134 00:06:48,390 --> 00:06:53,390 ‫cuando se creó por primera vez el JWT todavía está en el token, ¿verdad? 135 00:06:53,930 --> 00:06:56,550 ‫Y esa es la clave para esta verificación. 136 00:06:56,550 --> 00:06:59,180 ‫Porque ahora todo lo que tenemos que 137 00:06:59,180 --> 00:07:02,590 ‫hacer es comparar la firma de prueba con la firma original. 138 00:07:02,590 --> 00:07:05,050 ‫Y si la firma de prueba 139 00:07:05,050 --> 00:07:08,460 ‫es la misma que la firma original, entonces significa que la 140 00:07:08,460 --> 00:07:11,760 ‫carga útil y el encabezado no se han modificado, ¿verdad? 141 00:07:11,760 --> 00:07:13,690 ‫Porque si se hubieran modificado, 142 00:07:13,690 --> 00:07:16,720 ‫la firma de prueba tendría que ser diferente. 143 00:07:16,720 --> 00:07:19,600 ‫Por lo tanto, en este caso en el que 144 00:07:19,600 --> 00:07:22,990 ‫no ha habido alteración de los datos, podemos autenticar al usuario. 145 00:07:22,990 --> 00:07:24,940 ‫Y, por supuesto, si 146 00:07:24,940 --> 00:07:27,520 ‫las dos firmas son realmente diferentes, bueno, 147 00:07:27,520 --> 00:07:29,870 ‫entonces significa que alguien manipuló los datos. 148 00:07:29,870 --> 00:07:32,780 ‫Por lo general, al intentar cambiar la carga útil. 149 00:07:32,780 --> 00:07:35,470 ‫Pero ese tercero que manipula la carga útil, 150 00:07:35,470 --> 00:07:38,750 ‫por supuesto, no tiene acceso al secreto, por lo 151 00:07:38,750 --> 00:07:41,370 ‫que no puede firmar el JWT. 152 00:07:41,370 --> 00:07:44,320 ‫Por lo que la firma original nunca se corresponderá 153 00:07:44,320 --> 00:07:46,050 ‫con los datos manipulados. 154 00:07:46,050 --> 00:07:49,160 ‫Y por lo tanto, la verificación siempre fallará 155 00:07:49,160 --> 00:07:50,700 ‫en este caso. 156 00:07:50,700 --> 00:07:53,850 ‫Y esa es la clave para que todo este sistema funcione. 157 00:07:53,850 --> 00:07:57,190 ‫Es la magia lo que hace que JWT sea 158 00:07:57,190 --> 00:07:59,790 ‫tan simple, pero también extremadamente poderoso. 159 00:07:59,790 --> 00:08:01,560 ‫Permítanme resumirlo nuevamente. 160 00:08:01,560 --> 00:08:04,830 ‫Sin el secreto, nadie podrá manipular los datos 161 00:08:04,830 --> 00:08:07,920 ‫de JWT porque no pueden crear una 162 00:08:07,920 --> 00:08:10,960 ‫firma válida para los nuevos datos. 163 00:08:10,960 --> 00:08:13,570 ‫Quiero decir que podrían manipular los datos, 164 00:08:13,570 --> 00:08:16,870 ‫por supuesto, pero siempre fallará el paso de verificación. 165 00:08:16,870 --> 00:08:19,900 ‫Ahora, no se preocupe, no vamos a implementar 166 00:08:19,900 --> 00:08:22,660 ‫estos algoritmos JWT por nosotros mismos. 167 00:08:22,660 --> 00:08:24,830 ‫Son muy complejos y no vamos 168 00:08:24,830 --> 00:08:27,060 ‫a reinventar la rueda aquí, ¿de acuerdo? 169 00:08:27,060 --> 00:08:29,910 ‫Pero sigue siendo muy importante comprender realmente cómo funciona 170 00:08:29,910 --> 00:08:32,110 ‫todo este proceso detrás de escena. 171 00:08:32,110 --> 00:08:35,570 ‫Y espero que esta conferencia haya hecho precisamente eso por ti. 172 00:08:35,570 --> 00:08:38,370 ‫Pero ahora, pasemos a la siguiente lección para 173 00:08:38,370 --> 00:08:40,433 ‫comenzar a usar todo esto.