Auth - Autenticación y gestión de usuarios de Supabase

Auth es un servidor de autenticación y gestión de usuarios escrito en Go que impulsa las funciones de Supabase, como:

• Emisión de JWTs
• Seguridad a nivel de fila con PostgREST
• Gestión de usuarios
• Inicio de sesión con correo electrónico, contraseña, enlace mágico, número de teléfono
• Inicio de sesión con proveedores externos (Google, Apple, Facebook, Discord, ...)

Originalmente se basa en el excelente código base de GoTrue de Netlify; sin embargo, ambos han divergido significativamente en características y capacidades.

Si deseas contribuir al proyecto, consulta la guía de contribución.

Tabla de contenido

• Inicio rápido
• Ejecución en producción
• Configuración
• Endpoints

Inicio rápido

Crea un archivo .env para almacenar tus propias variables de entorno personalizadas. Consulta example.env

1. Inicia la base de datos Postgres local en un contenedor Postgres: docker-compose -f docker-compose-dev.yml up postgres
2. Compila el binario de auth: make build . Deberías ver una salida como esta:```bash go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" GOOS=linux GOARCH=arm64 go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" -o gotrue-arm64

3. Ejecuta el binario de auth: `./auth`

### Si tienes Docker instalado

Crea un archivo `.env.docker` para almacenar tus propias variables de entorno personalizadas. Consulta [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env)

1. `make build`
2. `make dev`
3. `docker ps` debería mostrar dos contenedores Docker (`auth-auth-1` y `auth-postgres-1`)
4. ¡Eso es todo! Visita el [endpoint de verificación de salud](http://localhost:9999/health) para confirmar que auth está en ejecución.

## Ejecución en producción

Ejecutar un servidor de autenticación en producción no es tarea fácil. Recomendamos usar [Supabase Auth](https://supabase.com/auth), que recibe actualizaciones de seguridad periódicas.

De lo contrario, asegúrate de configurar un proceso para actualizar rápidamente a la última versión. Puedes hacerlo siguiendo este repositorio, especialmente las secciones [Releases](https://github.com/supabase/auth/releases) y [Avisos de seguridad](https://github.com/supabase/auth/security/advisories).

### Compatibilidad hacia atrás

Auth utiliza el esquema de [Versionado Semántico](https://semver.org). Aquí hay algunas aclaraciones adicionales sobre las garantías de compatibilidad hacia atrás:

**Compatibilidad con la API de Go**

Auth no está pensado para usarse como una biblioteca de Go. No hay garantías de compatibilidad de API hacia atrás cuando se usa de esta manera, independientemente del número de versión que cambie.

**Parche**

Los cambios en la versión de parche garantizan compatibilidad hacia atrás con:

- Objetos de base de datos (tablas, columnas, índices, funciones).
- API REST
- Estructura JWT
- Configuración

Ejemplos garantizados:

- Una columna no cambiará su tipo.
- Una tabla no cambiará su clave primaria.
- Un índice no se eliminará.
- Una restricción de unicidad no se eliminará.
- Una API REST no se eliminará.
- Los parámetros de las API REST funcionarán de manera equivalente a antes (o mejor, si se ha corregido un error).
- La configuración no cambiará.

Ejemplos no garantizados:

- Una tabla puede agregar nuevas columnas.
- Las columnas de una tabla pueden reordenarse.
- Las restricciones no únicas pueden eliminarse (comprobaciones a nivel de base de datos, null, valores predeterminados).
- JWT puede agregar nuevas propiedades.

**Menor**

Los cambios en la versión menor garantizan compatibilidad hacia atrás con:

- API REST
- Estructura JWT
- Configuración

Se harán excepciones a estas garantías solo cuando se encuentren problemas de seguridad graves que no puedan remediarse de otra manera.

Ejemplos garantizados:

- Las API existentes pueden quedar obsoletas, pero seguirán funcionando durante las próximas versiones menores.
- Los cambios de configuración pueden quedar obsoletos, pero seguirán funcionando durante las próximas versiones menores.
- Los JWT ya emitidos se aceptarán, pero los nuevos JWT pueden tener una estructura diferente (aunque generalmente similar).

Ejemplos no garantizados:

- Eliminación de campos JWT después de un aviso de obsolescencia.
- Eliminación de ciertas API después de un aviso de obsolescencia.
- Eliminación del inicio de sesión con proveedores externos, después de un aviso de obsolescencia.
- Borrado, truncamiento o cambios significativos de esquema en tablas, índices, vistas y funciones.

Nuestro objetivo es proporcionar un aviso de obsolescencia en los registros de ejecución durante al menos dos versiones mayores o dos semanas si se publican varias versiones. La compatibilidad estará garantizada mientras el aviso esté activo.

**Mayor**

Los cambios en la versión mayor no garantizan ninguna compatibilidad hacia atrás con versiones anteriores.

### Funciones heredadas

Ciertas funciones heredadas de la base de código de Netlify no son compatibles con Supabase y pueden eliminarse sin previo aviso en el futuro. Esta es una lista completa de esas funciones:

1. Multiinquilino mediante la tabla `instances`, es decir, el parámetro de configuración `GOTRUE_MULTI_INSTANCE_MODE`.
2. Usuario del sistema (usuario UUID cero).
3. Superadministrador mediante la columna `is_super_admin`.
4. Información de grupo en JWT mediante `GOTRUE_JWT_ADMIN_GROUP_NAME` y otros campos de configuración.
5. Firma JWT. Supabase Auth admite claves asimétricas (RS256 por defecto; ECC/Ed25519 opcional). HS256 todavía se admite por compatibilidad, pero se recomienda migrar a claves asimétricas para una validación y rotación más fáciles. Las futuras obsolescencias se anunciarán en el changelog. Consulta [Claves de firma JWT](https://supabase.com/docs/guides/auth/signing-keys) y [la guía de JWTs](https://supabase.com/docs/guides/auth/jwts) para más detalles.

Ten en cuenta que esta no es una lista exhaustiva y puede cambiar.

### Buenas prácticas al auto-alojar

Estas son algunas buenas prácticas a seguir al auto-alojar para asegurar la compatibilidad hacia atrás con Auth:

1. No modifiques el esquema administrado por Auth. Puedes ver todas las migraciones en el directorio `migrations`.
2. No te bases en el esquema ni en la estructura de los datos en la base de datos. Usa siempre las API de Auth y los JWT para inferir información sobre los usuarios.
3. Ejecuta siempre Auth detrás de un proxy compatible con TLS, como un balanceador de carga, CDN, nginx u otro software similar.

## Configuración

Puedes configurar Auth usando un archivo de configuración llamado `.env`, variables de entorno o una combinación de ambos. Las variables de entorno tienen el prefijo `GOTRUE_` y siempre tendrán prioridad sobre los valores proporcionados mediante archivo.

### Nivel superior```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string obligatorio

La URL base donde se encuentra tu sitio. Actualmente se usa en combinación con otros ajustes para construir las URLs utilizadas en los correos electrónicos. Cualquier URI que comparta un host con SITE_URL es un valor permitido para los parámetros redirect_to (ver /authorize, etc.).

URI_ALLOW_LIST - string