Por qué tu producto necesita OAuth 2.0 y OIDC — Especialmente en la era de la IA

Desde el principio, Logto se construyó con una fuerte creencia en los estándares abiertos. Elegimos seguir protocolos como OIDC, OAuth 2.0 y SAML, no solo porque son ampliamente utilizados, sino porque representan prácticas bien establecidas y seguras en las que confía la industria. La seguridad siempre ha sido una prioridad para nosotros. También lo ha sido mantenerse fiel al espíritu del código abierto y adherirse a las mejores prácticas en Gestión de Identidad del Cliente y autenticación moderna.

Pero también aprendimos algo en el camino:

OAuth 2.0 y OIDC no son fáciles para todos. Para los desarrolladores que son nuevos en estos protocolos, los conceptos pueden parecer ajenos y, a veces, incluso contraintuitivos. Esto llevó a desafíos reales mientras trabajábamos para simplificar la experiencia del desarrollador sin comprometer la seguridad.

Dos cosas destacaron:

1. Aunque hemos trabajado duro para que la integración sea lo más fluida posible, todavía hay una curva de aprendizaje en torno a la comprensión de conceptos básicos como tokens de identificación, tokens de acceso y cómo funcionan.
2. Una pregunta común que recibimos es: "¿Puedo omitir el redireccionamiento en la pantalla de inicio de sesión?" Lamentablemente, el redireccionamiento es una parte esencial de cómo funciona OIDC y es necesario para la autenticación segura.

Una pregunta común de nuestros usuarios de Discord (con su ID y avatar obfuscados para privacidad).

Cada decisión viene con compensaciones, pero a veces, una elección que hiciste al principio resulta ser especialmente valiosa a medida que surgen nuevos casos de uso. Y ahora estamos entrando en una nueva era: la era de la IA.

En este artículo, exploraré cuándo tu producto debería usar OIDC y OAuth 2.0, cuándo podría no necesitarlo, y por qué siempre he defendido la adopción de estos estándares abiertos desde el principio, especialmente si estás construyendo un negocio real y eligiendo una solución CIAM. También explicaré por qué el auge de la IA hace que esta decisión sea más importante que nunca.

Lo que realmente hace OAuth 2.0 (con una analogía sencilla)#

Para los lectores que no están muy familiarizados con OAuth 2.0, permíteme dedicar un momento a repasar brevemente algunos de los conceptos básicos nuevamente, solo para aclarar las cosas.

OAuth 2.0 es para autorización delegada: OAuth 2.0 es un protocolo estándar de la industria para la autorización: permite que un servicio acceda a recursos en nombre de otro servicio con el consentimiento del propietario del recurso.

En un escenario OAuth, el usuario (propietario del recurso) concede a una aplicación cliente un acceso limitado (permisos definidos) a un API o servidor de recursos, sin compartir su contraseña. OAuth define cómo solicitar y emitir tokens de acceso que el cliente puede usar para llamar a APIs protegidos. Esto fue un cambio radical en comparación con los primeros días en los que las aplicaciones podían pedirte tus credenciales para acceder a otro servicio (un riesgo serio para la seguridad). Con OAuth 2.0, los usuarios aprueban un acceso específico y el cliente obtiene un token con solo los permisos y la duración necesarios: no se intercambian contraseñas, lo que mejora drásticamente la seguridad.

Piensa en OAuth 2.0 como registrarte en un hotel.

Tú (el usuario) eres el propietario de la habitación (tus datos). Pero en lugar de darle a alguien tu llave de la habitación (tu contraseña), vas a la recepción y pides una tarjeta de acceso temporal (un token de acceso) que solo funciona para que tu invitado o amigo ingresen al gimnasio o la piscina, no a toda la habitación.

El personal del hotel (sistema OAuth) emite esta tarjeta limitada con reglas específicas:

• Solo funciona para el gimnasio (recurso específico).
• Es válida por un tiempo corto.
• No permite que nadie entre en tu habitación.

De esta manera, no tienes que entregar tu llave maestra, y el sistema permanece seguro, incluso si alguien más obtiene esa tarjeta limitada.

