Crear una aplicación web con autenticación usando Supabase Auth y Cloudflare | Temas

Hola, soy Matsun de Liberogic.
Es mi primer artículo.

Últimamente hay una serie de noticias de seguridad, como PHP2Shell y HTTP2Shell.
Cloudflare también ha anunciado medidas de WAF contra las vulnerabilidades de PHP.
Creo que a partir de ahora debemos prestar más atención no solo a los sistemas web, sino también a los equipos de nuestro personal y al entorno de red.

El otro día, nuestro CTO Otsuka escribió sobre la creación de una aplicación web a medida con Supabase y Cloudflare.
En esta entrega, como continuación, hablaré sobre la autenticación, un elemento imprescindible en las aplicaciones de negocio.

En los sistemas internos y los portales para socios comerciales, con poder iniciar sesión no basta. Es necesario diferenciar la información visible y las funciones disponibles según el usuario. Para ello utilizamos Supabase Auth.

En las aplicaciones de negocio, normalmente se necesita iniciar sesión

Sistema interno de solicitudes y aprobaciones
Página de miembros
Portal para socios comerciales
Gestión de horas de trabajo y asistencia
Gestión de proyectos
Sistema de gestión para tiendas y sedes

En este tipo de aplicaciones web, casi siempre se necesita una función de inicio de sesión.
Sin embargo, que se pueda iniciar sesión introduciendo un ID y una contraseña no es suficiente.
Por ejemplo, en un sistema interno de solicitudes,

Empleado general
Superior
Administrador de sucursal
Administrador general
Administrador del sistema

Incluso usando la misma aplicación, lo que cada usuario puede hacer depende de su rol.
En un portal para socios comerciales, no conviene que un responsable de la empresa A pueda ver la información de la empresa B.
En una aplicación web con autenticación, es necesario distinguir entre

la autenticación, que verifica "quién es" el usuario
la gestión de permisos, que determina "qué puede hacer" esa persona

Centralizar el inicio de sesión con Supabase Auth

Supabase Auth es la función de autenticación que ofrece Supabase. Por ejemplo,

correo electrónico + contraseña
Magic Link
contraseña de un solo uso (OTP)
Inicio de sesión social con Google y otros proveedores

y más.
En aplicaciones empresariales, lo habitual es empezar con correo electrónico y contraseña, pero según el caso también se puede permitir el acceso mediante Magic Link sin contraseña. Que no tengas que implementar y operar todo esto desde cero es una gran ventaja.
Aunque la autenticación parezca un simple formulario de inicio de sesión, por detrás,

Registro de usuarios
Gestión de contraseñas
Verificación de correo electrónico
Gestión del estado de inicio de sesión
Restablecimiento de contraseña
Gestión de sesiones

y muchos otros procesos.
Supabase puede encargarse de estas funciones básicas de autenticación.

Así se ve al combinarlo con Cloudflare

En el artículo anterior sobre CTO,

comentamos que Cloudflare actúa como punto de entrada y Supabase como base de datos

y que, aunque se añada autenticación, la idea básica sigue siendo la misma.

ユーザー
  ↓
Cloudflare
  ↓
Next.js
  ↓
Supabase Auth
  ↓
Supabase
 ├ Database
 └ RLS

El usuario accede a la aplicación web e inicia sesión con Supabase Auth.
Con la información del usuario autenticado, el lado de Next.js muestra distintas pantallas y obtiene de Supabase los datos necesarios.
Cloudflare sigue funcionando como punto de entrada de la aplicación web. En la práctica, aquí se añaden,

Cloudflare Workers
R2
SendGrid
Box
APIs externas

según sea necesario.
No es necesario hacerlo todo solo con Supabase, ni todo solo con Cloudflare.
Cada uno se utiliza para lo que mejor sabe hacer.

Cambiar la pantalla según el usuario que ha iniciado sesión

Por ejemplo, supongamos que creamos un portal para clientes. Al iniciar sesión,

○○株式会社
森本様

現在の案件
資料一覧
お問い合わせ
アカウント設定

aparece una pantalla como esta.
Si accede una persona de otra empresa, solo se muestran los proyectos y materiales de su empresa.
Si accede un administrador,

se muestran todos los clientes
Todos los proyectos
Gestión de usuarios
Gestión de archivos
Historial de operaciones

etc., se muestra un menú para administradores.
Aunque a simple vista parezca sencillo, por detrás,

es necesario determinar quién es el usuario que ha iniciado sesión

y obtener la información vinculada a ese usuario.
Con Supabase Auth, cada usuario autenticado tiene un ID que lo identifica, por lo que ese ID se asocia con los datos del negocio.

No basta con verificar la autenticación solo en el navegador

Al crear aplicaciones web con Next.js u otras herramientas, la información de autenticación no siempre se gestiona únicamente en el lado del navegador. En el servidor también suele ser necesario comprobar si el usuario ha iniciado sesión.
Supabase ofrece un método de autenticación basado en cookies para entornos SSR, y Next.js permite gestionar la sesión del usuario tanto desde el cliente como desde el servidor. Este mecanismo es muy importante. Por ejemplo,

