← Todas las plantillas · Contraseñas e inicio de sesión
Despliega FusionAuth en un clic
Administración de identidades y accesos de clientes: inicio de sesión, registro, inicio de sesión único y MFA para tus apps
Una alternativa autoalojada a Auth0, Okta y Amazon Cognito.
¿Qué es FusionAuth?
FusionAuth es un servidor de administración de identidades y accesos de clientes (CIAM): tus apps web, móviles y de API le delegan el inicio de sesión, el registro y la administración de usuarios. Admite OAuth 2.0, OpenID Connect y SAML 2.0, así que la mayoría de los frameworks se conectan a él con sus bibliotecas estándar, y tiene bibliotecas cliente propias para JavaScript, Python, Java, Go, PHP, .NET, Ruby y más. Sus páginas de inicio de sesión alojadas permiten iniciar sesión con contraseña, con un enlace mágico o con una cuenta social como Google, Apple o Facebook, agregan autenticación de dos factores con una app de autenticación y se pueden personalizar con temas para que se parezcan a tu app.
FusionAuth lo desarrolla FusionAuth, Inc., de Denver, y su plan Community es gratis y sin límite de usuarios; los planes de pago agregan funciones como códigos por correo y SMS, detección de contraseñas filtradas, formularios de registro personalizados y SCIM. No es de código abierto: lo ejecutas bajo la licencia de FusionAuth. Todo está en una sola interfaz de administración y una API REST: aplicaciones, tenants para conjuntos de usuarios separados, roles, grupos, webhooks, configuración de JWT y lambdas que dan forma a los tokens.
Esta plantilla ejecuta la imagen oficial de FusionAuth, versión 1.69.4, con una base de datos Postgres 18 que Nuevo proyecto crea a su lado, o una de las tuyas que elijas, y busca a los usuarios en Postgres, sin Elasticsearch. FusionAuth se inicia primero en un puerto al que nadie llega, donde su administrador se crea con el correo y la contraseña que escribes, así que su asistente de configuración nunca queda abierto a un desconocido. Su correo sale por Resend, SendGrid o Amazon SES, el que elijas en Nuevo proyecto, y no envía ninguno hasta que configures un proveedor en el tenant.
Hosting de FusionAuth en Pethost
- Inicias sesión en Pethost con una passkey, GitHub o Google. ¿Aún no tienes máquina? Eliges un plan, y el enlace espera hasta que esté lista.
- Nuevo proyecto se abre en FusionAuth. Rellenas lo que pide y haces clic en Crear proyecto: Correo electrónico, Contraseña de administrador.
- El correo es opcional: para que FusionAuth lo envíe, eliges Resend, SendGrid o Amazon SES en Nuevo proyecto y pegas lo que te da el proveedor.
- Nuevo proyecto también crea una base de datos nueva para FusionAuth y la conecta antes de que la app arranque por primera vez: Postgres (512 MB). O eliges una de tus bases de datos Postgres: FusionAuth recibe en ella un usuario y una base de datos propios, que las demás apps de allí no pueden leer, y todas las apps que la usan comparten el backup y se restauran juntas.
- En un par de minutos FusionAuth está en marcha en su propia dirección con HTTPS. Sus secretos se generan al azar, y sus datos entran en el backup de cada noche.
- Es un proyecto como cualquier otro: tú o tu agente lo pueden cambiar, volver a una versión anterior o restaurar.
Preguntas sobre FusionAuth
¿FusionAuth es gratis?
El plan Community de FusionAuth es gratis si lo alojas tú, sin límite de usuarios y con las funciones principales: OAuth 2.0, OpenID Connect y SAML, inicio de sesión social, MFA con app de autenticación, temas y la API completa. Los planes de pago agregan códigos por correo y SMS, detección de contraseñas filtradas, formularios de registro personalizados, SCIM y detección de amenazas. FusionAuth se usa gratis, pero no es de código abierto.
FusionAuth frente a Auth0: ¿cuál debería usar?
Los dos inician la sesión de los usuarios con OAuth 2.0, OpenID Connect y SAML, con inicio de sesión social y MFA. Auth0 es un servicio en la nube con precio según los usuarios activos al mes; el plan Community de FusionAuth funciona donde lo alojes, gratis para cualquier número de usuarios, y sus datos se quedan en tu base de datos.
¿Cómo agrego inicio de sesión a mi app con FusionAuth?
Crea una aplicación en la interfaz de administración de FusionAuth y agrega la dirección de callback de tu app como URL de redirección autorizada. Luego tu app envía a los usuarios a la página de inicio de sesión alojada de FusionAuth con una biblioteca de OpenID Connect, usando el ID de cliente y el secreto de la aplicación, y recibe sus tokens.
¿FusionAuth admite inicio de sesión social y passkeys?
Sí. En el plan Community, la sección Identity Providers agrega a la página de inicio de sesión Google, Apple, Facebook, Twitter y cualquier proveedor de OpenID Connect o SAML 2.0. Las passkeys (WebAuthn) necesitan un plan Licensed Community gratuito, que se registra en el portal de cuenta de FusionAuth.
¿FusionAuth puede migrar usuarios desde Auth0 o Firebase?
Sí. Su User Import API acepta los hashes de contraseña existentes, así que los usuarios conservan sus contraseñas, y FusionAuth documenta migraciones desde Auth0, Amazon Cognito, Firebase, Keycloak y otros.
¿Cuánta memoria y disco necesita FusionAuth?
FusionAuth funciona con Java: unos 600–800 MB de memoria en reposo, junto a su Postgres de 512 MB, y más con muchos usuarios e inicios de sesión; su base de datos crece despacio, con los usuarios y el historial de sus inicios de sesión. Nuevo proyecto da a cada base de datos de la app la memoria que recomienda la plantilla, salvo que la cambies: Postgres (512 MB). En Pethost le basta el plan Starter, y queda sitio para otras apps a su lado.
El archivo Docker Compose de FusionAuth
La plantilla es este compose.yaml y las variables que se escriben en el .env del proyecto al crearlo. Pethost ejecuta el archivo tal como está escrito. La máquina escribe allí cómo inicia sesión la app en sus bases de datos, al conectarlas. Nuevo proyecto escribe los ajustes de correo elegidos en él, o los deja vacíos si la app no envía correo.
Contenedores: fusionauth (fusionauth/fusionauth-app:1.69.4).
Bases de datos, cada una un proyecto propio: Postgres (512 MB).
services:
fusionauth:
image: fusionauth/fusionauth-app:1.69.4
restart: unless-stopped
environment:
# FusionAuth reads DATABASE_URL as a JDBC URL, so it is made here from the part's parts.
DATABASE_URL: jdbc:postgresql://${DATABASE_HOST:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}:${DATABASE_PORT:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}/${DATABASE_NAME:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
DATABASE_USERNAME: ${DATABASE_USER:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
DATABASE_PASSWORD: ${DATABASE_PASSWORD:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
# Silent mode makes the schema in the linked database, which the app's user owns, and
# applies a new release's migrations at its start; production mode never shows the
# migration screen to a visitor.
FUSIONAUTH_APP_SILENT_MODE: "true"
FUSIONAUTH_APP_RUNTIME_MODE: production
# Users are searched in Postgres, with no Elasticsearch or OpenSearch beside it.
SEARCH_TYPE: database
FUSIONAUTH_APP_MEMORY: 512M
# 20 connections at most, FusionAuth's default, within the 47 of the Postgres part.
DATABASE_MAXIMUM_POOL_SIZE: "20"
URL: ${URL}
ADMIN_EMAIL: ${ADMIN_EMAIL}
ADMIN_PASSWORD: ${ADMIN_PASSWORD}
SETUP_API_KEY: ${SETUP_API_KEY}
# The mail provider picked in New project, by STARTTLS on its port; with none, FusionAuth
# sends no mail until one is set on the tenant.
SMTP_HOST: ${SMTP_HOST}
SMTP_PORT: ${SMTP_PORT}
SMTP_USER: ${SMTP_USER}
SMTP_PASSWORD: ${SMTP_PASSWORD}
SMTP_FROM: ${SMTP_FROM}
SMTP_FROM_NAME: ${SMTP_FROM_NAME}
# A new FusionAuth shows its setup wizard to whoever opens it first, also in the seconds
# before Kickstart has run, and counts the setup as done only when Kickstart made the
# administrator. So FusionAuth runs first on port 9019, which nobody reaches, and only then on
# port 9011, the page's. On a new database, Kickstart makes the set-up's API key and the
# administrator, with a stand-in email and password, and gives the default tenant the
# project's address as its issuer; the API then gives the administrator the email and
# password of the fields, and the tenant the mail provider, since Kickstart takes a quote or
# a backslash out of what it is given. The set-up's key is deleted last: while it answers,
# the set-up is unfinished, and once it is refused and the setup wizard sends a visitor to
# sign in, FusionAuth is set up.
command:
- bash
- -c
- |
set -e
cd /usr/local/fusionauth
json() { printf '%s' "$$1" | sed -e 's/\\/\\\\/g' -e 's/"/\\"/g'; }
# The set-up's API key, and the ids of it and of the administrator, all from SETUP_API_KEY.
key=$$SETUP_API_KEY
key_id=$${key:0:8}-$${key:8:4}-$${key:12:4}-$${key:16:4}-$${key:20:12}
admin_id=$${key:32:8}-$${key:40:4}-$${key:44:4}-$${key:48:4}-$${key:52:12}
# Kickstart runs only on a FusionAuth with no API key and no user yet.
cat > /tmp/kickstart.json <<KICKSTART
{
"apiKeys": [{"id": "$$key_id", "key": "$$key", "keyManager": true, "description": "The template's set-up"}],
"requests": [
{"method": "PATCH", "url": "/api/tenant/#{FUSIONAUTH_TENANT_ID}", "body": {"tenant": {"issuer": "$$URL"}}},
{
"method": "POST",
"url": "/api/user/registration/$$admin_id",
"body": {
"user": {"email": "[email protected]", "password": "$$key"},
"registration": {"applicationId": "#{FUSIONAUTH_APPLICATION_ID}", "roles": ["admin"]}
}
}
]
}
KICKSTART
FUSIONAUTH_APP_HTTP_PORT=9019 FUSIONAUTH_APP_KICKSTART_FILE=/tmp/kickstart.json fusionauth-app/bin/start.sh &
first=$$!
stop_first() {
kill $$first
wait $$first 2> /dev/null || true
}
api() {
method=$$1
path=$$2
shift 2
curl -sS -o /tmp/api.json -w '%{http_code}' -X "$$method" -H "Authorization: $$key" \
-H 'Content-Type: application/json' "$$@" "http://127.0.0.1:9019$$path" 2> /dev/null || true
}
refused() {
echo "FusionAuth refused $$1: $$(cat /tmp/api.json)" >&2
stop_first
exit 1
}
# Silent mode migrates the database first; a database that does not answer stops the
# start after 5 minutes, and the next start tries again.
for wait in $$(seq 300); do
kill -0 $$first 2> /dev/null || { echo "FusionAuth stopped at its first start." >&2; exit 1; }
admin=$$(api GET "/api/user/$$admin_id")
[ "$$admin" = 200 ] && break
wizard=$$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:9019/admin/setup-wizard || true)
[ "$$admin" = 401 ] && [ "$$wizard" = 302 ] && break
sleep 1
done
if [ "$$admin" != 200 ] && [ "$$wizard" != 302 ]; then
echo "FusionAuth did not answer on its first start within 5 minutes." >&2
stop_first
exit 1
fi
if [ "$$admin" = 200 ]; then
echo "setting FusionAuth up on a port nobody reaches"
tenant=$$(grep -o '"tenantId":"[^"]*"' /tmp/api.json | head -n 1 | cut -d '"' -f 4)
if [ "$${#ADMIN_PASSWORD}" -lt 8 ]; then
echo "The admin password has fewer than 8 characters, which FusionAuth refuses: give one of 8 or more in ADMIN_PASSWORD of the project's .env, then deploy again." >&2
stop_first
exit 1
fi
[ "$$(api PATCH "/api/user/$$admin_id" \
-d "{\"user\": {\"email\": \"$$(json "$$ADMIN_EMAIL")\", \"password\": \"$$(json "$$ADMIN_PASSWORD")\"}}")" = 200 ] \
|| refused "the administrator's email and password"
if [ -n "$$SMTP_HOST" ]; then
[ "$$(api PATCH "/api/tenant/$$tenant" -d "{\"tenant\": {\"emailConfiguration\": {\"host\": \"$$(json "$$SMTP_HOST")\",
\"port\": $$SMTP_PORT, \"security\": \"TLS\", \"username\": \"$$(json "$$SMTP_USER")\", \"password\": \"$$(json "$$SMTP_PASSWORD")\",
\"defaultFromEmail\": \"$$(json "$$SMTP_FROM")\", \"defaultFromName\": \"$$(json "$$SMTP_FROM_NAME")\"}}}")" = 200 ] \
|| refused "the mail provider"
fi
# The set-up's API key can do anything, and nothing needs it any more.
[ "$$(api DELETE "/api/api-key/$$key_id")" = 200 ] || refused "to delete the set-up's API key"
echo "FusionAuth is set up, with the administrator $$ADMIN_EMAIL"
fi
stop_first
rm /tmp/kickstart.json
exec fusionauth-app/bin/start.sh
healthcheck:
test: ["CMD", "curl", "-fsS", "-o", "/dev/null", "http://127.0.0.1:9011/api/status"]
interval: 10s
timeout: 5s
retries: 30
start_period: 300s
Más en Contraseñas e inicio de sesión
- VaultwardenUn servidor de contraseñas para las apps de Bitwarden
- AuthorizerInicio de sesión para tus propias apps, con OAuth 2 y OpenID Connect
- Password PusherComparte contraseñas y secretos con enlaces que caducan
- authentikUn proveedor de identidad para el inicio de sesión único en tus apps: OpenID Connect, SAML, LDAP, MFA y passkeys
- KeycloakAdministración de identidades y accesos de código abierto: inicio de sesión único para tus apps con OpenID Connect y SAML