Veamos otro ejemplo. OAuth 2.0 se utiliza ampliamente en el escenario de inicio de sesión social.

Digamos que te estás registrando en una nueva aplicación como Notion, y en lugar de crear un nuevo nombre de usuario y contraseña, haces clic en "Continuar con Google."

Esto es lo que sucede detrás de escena con OAuth 2.0:

1. Te redirigen a la página de inicio de sesión de Google, donde inicias sesión (si no lo has hecho ya).

2. Google pregunta:

   “¿Permites que esta aplicación vea tu perfil básico y dirección de correo electrónico?”

3. Haces clic en "Permitir", y Google envía a la aplicación un token de acceso.

4. La aplicación usa ese token para:

   • Confirmar tu identidad (a través de tu correo electrónico e información de perfil).
   • Crear o iniciar sesión en una cuenta, sin ver nunca tu contraseña de Google.

Lo que realmente hace OIDC (con una analogía sencilla)#

Ahora echemos un vistazo a OIDC, un estándar más nuevo y avanzado. OpenID Connect apunta a Identidad y Autenticación: es una capa de autenticación construida sobre OAuth 2.0. Mientras que OAuth 2.0 por sí solo no le dice a la aplicación quién es el usuario (solo se trata de tokens de acceso y permisos), OIDC agrega una manera estándar de manejar el inicio de sesión del usuario y la identidad.

Cuando se utiliza OIDC, el servidor de autorización también actúa como un Proveedor de OpenID (un Proveedor de Identidad) que autentica al usuario y emite un token de identificación que contiene información sobre el usuario (las “afirmaciones de identidad”).

En resumen, OAuth 2.0 responde a “¿Puede este cliente acceder a este recurso?” y OIDC responde a “¿Quién es el usuario que acaba de iniciar sesión?”. Juntos, permiten que tu aplicación verifique la identidad del usuario y luego use tokens autorizados para acceder a APIs en nombre del usuario.

Usemos la analogía del hotel para entender mejor OAuth 2.0 vs. OIDC nuevamente.

Imagina que te estás registrando en un hotel.

• OAuth 2.0 es como pedirle al hotel que deje que tu amigo use el gimnasio y la piscina en tu nombre.

  Vas a la recepción, das permiso, y el hotel le da a tu amigo un pase de invitado.

  Al hotel no le importa quién es el amigo, solo que está permitido usar las instalaciones.

  👉 Eso es OAuth: “Esta aplicación puede acceder a algunos de mis datos o servicios.”

• OIDC es como pedirle al hotel que verifique quién es la persona antes de darle acceso.

  Así que tu amigo también muestra una tarjeta de identificación: y ahora el hotel sabe su nombre, estado, y que es un huésped verificado.

  👉 Eso es OIDC: “Aquí está quién es el usuario, y ahora están registrados.”

Cómo usa Logto OAuth 2.0 y OpenID Connect (OIDC)#

Las características principales de autenticación de Logto están construidas sobre OIDC (OpenID Connect)#

En el corazón, Logto es un proveedor de OpenID Connect (OIDC): un estándar construido sobre OAuth 2.0 que se enfoca en la autenticación segura y moderna del usuario. Logto es una solución profesional CIAM, donde las identidades son los bloques de construcción centrales que gestionamos.

Diseñamos Logto con la seguridad como base. Eso significa hacer cumplir PKCE por defecto, bloquear flujos inseguros como el flujo implícito y depender de la redirección para manejar los inicios de sesión de forma segura.

¿Por qué redirección?#

OIDC está destinado a la autenticación basada en el navegador. No es solo una elección técnica: se trata de brindar a los usuarios una experiencia segura y consistente en todas las plataformas. Redirigir al usuario al proveedor de identidad (como Logto, Google o Microsoft) ayuda a hacer eso posible.

Esto es lo que parece el flujo típico:

1. El usuario hace clic en “Iniciar sesión”

   → Tu aplicación los envía a la página de inicio de sesión de Logto.

2. Inician sesión de manera segura

   → Aquí es donde ocurren cosas como MFA, biometría o inicios de sesión sociales.

