OAuth, SAML y OpenID: Comparación

Estándar abierto para la autorización que permite a los usuarios conceder acceso a sus recursos (ej: archivos de Google Drive) a otra plataforma sin compartir sus credenciales.

Estándar basado en XML para autenticación y autorización, permitiendo inicio de sesión único (SSO) en múltiples plataformas sin volver a ingresar credenciales.

(No especificado en el texto proporcionado).

OAuth se enfoca en la autorización de acceso, SAML en la autenticación y inicio de sesión único, y OpenID (no especificado) posiblemente en la verificación de identidad. Sus usos y enfoques son diferentes.

Aunque el texto no explica cómo se combinan, OAuth puede trabajar con OpenID Connect para la verificación de identidad, y SAML establece el inicio/cierre de sesión.

Beneficios: Acceso seguro a recursos, inicio de sesión único. Desafíos: Complejidad de la implementación, mantenimiento, seguridad de las credenciales (que no se comparten).

OAuth define cuatro roles: Dueño del recurso, Cliente, Servidor de recursos y Servidor de autorización.

Un protocolo de autenticación basado en XML que permite el intercambio de información de autenticación y autorización entre dominios federados.

Proveedor de identidad en SAML, responsable de verificar la identidad de los usuarios.

Proveedor de servicio en SAML, que solicita la información de los usuarios al IDP.

Estándar abierto para autenticación que permite a los usuarios utilizar sus identidades online existentes para iniciar sesión en otros sitios.

Protocolo principalmente utilizado para autorización, permitiendo a los clientes solicitar acceso a recursos de usuario en un servidor.

Proceso de verificar la identidad de un usuario.

Proceso de determinar los permisos de un usuario para acceder a recursos.

Arquitectura en la que un cliente solicita un servicio a un servidor.

Arquitectura en la que entidades confían entre sí para el intercambio de información de seguridad.

Arquitectura donde no hay un centro de control, sino que cada entidad tiene autonomía.

Estándar para autorizar el acceso a recursos de usuario. Permite a las apps pedir permiso para acceder a datos del usuario en otras plataformas sin compartir las credenciales.

Protocolo de autenticación y autorización basado en XML para el inicio de sesión único en múltiples plataformas.

Entidad que verifica la identidad de un usuario en SAML.

Estándar basado en XML para autenticación y autorización, permitiendo inicio de sesión único en múltiples plataformas.

Entidad que solicita la información de usuario al IDP en SAML.

Estándar de autenticación. Permite a los usuarios iniciar sesión en otras plataformas con sus credenciales existentes.

OAuth se centra en la autorización, SAML en la autenticación y sesión única, y OpenID en la validación de identidad. Tienen enfoques distintos.

Estándar abierto de autenticación que permite usar identidades online existentes en otros sitios web.

Protocolo principalmente para autorización, permitiendo a clientes acceder a recursos de usuario sin compartir credenciales.

Pueden trabajar juntos. OAuth gestiona el permiso de acceso, SAML la sesión única y OpenID la verificación de identidad. OpenID Connect es un derivado de OpenID que se usa mucho con OAuth.

OAuth define cuatro roles: Dueño del Recurso, Cliente, Servidor de Recursos y Servidor de Autorización.

Proceso de verificar la identidad de un usuario.

Proveedor de Identidad en SAML, responsable de verificar la identidad del usuario.

Proceso de determinar los permisos de un usuario para acceder a recursos.

Arquitectura donde un cliente solicita servicios a un servidor.

Proveedor de Servicios en SAML, que solicita información de usuarios al IDP.

Arquitectura donde entidades confían entre sí para intercambio de información de seguridad.

Arquitectura sin un centro de control, cada entidad con autonomía.

Estándar para autorización de acceso a recursos. Permite a las aplicaciones pedir permiso para acceder a datos del usuario en otras plataformas.

Estándar de autenticación que permite a los usuarios iniciar sesión en otras plataformas con sus credenciales existentes.

Tokens que representan las autorizaciones y la información de seguridad del usuario.

Proceso de verificar la identidad de un usuario.

Proceso de determinar los permisos de un usuario para acceder a recursos.

Método anterior de compartir credenciales de usuario directamente con el servicio.

Acceder a un recurso actuando como el usuario final.

Claves únicas que identifican a una aplicación y otorgan acceso a la API.

Método de obtención de tokens de acceso sin intercambiar un código de autorización, lo que reduce el número de pasos, aunque es arriesgado.

Método estándar de obtención de tokens donde un código se intercambia por un token de acceso.

Método para aplicaciones con una relación de confianza establecida.

Permite renovar tokens de acceso expirados sin interactuar nuevamente con el usuario.

Método alternativo al flujo embebido para aplicaciones móviles que usa el navegador del sistema para autenticación, evitando un navegador dentro de la app.

Añade autenticación a OAuth 2.0, proporcionando información adicional del usuario (id_token).

Estándar para la transmisión segura de información entre dos partes en formato JSON, usada por OpenID Connect.

Combinación de flujos de autorización y secreto de cliente que permite acceso inmediato al id_token y llamadas adicionales al backend.

Un ataque donde un sitio web malicioso engaña al navegador para que realice una acción en un sitio web al que el usuario está autenticado.

Un pequeño archivo de texto que un servidor web guarda en el navegador de un usuario.

Claves que identifican a un proyecto y dan acceso completo a todas las operaciones de una API.

Un framework para la autorización, no la autenticación, permitiendo a las aplicaciones pedir permiso al usuario para acceder a recursos en otras plataformas.

Versión mejorada de OAuth, que utiliza scopes y diferentes flujos para gestionar permisos más específicos.

Permisos específicos que define una aplicación para acceder a recursos.

Diferentes métodos para obtener tokens de acceso dependiendo del tipo de aplicación.

Aplicaciones que pueden guardar una contraseña (secreto) para mayor seguridad.

Aplicaciones que no pueden guardar secretos y requieren un flujo específico para la autorización.

Flujo recomendado, seguro, para obtener access_token usando un código intermedio que solo la application sabe.

Procedimiento dentro del Authorization Code Flow para mejorar la seguridad.