OpenID Connect (OIDC) es un protocolo de autenticación que funciona como una capa de identidad sobre el framework de autorización OAuth 2.0. Mientras que OAuth 2.0 se centra en la autorización delegada (permitiendo que una aplicación acceda a recursos protegidos en nombre de un usuario), OIDC añade la capacidad de verificar la identidad del usuario final y obtener información básica del perfil. Lo logra mediante el uso de un ID Token (un JSON Web Token o JWT) que contiene claims sobre la autenticación y el usuario. Este token es firmado digitalmente y puede ser verificado por la aplicación cliente para asegurar su integridad y autenticidad. OIDC define flujos de autenticación estándar (como Authorization Code Flow, Implicit Flow y Hybrid Flow) que permiten a las aplicaciones interactuar con un OpenID Provider (OP) para autenticar usuarios y recibir los tokens necesarios.
En el mundo real, OIDC es ampliamente adoptado como el estándar de facto para la autenticación federada y Single Sign-On (SSO) en aplicaciones web y móviles. Ejemplos concretos incluyen la autenticación con Google, Facebook, Microsoft, y otros proveedores de identidad que ofrecen "Login con X". Plataformas de identidad empresarial como Okta, Auth0, Keycloak y Azure Active Directory implementan OIDC para gestionar la autenticación de usuarios en miles de aplicaciones. Frameworks de desarrollo web y bibliotecas como Spring Security en Java, Passport.js en Node.js, y paquetes para .NET o Python, ofrecen integraciones robustas con OIDC, facilitando a los desarrolladores la implementación de flujos de autenticación seguros y conformes con el estándar.
Para un Arquitecto de Sistemas, OIDC es fundamental por varias razones estratégicas. Permite externalizar la gestión de identidades y la autenticación a proveedores especializados, reduciendo la carga de seguridad y cumplimiento normativo. Facilita la implementación de SSO a través de múltiples aplicaciones y servicios, mejorando la experiencia del usuario y la productividad. Sin embargo, implica trade-offs: se introduce una dependencia externa en el OpenID Provider, lo que requiere considerar su disponibilidad, rendimiento y políticas de seguridad. La elección del flujo de OIDC (ej. Authorization Code Flow con PKCE para clientes públicos vs. Implicit Flow para SPAs más antiguas) es crítica para la seguridad. Un arquitecto debe entender cómo gestionar los ID Tokens y Access Tokens, la revocación de sesiones, la rotación de claves y la protección contra ataques como la inyección de tokens o la suplantación de identidad, para diseñar sistemas robustos y seguros.