3. Logto los devuelve

   → Junto con un token seguro o código de autorización.

4. Tu aplicación completa el inicio de sesión

   → El token es verificado, y el usuario inicia sesión.

Este patrón puede parecer simple, pero trae beneficios poderosos:

• Tu aplicación no maneja credenciales directamente, lo que significa menos riesgos.
• Es más fácil agregar funciones como MFA sin cambiar el código de la aplicación.
• Funciona genial para móviles también:
  • iOS usa ASWebAuthenticationSession
  • Android usa Custom Tabs

Y si tu producto abarca múltiples aplicaciones, la redirección permite el inicio de sesión único: los usuarios inician sesión una vez y se mueven entre aplicaciones sin fricciones.

Logto no admite recopilar contraseñas directamente en tu aplicación. Eso es intencional. El flujo ROPC no se recomienda para las mejores prácticas de seguridad de OAuth 2.0 por buenas razones: es menos seguro y más difícil de escalar de manera segura.

Logto también es un proveedor de OAuth 2.0/OIDC (Proveedor de Identidad)#

Logto es más que solo un servidor de autenticación: es un Proveedor de OAuth 2.0, OpenID Connect (OIDC) y Proveedor de Identidad (IdP) completo. Eso significa que puede gestionar de manera segura las identidades de usuario y emitir tokens que otras aplicaciones pueden confiar.

Además de potenciar las experiencias de inicio de sesión para tus propias aplicaciones, Logto también admite integraciones de aplicaciones de terceros, permitiendo que servicios externos confíen en Logto como su fuente de identidad.

¿Qué significa eso en la práctica?

Como un Proveedor de Identidad (IdP), Logto maneja la verificación de usuarios, gestiona credenciales y emite tokens de autenticación. Una vez que un usuario inicia sesión, Logto puede permitirles acceder a diferentes aplicaciones, incluso de otros proveedores, sin tener que iniciar sesión nuevamente. Es el mismo concepto detrás de “Iniciar sesión con Google” o “Iniciar sesión con Microsoft”.

Hay dos tipos de aplicaciones en este contexto:

• Aplicaciones de primera mano: Aplicaciones que construyes y controlas completamente, integradas directamente con Logto.
• Aplicaciones de terceros: Servicios externos construidos por socios o desarrolladores fuera de tu organización.

Logto permite a tus usuarios iniciar sesión en estas aplicaciones de terceros usando sus cuentas Logto existentes, igual que los usuarios empresariales inician sesión en herramientas como Slack con sus credenciales de Google Workspace. Esto te permite:

• Ofrecer inicio de sesión único (SSO) en todo tu ecosistema.
• Construir una plataforma abierta, donde desarrolladores de terceros puedan agregar “Iniciar sesión con Logto” a sus aplicaciones.

¿Cuándo realmente necesitas OAuth 2.0 y OIDC?#

1. Si previamente usaste Auth0 (o similar): Auth0 ya es un proveedor de OAuth 2.0 y OIDC. Gestiona el inicio de sesión del usuario, la emisión de tokens e integra con tus APIs o aplicaciones.
2. Autorización M2M: Servidor a servidor (flujo de credenciales del cliente) Las máquinas (o servicios backend) necesitan comunicarse de forma segura sin un usuario.
3. Flujo de dispositivos: Smart TVs, consolas, dispositivos IoT: Dispositivos como televisores o impresoras necesitan autenticar a un usuario. El flujo de dispositivos es parte de OIDC.
4. Tienes las necesidades de interacción: No solo estás autenticando usuarios: estás creando un ecosistema donde aplicaciones externas, socios o agentes pueden integrarse con tu plataforma y acceder a datos de usuario de manera segura.

Por qué OAuth y OIDC son más importantes que nunca en la era de la IA#

En la era de la IA, estamos viendo un aumento de nuevas necesidades de integración y acceso, especialmente en áreas como agentes autónomos, dispositivos inteligentes y comunicación sistema a sistema. Estas tendencias están haciendo que OAuth 2.0 y OIDC sean más importantes que nunca. Aquí hay algunos ejemplos:

1. Servidores MCP remotos

   Construyes un servidor MCP (Protocolo de Contexto de Modelo) remoto y deseas que agentes de terceros se conecten a él. Estos agentes necesitan acceso seguro para solicitar contexto, realizar acciones e intercambiar datos, todo sin comprometer la confianza del usuario. OAuth proporciona el mecanismo para delegar acceso de manera segura.

2. Abrir tu producto a integraciones

   Ejecutas tus propios servicios empresariales —digamos una herramienta de gestión de proyectos o una plataforma para clientes— y deseas permitir que otros productos o agentes se integren con ello. Eso podría significar extraer datos, activar flujos de trabajo o integrar tus funciones en otros entornos. OAuth 2.0/OIDC habilita un control de acceso basado en tokens, de gran precisión, sin compartir credenciales de usuario.

3. Construir tu propio agente

   Estás creando un agente de IA o asistente y quieres que interactúe con otras aplicaciones y servidores MCP: programar reuniones, enviar correos electrónicos, publicar actualizaciones o consultar datos. Estos requieren acceso seguro y autenticado a servicios de terceros. OAuth 2.0 es cómo tu agente obtiene autorización para actuar en nombre del usuario.

4. El auge de los dispositivos inteligentes

   Dispositivos de hardware como traductores de IA o tomadores de notas inteligentes están siendo más capaces gracias a los LLM. Y con menores costos y mayor rendimiento, más de estos dispositivos están saliendo al mercado. Estos dispositivos a menudo necesitan una forma de autenticar usuarios y acceder a servicios basados en la nube, especialmente con interfaces de entrada limitadas. Ahí es donde los flujos como el flujo de autorización de dispositivos de OAuth y la validación de identidad basada en OIDC se vuelven críticos.

Cuándo podrías no necesitar OAuth 2.0/OIDC#

Por supuesto, hay casos en los que podrías no necesitar OAuth 2.0 u OIDC, al menos no en este momento. En otras palabras, si tu caso de uso actual es simple o completamente autónomo, estos protocolos podrían no aportar valor inmediato.

Sin embargo, a medida que tu producto crece o tu ecosistema se expande, la necesidad de OAuth 2.0 y OIDC a menudo se hace mucho más evidente a largo plazo.

1. Aplicaciones internas simples

   Si tu aplicación solo es utilizada por un pequeño equipo dentro de una empresa y no necesita integrarse con servicios de terceros o exponer APIs, un sistema de autenticación básico de usuario-contraseña (por ejemplo, sesiones de cookies) podría ser suficiente.

2. No se necesita autenticación de usuarios

   Si tu producto no tiene cuentas de usuario o funciones conscientes de la identidad —como un sitio de contenido público o una herramienta servidor a servidor con claves de API estáticas— OIDC no es necesario.

3. No se requiere acceso delegado

   OAuth brilla cuando necesitas que los usuarios autoricen a tu aplicación para acceder a sus datos en otro sistema (por ejemplo, Google Drive). Si no estás integrando APIs de terceros o construyendo flujos de trabajo multisistema, OAuth agrega complejidad con poco valor.

4. Entorno único, riesgo mínimo

   Para prototipos en etapas tempranas, MVPs o herramientas de prueba internas donde la simplicidad y la velocidad son más importantes que las necesidades de seguridad, podrías retrasar la implementación de OAuth/OIDC hasta más tarde.

Pensamientos finales sobre la elección de la estrategia de autenticación correcta#

Podrías no necesitar OAuth 2.0 u OIDC de inmediato, y eso está completamente bien. En las etapas tempranas, las soluciones simples a menudo cumplen el trabajo. Pero a medida que tu producto crece, a medida que los agentes y la IA se integran más en cómo construimos y a medida que tu ecosistema se abre a socios y terceros, la autenticación segura y estandarizada se convierte menos en un lujo y más en una necesidad.

En lugar de apresurarte más tarde, vale la pena sentar las bases ahora. Adoptar OAuth 2.0 y OIDC no es solo resolver los problemas de hoy: se trata de estar preparado para lo que viene.