Implementación de flujos OAuth 2.0 con APIs populares
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 11 de 25
Clase 11 / 25
Christian Valenzuela
Angel Solis
ntt data
Guillermo Rodas
Profesor
FRANKLIN ANTONIO GONZALEZ VANEGAS
Alejandro Chavez
Angel Javier Sanchez Tenjo
Enrique Ortuno
Enrique Ortuno
Mario Juárez
Benjamin Rodriguez
Unas de las diferencias entre OAuth 1 y 2 (los diferenciaremos por numero para practicidad) son los roles, antes solamente existian 3, donde el (auth server y resource server) eran uno solo.
Otra fue la complejidad a la hora de autenticarse para hacer peticiones a las APIS de terceros, donde cada request, debia ser procesado con varias implementaciones y configuraciones de librerias para llegar a un resultado final (tomando en cuenta que veniamos de un username/password). Luego, esto pasa a los tokens, donde volvemos a tener una manera mas rapida de acceder a las APIS
Primero pondré unos puntos que describen a ambos protocolos y después dejaré mi conclusión. La información de esos puntos proviene del siguiente sitio.
OAuth 1.0:
Independiente del transporte. La seguridad no se delega a HTTPS / TLS.
Fundada en criptografía, especialmente firmas digitales. Las firmas digitales se utilizan para demostrar la integridad y autenticidad de un mensaje. Las firmas digitales pueden garantizar que se envió un determinado mensaje desde una fuente específica y que el mensaje y la firma no se alteraron de ninguna manera. Un mensaje firmado está vinculado a su origen. No se puede alterar ni copiar a otra fuente, pero las implementaciones del lado del cliente pueden ser especialmente complejas.
Los mensajes se firman individualmente criptográficamente. Si un solo mensaje dentro de la comunicación se construye o firma incorrectamente, toda la transacción será invalidada.
Flujo de trabajo básico de firma.
OAuth 2.0:
Dependiente del transporte. La mayoría de las defensas de seguridad se delegan a HTTPS / TLS. Un error tipográfico, una configuración TLS incorrecta, una falla en la validación adecuada de un certificado o vulnerabilidades en una biblioteca subyacente pueden conducir a un ataque de hombre en el medio ( MitM ), comprometiendo todas las comunicaciones de OAuth.
Centrado alrededor de tokens al portador. Estos son fáciles de integrar pero no excelentes para la seguridad. Las fichas al portador no proporcionan mecanismos de seguridad interna. Se pueden copiar o robar, pero son más fáciles de implementar.
Mucho más fácil trabajar con él. OAuth 2.0 es mucho más utilizable, pero mucho más difícil de construir de forma segura.
Mucho más flexible. OAuth 1.0 solo manejó flujos de trabajo web, pero OAuth 2.0 también considera clientes no web.
Mejor separación de deberes. El manejo de solicitudes de recursos y el manejo de la autorización del usuario se pueden desacoplar en OAuth 2.0.
Flujo de trabajo básico de firma.
Revisando los anteriores puntos, se puede concluir que el cambio a la versión 2.0 fue motivada principalmente por la dificultad de implementar la anterior versión y su limitación a los flujos de trabajo web.
Mi pregunta es ¿Quién y como se debe generar el Client ID y el Client Secret?
El Auth server es quien debe generarlos para identificar todos los clientes que debe autorizar en un futuro. Ya el detalle se puede ver en la especificación.
La diferencia principal es que OAuth 1.0 puede usar firmas por petición o solo un secret con HTTPS, mientras que OAuth 2.0 simplifica todo usando solo tokens de acceso y HTTPS, eliminando la necesidad de firmas individuales y haciendo el flujo más flexible.
El curso ha estado super bien hasta ahora pero:
OAuth 1.0 y OAuth 2.0 se diferencian principalmente en su enfoque de seguridad y complejidad. OAuth 1.0 basa la seguridad en la firma criptográfica de cada solicitud, lo que lo hace muy seguro pero complejo de implementar y poco flexible para aplicaciones modernas como SPA y móviles. OAuth 2.0, en cambio, simplifica el modelo usando tokens y confiando en HTTPS como canal seguro, lo que facilita su adopción, escalabilidad e integración con APIs y arquitecturas distribuidas; por esta razón fue necesario crear OAuth 2.0, para adaptarse a la evolución de la web y mejorar la experiencia de los desarrolladores sin sacrificar la seguridad cuando se implementa correctamente.
A que se refiere la frase "esto debe suceder en el backend" en el minuto 6:43, no quería decir... esto debe suceder mediante https?
Ahora que vi los flujos en los temas mas adelante, hace todo mas sentido, esto se refiere a que deberia suceder o pasar en un proceso del backend, por ejemplo cuando una web-app es server side rendered.
Las diferencias (ventajas) intorducidas en oauth 2.0 mas importantes son:
Considero que el salto a OAuth 2.0 fue provocado por la necesidad de tener mas versatibilidad en el manejo de los token, como la implementacion de un token de actualizacion. Esta version 2.0 trajo mas variedad de metodos para realizar la validacion de un token.
