OAuth para identificar, base de datos para la cuenta: la línea que no debes cruzar

Un análisis técnico vuelve sobre una decisión arquitectónica que muchos sistemas resuelven mal: separar quién eres (autenticación) de qué puedes hacer (autorización). La propuesta es sencilla y aplicable a cualquier portal con roles y acciones sensibles, no solo a la gestión de propiedades del ejemplo original: deja que Google o GitHub te digan quién es la persona, pero mantén en tu base de datos la propiedad de la cuenta, la emisión de la sesión y la revocación. Ese límite es la clave del diseño.

La razón es que un proveedor social autentica a una persona, pero no sabe qué roles tiene en tu sistema. El mismo usuario puede ser propietario de un edificio y proveedor de otro, así que la autorización tiene que evaluarse después de la autenticación, no deducirse del perfil externo. Por eso, la aplicación debe unir un subject externo a una cuenta interna, registrar esa unión y emitir una sesión cuya duración refleje el riesgo de las operaciones que permite.

Cómo hacerlo bien

La propuesta se basa en tres invariantes: un subject de proveedor mapea a una sola identidad interna, una retirada del callback no crea dos sesiones, y cada decisión de autenticación deja un registro de auditoría que sobrevive a la sesión.

Para lograrlo, guarda un account_id interno como propietario estable de los datos, y guarda el par (issuer, subject) como clave de identidad del proveedor. El email no es una clave duradera porque puede cambiar; úsalo solo para mostrar y recuperar, no para identificar. Además, tienes que mantener una tabla separada de membresías que relacione account_id, propiedad y rol, para que una señal de entrada no conceda acceso a todo lo que gestiona la empresa.

Para el inicio de sesión con Google o GitHub, el flujo correcto es el de autorización de OAuth con PKCE (RFC 6749 y RFC 7636). El navegador recibe un state y un code challenge, el servidor intercambia el código, valida el emisor y el destino, y luego busca al subject. La sesión la crea el servidor, no el navegador. Con credenciales nativas se llega al mismo punto, pero la prueba es un verificador de contraseña que tu servicio debe proteger y retirar cuando ya no sirva.

Sesión y revocación

La duración de la sesión es el siguiente gran dilema. Una cookie de navegador de dos horas limita el daño si roban la cookie, pero puede obligar a un usuario a volver a autenticarse en medio de una inspección. La solución que recomienda el análisis es una cookie opaca de sesión de corta duración, con estado de refresco en el servidor, marcada como Secure, HttpOnly y SameSite=Lax. Y para acciones de alto impacto, como cambiar una cuenta bancaria o transferir propiedad, debería exigirse autenticación adicional aunque la sesión siga activa.

El código de ejemplo, escrito en Go, muestra el patrón correcto del callback: el handler trata la respuesta como entrada al menos una vez, usa una clave única de proveedor y una transacción para hacer inofensivas las repeticiones. También insiste en que la escritura de auditoría forme parte de la misma transacción que crea la sesión; si falta una fila de auditoría, es una señal de cumplimiento, no un detalle de registro.

Este enfoque es particularmente útil en aplicaciones donde existe la tentación de fusionar cuentas solo porque comparten un correo. No hay que hacerlo: hay que exigir pruebas de control de la cuenta existente y registrar un evento de vinculación explícito. Para la auditoría, ese evento debe incluir la cuenta interna, el emisor, el subject, la sesión del actor, la marca de tiempo y el motivo.

La frontera entre OAuth y credenciales nativas no se decide por comodidad, sino por quién es el dueño último de la cuenta. Si un proveedor externo la certifica, pero tu base de datos sigue siendo el sistema de registro para la cuenta y la sesión, tienes el mejor de los dos mundos. La guía de OWASP sobre autenticación añade más contexto sobre buenas prácticas de sesión y cookies para quienes quieran profundizar.