Cómo proteger endpoints con tokens en Express
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Contenido del curso
Curso de OAuth 2.0 y OpenID Connect: Flujos de Autenticación y Casos de Estudio
Clase 5 de 25
Clase 5 / 25
Lisandro Obregón
Antonio Obregón
Brandon Lee Aguero Fernandez
Francisco Martin Nacimiento
Juan Carlos Silva Vargas
Carlos Sanjuan
Víctor Julián González Estrada
Geovanni Labastida Vázquez
Juan Carlos Silva Vargas
Bryan Key
Dannier Leonides Galicia Chinchilla
FELIX NADER NUÑEZ
Jesús Ignacio García Fernández
Carlos Osvaldo Zapata Arango
Ulqernesh Karvenae
Julio Armando Eufraccio
Guillermo Rodas
ProfesorJosé Josías Padilla Martínez
Guillermo Rodas
ProfesorFELIX NADER NUÑEZ
Víctor Muñoz García
Víctor Muñoz García
Martin Salazar
Alejandro Chavez
Anthony Yoel Matheus García
Esta es mi respuesta al reto de la clase
En lugar de 'Descifrado del token base64' debe ser 'Descodificado del msg en base64'
Wow! 🤯, sin duda aprovechare los tests que nos ofrece postman, porque yo anteriormente copiaba y pegaba el token, ahora ya jamas 🙌
Es la segunda vez que repaso el curso, al principio sentí que se me mezclaban los conceptos e ideas, por qué repasar la autenticación tradicional, mientras el curso trata de OAuth, me costó asociar ambos conceptos.
Ahora en mi segunda iteración del curso, siguiendo el hilo de la anterior clase, entiendo que es para repasar la autenticación/autorización "tradicional" (por así llamarla) en comparación con OAauth, es decir, justamente cito la frase de la anterior clase "la autenticación/autorización ya estaba resuelta" pero entre 2 partes, no para cuando hay un 3ro involucrado.
Entonces lo que vemos acá es eso la autenticación/autorización entre 2 partes.
Faltaría creo yo profundizar un poco en por qué el método entre 2 partes no funciona con un 3ro, creo que se pueden argumentar varias cosas, las que puedo argumentar yo son:
- La confianza al tercero, como servicio, no le voy a dar tokens de acceso a cualquier otro servicio. - Como obtener el token sin exponer las credenciales de los usuarios.
Interesantes disertaciones y está bien tener una postura crítica.
Yo vine a aprender... Asi que el repaso me cae bien; pero debo decir que hasta ahora solo lo comprendo en lo tecnico... Cuando nos llevaron al codigo de ejemplo, ya dije "UY SE PUSO HEAVY" por que uno puede echar un vistazo y comprenderlo.
Pero al final, yo vine al curso por que quiero implementar un metodo para dar acceso a los vendedores de mi base de datos en el tenan de microsoft a una herramienta que por ahora va creada en el Front End... y debo construir todas las partes y que tengan congruencia. (Antes no tenia el problema de la validacion de los usuarios, por que ingresaban al formulario de Google con su cuenta de Gmail).
Por si algun buen samaritano y buen lector, lee y me da pistas... o incluso el profe.
Algo similar a esto he construido sobre Node.js, ayudandome de librerias como Passport que tienen varias middlewares y metodos para validar el token firmado, como por ejemplo que sea del secret y su tiempo de expiracion.
Cool
La maravilla de los Agentes de IA y un buen Prompt Engineering:
ChatGPT 5.1
Authorization Code con PKCE realiza validacion con code_challenge y code_verifier
Autenticación sólida del cliente. En lugar de un secreto estático, el cliente se autentica mediante certificados con mutual TLS (mTLS) o con un JWT de cliente (client assertion).
Prueba de posesión (DPoP) o tokens sender‑constrained para proteger el Token en caso de ser robado.
Autenticación multifactor (MFA) Integrar MFA con OAuth 2.0 disminuye drásticamente el impacto de credenciales comprometidas; también se recomienda configurar expiraciones cortas para los tokens y rotación de refresh tokens
Bueno, el curso hasta ahora va bien, yo colocaria los 5 videos previos y los volveria 1 solo, luego, yo soy backend dev y veo que la parte donde habla de postman lo explica MUY rapido y no explica la herramienta (entiendo que el curso no va de eso) pero supongo que un frontend o un back junior se confundiria con eso, ademas explicar express "muy por encima" tambien medio confunde, veo que hubiera sido mejor explicarlo con algun diagrama o dibujo para que la gente lo "digiera" mejor. Por el resto, perfecto! Go ahead 💚
No estoy viendo la ventaja de este curso. Los que conocemos, no aprendemos nada nuevo. Y los que no lo conocen tampoco aprenden. Esos saltos bruscos de explicarte como si fueras un niño, y de la nada se salta a usar conceptos de senior. Y gran cacareadera del oauth y oidc y nada aclaró solo conceptos que ni aclaran y ni aportan.
Este es mi aporte del diagrama del flujo de la clase !diagrama
title: Flujo del endpoint /private Postman -> /token: usuario:contraseña note: **usuario y contraseña** está codificado en base64. /token -> /token: getCredential /token -> /token: getUSer /token -> /token: singToken /token -> Postman: token Postman -> /private: _header token_ /private -> /private: getToken /private -> /private: verifyToken /private -> /private: validateExpiration /private -> Postman: response `I'm private` note: ver [clase Preview:protección de url](https://platzi.com/clases/7197-oauth/61128-preview-proteccion-de-un-endpoint/) para mas detalle
Usaria accessToken (memoria) con refreshToken (cookie http secure ) en donde cada vez que expire el accessToken generar un refreshToken nuevo para tener rotacion
Hola profesor al ocupar tanto Postman como Insomnia, en la solicitus Post me aparece:
{ "error": "invalid credentials" }
y ya estuve revisando con distintos nombres y distintas secuencias y sigo sin poder obtener mi token.
Saludos
¿Podrías compartir el token por acá y un ejemplo de cómo estás enviando la solicitud?
Tengo una curiosidad, como se comentaba en el video, enviar las credenciales como Basic Auth mediante base64 concatenando con ":", observo un inconveniente. ¿Qué sucedería si el usuario incluye ese símbolo en su email/user o contraseña?, según mis propias pruebas resulta en un fallo como el siguiente:
Lo que pasa es que como lo indica la especificación es por eso que el username no podría tener esos caracteres especiales: https://www.ietf.org/rfc/rfc2617.txt de esa forma se tomarían los primer dos puntos ":" y el resto sería considerado el password.
Perdón,
En el ejemplo anterior PORT: es PORT=
Hola, Cuando ejecuto el endpoint del token, en postman, este me devuelve el siguiente response:
{ "error": "Invalid credentials" }
¿Podrías confirmarme si tengo que generar un archivo .env con un contenido similar al siguiente?
PORT: 3000
USERNAME="victor" PASSWORD="1234" FULLNAME="Víctor Hugo Larraz"
SECRET="Cl4v3S3cret4"
Gracias.
esto es lo que pude captar
Excelente clase, muy bien explicado como funciona la autenticacion tradicional.
Inicio | V Solicitar token de acceso | V Validar token de acceso | V Si el token es válido | V Realizar solicitud al endpoint protegido | V Procesar respuesta del endpoint | V Fin
El proceso comienza con el inicio del flujo.
Se solicita un token de acceso al proveedor de autenticación o autorización correspondiente. Esto puede implicar enviar las credenciales de autenticación (como nombre de usuario y contraseña) o utilizar un flujo de autenticación específico, como OAuth o OIDC.
El token de acceso recibido es validado para asegurarse de que es auténtico y válido. Esto puede implicar verificar la firma digital, comprobar la fecha de vencimiento y garantizar que el token sea emitido por una entidad confiable.
Si el token de acceso es válido, se procede a realizar la solicitud al endpoint protegido. Esto puede ser una API o servicio web que requiere autenticación y autorización para acceder a sus recursos.
La respuesta del endpoint protegido es recibida y procesada según las necesidades del sistema. Puede implicar extraer datos relevantes, realizar acciones específicas o realizar algún tipo de procesamiento adicional.
El flujo del proceso llega a su fin una vez que se completa el procesamiento de la respuesta del endpoint protegido.
Este diagrama de flujo ilustra el flujo básico para consumir un endpoint protegido utilizando un token de acceso. Los detalles específicos y los pasos exactos pueden variar según el sistema, el proveedor de autenticación y autorización utilizado, así como el protocolo de seguridad implementado.