/login

puede verse por cualquiera, pero

/dashboard

solo para las personas que han iniciado sesión,

/admin

o solo para administradores, controlando el acceso también por URL.
Ocultar simplemente el botón de "Administrar" en pantalla no garantiza la seguridad.
Para que no haya problemas aunque alguien abra una URL directamente o llame directamente a la API, también hay que verificar los permisos en el lado del servidor y de la base de datos.

Autenticación y gestión de permisos son cosas distintas

Al diseñar una aplicación de negocio, la autenticación y la gestión de permisos deben considerarse por separado.
Con Supabase Auth se puede confirmar que,

"El Sr. Morimoto ha iniciado sesión"

sí es posible verificarlo. Sin embargo,

"¿qué datos puede ver el Sr. Morimoto?"

es otra cuestión. Por ejemplo,

ユーザー
 ↓
所属会社
 ↓
所属拠点
 ↓
役割
 ↓
閲覧できるデータ

es necesario diseñar relaciones como estas.
En las aplicaciones de negocio, esta parte varía mucho de una aplicación a otra.
Si solo hay "administradores" y "usuarios generales", es sencillo, pero

sede central
Sucursal
Tienda
Cliente
Agente
Personal externo

Cuando se suman usuarios como estos, el diseño de permisos se vuelve mucho más complejo de golpe.
Y en el caso de Supabase, el elemento clave para este control de permisos es **RLS (Row Level Security)**.
Con RLS, es posible aplicar restricciones también en el lado de la base de datos, de modo que,

solo los datos propios
solo los datos de la misma empresa
solo los datos de la misma sede
todo, en el caso de los administradores

...y similares.
El diseño específico de RLS lo abordaremos en el próximo artículo.

Protección también en Cloudflare

Que exista Supabase Auth no significa que toda la seguridad de la aplicación web recaiga en Supabase. En Cloudflare,

WAF
DNS
HTTPS
protección contra bots
control de tasa de solicitudes
procesamiento de API con Workers
según sea necesario, Cloudflare Access

, entre otras medidas. Es decir,

Cloudflare
   ↓
Webアプリ
   ↓
Supabase Auth
   ↓
権限制御
   ↓
Database

Por eso conviene pensarlo en varias capas.
Tener una pantalla de inicio de sesión no significa que la aplicación sea segura.
En una aplicación web, cada capa (el punto de entrada, la aplicación, la API y la base de datos) debe contar con sus propios controles adecuados.

Por ejemplo, puede usarse en aplicaciones como estas

La combinación de Supabase Auth y Cloudflare se puede usar en diversas aplicaciones empresariales.

Aplicación interna de solicitudes y aprobaciones

Los empleados inician sesión, registran solicitudes y su superior o administrador las aprueba
Los empleados generales solo pueden ver sus propias solicitudes
Los superiores solo pueden ver los de su departamento
Los administradores tienen acceso a todo

Así es como se controlan los permisos.

Portal para socios comerciales

Se emiten cuentas por cada cliente,

información del proyecto
materiales
archivos
Avisos
Historial de consultas

y similares.
Es la misma aplicación web, pero el contenido cambia según la empresa con la que se haya iniciado sesión.

Página de miembros

Solo el propio miembro puede

consultar sus datos de registro
Historial de solicitudes
Información del contrato
archivos
Ajustes

y revisar otros datos.

Sistema de gestión de sucursales

Los responsables de tiendas y oficinas de todo el país inician sesión y registran la información de su propia sede.
El personal de la sede central puede revisar todas las sedes de forma conjunta.
Para este tipo de uso también se puede combinar Supabase Auth con el control de permisos.

Ya no es necesario construir toda la infraestructura de autenticación

Antes, al crear un sistema empresarial con autenticación, había que diseñar desde el principio cómo implementar el servidor de autenticación, cómo gestionar las sesiones y cómo vincularlas con la base de datos.
Por supuesto, hoy también es necesario diseñar todo eso.
Sin embargo, al usar un mecanismo como Supabase Auth se reduce el trabajo de construir la infraestructura de autenticación desde cero. Ese tiempo se puede dedicar a

quién puede ver qué
quién puede operar qué
qué permisos se necesitan en la operación del negocio

, que es lo que realmente conviene considerar.
Personalmente, creo que este es el gran beneficio de usar Supabase en aplicaciones empresariales.

Conclusión

Combinando Supabase Auth con Cloudflare, es posible crear aplicaciones web con autenticación incluso con una arquitectura relativamente sencilla.
Sin embargo, lo importante no es crear la pantalla de inicio de sesión.
Para los usuarios autenticados, lo que realmente importa es definir

qué pueden ver
qué pueden operar
a qué datos pueden acceder

Se convierte en una aplicación web utilizable en el trabajo solo después de diseñarla por completo.
Supabase Auth se encarga de verificar "quién es" el usuario, y el control de permisos posterior se construye en el lado de la aplicación y de la base de datos.

En la próxima entrega, veremos cómo usar RLS de Supabase en aplicaciones empresariales.