OpenID Connect, el estándar universal para SSO
OpenID Connect, conocido como OIDC, se ha convertido en el estándar universal para el inicio de sesión único y la gestión de identidades en Internet. Crea una capa de identidad en OAuth2 y es un protocolo estándar de autenticación de identidad basado en el protocolo OAuth2.
OAuth2 en realidad solo realiza autorización, mientras que OpenID Connect agrega autenticación además de la autorización.
Las ventajas de OIDC son: token de identidad (JWT) basado en JSON simple y totalmente compatible con el protocolo OAuth2.
Hoy presentaremos los principios específicos de OIDC.
Lanzado en 2014, OpenID Connect es una capa de identidad simple construida sobre el protocolo OAuth 2.0, que permite a los clientes autenticar a los usuarios finales basándose en la autenticación realizada por un servidor de autorización o un proveedor de identidad (IdP). obtener información relacionada con el usuario.
OpenID Connect proporciona una API HTTP RESTful y utiliza Json como formato de entrega de datos.
Hablamos antes del protocolo SAML basado en el formato XML, y OpenID Connect es utilizado por cada vez más aplicaciones debido a su formato de intercambio de datos más simple y se ha convertido en un estándar de facto.
Echemos un vistazo al proceso básico de OpenID Connect:
El token de identificación es como la tarjeta de identificación de un usuario. Existe en formato JWT y está firmado por el OP para garantizarlo. seguridad.
La forma de obtener el ID Token es enviar una solicitud de autenticación al OP.
Dado que el token de identificación existe en formato JWT, JWT se puede dividir en tres partes, a saber, encabezado, carga útil y firma.
Aquí nos centramos principalmente en el contenido json de Payload:
Los anteriores son los Claims estándar de ID Token.
Ahora que sabemos qué es un ID Token, ¿cómo solicitamos un ID Token en el cliente RP de OpenID Connect?
Aunque OpenID Connect no especifica cómo se debe verificar realmente la identidad de un usuario, corresponde al proveedor decidir. Pero normalmente dejamos que el navegador web realice el paso de autenticación.
El navegador redirige al usuario a la ventana de autenticación del servidor de autenticación. Después de que el usuario ingresa el nombre de usuario y la contraseña, el usuario solicita el token de identificación a través del protocolo OAuth 2.0.
Existen tres formas de utilizar OAuth 2.0 para obtener el Token de ID:
Los pasos del proceso del Código de Autorización son los siguientes:
El cliente prepara una identidad solicitud de autenticación, que contiene parámetros requeridos
El cliente envía una solicitud al servidor de autorización
El servidor de autorización autentica a los usuarios más populares
El servicio de autorización obtiene la unificación/autorización del usuario final
El servidor de autorización envía al usuario final de regreso al cliente, junto con el código de autorización
El cliente utiliza el código de autorización para solicitar una respuesta del Punto final del token
El cliente recibe la respuesta, el cuerpo de la respuesta contiene el token de identificación y el token de acceso
El cliente verifica el token de identificación y obtiene cierta información de identidad del usuario
La imagen de arriba es una autorización implícita. Por ejemplo, a diferencia del modo Código de autorización, el servidor de autenticación devuelve un fragmento del token de acceso. Solo con este fragmento, no podemos obtener el token de acceso.
Aquí necesitamos realizar una solicitud adicional al servidor de recursos del cliente y el servidor devolverá un script. A través de este script, analizamos el fragmento del token de acceso y obtenemos el token de acceso final.
El modo mixto se usa con menos frecuencia. Es una combinación de los dos modos anteriores. Permite obtener el valor del token desde el front-end y el back-end respectivamente.
Entonces, ¿qué podemos hacer con el ID Token solicitado?
El servidor no necesita almacenar información de la sesión, solo necesitamos verificar el token en el servidor.
Aquí damos un ejemplo de cómo obtener un token de identificación utilizando la autorización del código de autenticación.
El siguiente es un ejemplo de redirección:
En el lado OP, se comprobará si ya existe una sesión de usuario válida; de lo contrario, aparecerá la interfaz de inicio de sesión del usuario para permitir el usuario para iniciar sesión.
Después de iniciar sesión correctamente, el cliente será redirigido a redirigir_uri con el código de autenticación:
El código devuelto arriba es solo un producto intermedio y el RP debe enviar el código a el OP a cambio del token de identificación.
Esta vez utilizamos directamente una solicitud POST de backend:
Si tiene éxito, el OP devolverá un objeto JSON con un token de ID, un token de acceso o un token de actualización:
El formato del token de identificación es JWT.
El token de identificación que obtuvimos ya contiene información de reclamos muy útil.
De hecho, ID Token también puede contener otra información de usuario:
Como nombre, perfil, imagen, correo electrónico, sexo, fecha de nacimiento, número de teléfono, dirección y otra información útil.
Podemos agregar alcances adicionales al solicitar el token:
Por ejemplo, en el ejemplo anterior, agregamos información de correo electrónico adicional, luego el OP agregará el correo electrónico a las opciones del token.
Por ejemplo: