El impuesto del SSO en software autohospedado

Qué es el impuesto del SSO

El impuesto del SSO en el software autohospedado es el patrón por el que la aplicación es gratuita, pero el inicio de sesión único (SSO) es la única función que debe comprar. Puede ejecutar todo en su propio VPS sin una clave de licencia ni un límite de usuarios. Después abre la página de autenticación de la documentación y encuentra OpenID Connect (OIDC) o SAML (security assertion markup language) dentro de un plan de pago.

Esto importa más que una función normal bloqueada tras un pago, porque el SSO permite que un conjunto de servicios autohospedados se comporte como un solo sistema. Un proveedor de identidad (IdP) le proporciona una cuenta por persona, una política de contraseñas, un único lugar para activar la autenticación multifactor (MFA) y un único lugar para desactivar el acceso de un usuario. Sin SSO, cada aplicación mantiene su propia base de datos pequeña de usuarios y usted debe administrar cada una manualmente.

Este patrón es lo bastante antiguo como para tener un registro público. SSO Wall of Shame, en sso.tax, enumera proveedores que cobran un recargo elevado por el inicio de sesión único. Incluye entradas desde 2018 y su autor establece un criterio razonable: "Si su compatibilidad con SSO supone un aumento de precio del 10%, no aparece en esta lista". La mayor parte de esa lista corresponde a software cerrado. La misma lógica de precios aparece ahora en proyectos de código abierto que se alojan en servidores propios.

Por qué los mantenedores incluyen el inicio de sesión único en un nivel de pago

Hay dos motivos y ambos son legítimos. El SSO es caro de mantener y es una de las pocas funciones por las que una organización grande está dispuesta a pagar.

El coste de soporte es real porque una integración de identidad nunca está terminada. Cada IdP da un formato ligeramente distinto a sus claims. La asignación de grupos, la duración de la sesión, las URL de redirección y la desviación del reloj pueden provocar errores de inicio de sesión. Además, un error de inicio de sesión bloquea a todos los usuarios a la vez, por lo que esos tickets son urgentes. Después llegan las solicitudes adicionales: grupos anidados, asignación de roles, aprovisionamiento automático con SCIM (system for cross-domain identity management) y registros de auditoría que revisará el equipo de cumplimiento.

Los ingresos dependen de una cuestión aritmética, no de la mala intención. Una empresa que no pueda conectar la aplicación con su propio IdP no la implementará en absoluto. Por eso el SSO marca una separación clara entre el usuario que paga y el que no paga. Un proyecto open core tiene que situar esa separación en algún punto. El SSO encaja mejor que casi cualquier otra función, por lo que muchos proyectos lo eligen.

Hay que corregir una queja habitual: consulte el changelog antes de asumir que se ha retirado una función, porque una eliminación aparece en las notas de la versión. En los proyectos que revisé para esta publicación, las funciones de SSO de pago se desarrollaron para el nivel de pago desde el principio. No encontré ningún caso en el que se retirara un SSO gratuito que ya funcionara. Grafana es un ejemplo típico. Su página de SAML incluye una nota de una sola línea: "Available in Grafana Enterprise and Grafana Cloud", mientras que OAuth genérico contra su propio issuer funciona en la compilación open source.

El coste real del SSO

El dinero es la parte menor. Los planes de pago se venden por usuario, por lo que la factura crece con el equipo mientras el alojamiento y las actualizaciones siguen siendo responsabilidad suya.

El coste mayor es el trabajo manual de gestión de identidades, y aparece en cuatro áreas.

• Un almacén de contraseñas por aplicación, de modo que una contraseña reutilizada abre una brecha en todas las aplicaciones que la comparten.
• La baja de usuarios basada en la memoria. Tiene que recordar todos los servicios que utilizaba una persona, y el que olvide será el que importe.
• MFA configurado aplicación por aplicación, cuando la aplicación lo admite.
• Inicios de sesión compartidos, que es lo que realmente ocurre en equipos pequeños sometidos a esta presión.

Este último punto merece una frase aparte. Cuando un equipo comparte una cuenta de administrador en un gestor de documentos, el registro de auditoría muestra un solo nombre para todo, por lo que no puede saber quién eliminó la factura. Los permisos por usuario también dejan de funcionar, porque sólo existe un usuario. Ese es el daño real del coste del SSO: empuja a los equipos pequeños hacia una única cuenta compartida, que es peor que cualquiera de las alternativas.

La lista de comprobación que debe ejecutar antes de adoptar cualquier aplicación

Ejecute esta comprobación antes de docker compose up, no después de que la aplicación almacene 400 documentos.

1. Abra la página de autenticación de la documentación y lea la nota sobre el nivel que aparece al principio. Las funciones de pago tienen una insignia o una frase de disponibilidad de una línea.
2. Confirme que la aplicación se comunica mediante OIDC o SAML con su propio emisor, en lugar de hacerlo con una lista fija de proveedores públicos.
3. Compruebe la asignación de roles y grupos. Crear el usuario es sólo la mitad del trabajo. Asignar permisos manualmente en diez aplicaciones es la otra mitad, y es la que causa problemas.
4. Compruebe si la aplicación acepta en una cabecera el nombre de usuario autenticado enviado por un proxy de confianza y si puede fijar qué proxy considera de confianza.
5. Lea el historial de licencias en git y compruebe si los colaboradores firman un CLA (acuerdo de licencia de colaboradores).
6. Compruebe el proceso de baja. Averigüe qué ocurre con los tokens de API (interfaz de programación de aplicaciones) y las sesiones activas cuando se deshabilita la cuenta del IdP.

El punto 2 es donde se producen la mayoría de las decepciones. Un botón "Iniciar sesión con Google" no es OIDC con su proveedor de identidad. Es una integración fija con un único proveedor. La compatibilidad real le solicita una URL de emisor. Todo lo demás procede del descubrimiento. Puede confirmar la configuración del proveedor con un solo comando.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Un proveedor que funciona devuelve tres URL. Un resultado vacío o un 404 suele indicar que la ruta de descubrimiento es incorrecta. Esa ruta depende del proveedor: Keycloak la publica en /realms/<realm>/.well-known/openid-configuration. Si la aplicación no tiene ningún campo para una URL de emisor, no puede comunicarse con su IdP, independientemente de lo que indique la lista de funciones.

El punto 6 afecta a muchas personas semanas después de que alguien abandone la organización. Deshabilitar la cuenta en el IdP impide nuevos inicios de sesión. No revoca un token de API que la aplicación haya emitido antes, porque la aplicación valida ese token por su cuenta y nunca consulta al IdP. Por tanto, el proceso de baja tiene dos pasos: deshabilitar la cuenta en el IdP y después eliminar el usuario o sus tokens dentro de cada aplicación.

Lo que realmente indican las insignias de nivel

Estas afirmaciones se comprobaron en la documentación de cada proyecto en agosto de 2026. Empecemos por las opciones de pago.

Grafana publica SAML como «Available in Grafana Enterprise and Grafana Cloud», junto con la sincronización de equipos y el aprovisionamiento SCIM. OAuth genérico, GitHub OAuth, LDAP (protocolo ligero de acceso a directorios) y el proxy de autenticación están disponibles en la compilación de código abierto, por lo que un administrador de un servidor pequeño todavía puede iniciar sesión mediante su propio proveedor. La función de pago empieza en SAML, no en el inicio de sesión único en general. Esta es la distinción que la expresión «impuesto por SSO» suele ocultar.

Metabase es más directo. Su documentación indica: «SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).» La edición de código abierto mantiene el inicio de sesión mediante contraseña y LDAP.

Passbolt clasifica su documentación de SSO como Pro y Cloud, por lo que la edición comunitaria no incluye esta función. Los proveedores documentados incluyen Keycloak y Entra ID.

Ahora, el otro lado, porque este patrón no es universal.

• GitLab Self-Managed muestra «Tier: Free, Premium, Ultimate» en su página de SAML, por lo que usar SAML con tu propio GitLab no tiene coste.
• Paperless-ngx configura OIDC mediante django-allauth con PAPERLESS_SOCIALACCOUNT_PROVIDERS, oculta el formulario de inicio de sesión local con PAPERLESS_DISABLE_REGULAR_LOGIN y asigna las claims a grupos con PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka acepta OIDC_ISSUER, OIDC_CLIENT_ID y OIDC_CLIENT_SECRET, establece openid profile email como ámbitos predeterminados y convierte a los usuarios en administradores a partir de una claim de rol con OIDC_ADMIN_ROLES.
• BookStack activa esta función con AUTH_METHOD=oidc y después asigna los grupos del proveedor a sus propios roles con OIDC_USER_TO_GROUPS=true y OIDC_GROUPS_CLAIM.
• Vaultwarden incorporó «support for SSO with OpenID Connect» en 1.35.0, el 27 de diciembre de 2025, mediante una pull request de un colaborador que había mantenido la función en un fork.
• listmonk incluye el inicio de sesión mediante OIDC junto con sus roles de usuario desde v4.0.0.

Tenlo en cuenta al elegir, no después de haber tomado la decisión. Un tablero kanban de Planka y las demás alternativas autoalojadas a Trello no gestionan la identidad de la misma forma. Lo mismo ocurre con BookStack, Wiki.js y Outline. El OIDC gratuito es una función que puedes valorar igual que los límites de almacenamiento o las aplicaciones móviles. Si todavía estás preparando la lista, qué autoalojar en 2026 es un punto de partida razonable. Tanto el gestor de documentos Paperless-ngx como Vaultwarden ofrecen OIDC gratuito actualmente.

Por qué un reverse proxy delante de la aplicación no es single sign-on

La solución habitual es usar forward auth. El reverse proxy retiene cada petición, consulta a un servicio de autenticación si ese navegador tiene una sesión iniciada y sólo entonces reenvía la petición a la aplicación. authentik lo denomina proxy provider y ofrece un modo forward auth para una sola aplicación y otro para todo un dominio. Authelia y oauth2-proxy realizan la misma función.

Un bloque de sitio de Caddy tiene este aspecto, siguiendo el ejemplo del propio authentik.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

En Caddy, las mayúsculas y minúsculas de esos nombres de cabecera son importantes, porque un nombre que no coincide llega vacío. En cada petición que aprueba, el outpost establece X-authentik-username, X-authentik-email, X-authentik-groups y algunos valores más.

Esto es lo que se consigue. Nadie llega a la aplicación sin pasar primero por el proveedor de identidad. Por tanto, un formulario de inicio de sesión sin parchear deja de estar expuesto a Internet y MFA se aplica de una vez a todo lo que está detrás del proxy.

Esto es lo que no se consigue: la identidad dentro de la aplicación. La aplicación sigue teniendo sus propias cuentas y su propia representación de quién tiene una sesión iniciada. Si todos pasan el proxy y llegan a una única cuenta de administrador compartida, tiene una puerta de entrada sólida y una sesión anónima detrás de ella. El registro de auditoría sigue mostrando un solo nombre. Los permisos tampoco pueden diferenciarse entre usuarios. Llamar SSO a esta configuración es un error de seguridad, porque el proceso de baja sólo es parcialmente efectivo: eliminar a la persona del IdP cierra la puerta de entrada, pero un token de API que haya creado dentro de la aplicación sigue funcionando para cualquiera que pueda acceder directamente a ella.

Hacer segura la autenticación mediante cabeceras

Algunas aplicaciones aceptan un nombre de usuario del proxy. Esto proporciona una identidad por usuario sin pagar por SSO. El ajuste tiene un nombre diferente en cada proyecto.

Grafana lo denomina auth proxy y se distribuye desactivado. El nombre de la cabecera predeterminado es X-WEBAUTH-USER, y puede indicarle cualquier cabecera que establezca el proxy.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist es la línea que se suele omitir. La documentación de Grafana indica claramente que existe para impedir que los usuarios falsifiquen la cabecera. Por tanto, sólo debe contener la dirección del proxy. Gitea ofrece la misma función con otros nombres y se distribuye con un valor predeterminado más seguro.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES tiene el valor predeterminado 127.0.0.0/8,::1/128, y REVERSE_PROXY_LIMIT indica cuántos proxies confiará Gitea en la cadena. Establecer ese límite en cero desactiva por completo el tratamiento de la cabecera.

Paperless-ngx ofrece PAPERLESS_ENABLE_HTTP_REMOTE_USER mediante PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. Su documentación incluye esta advertencia, que debe aplicarse a todos estos ajustes:

Esto permitirá autenticarse simplemente añadiendo una cabecera Remote-User: <username> a una petición. Úselo con cuidado.

Dos reglas mantienen segura la autenticación mediante cabeceras, y ambas dependen de la accesibilidad. Primero, la aplicación debe ser inaccesible salvo a través del proxy. Cualquiera que pueda abrir un socket hacia ella puede enviar esa cabecera y asumir la identidad de cualquier usuario. En Docker, ports: ["8000:8000"] publica en todas las interfaces. Vincúlelo a la dirección de loopback con ports: ["127.0.0.1:8000:8000"], o elimine el puerto publicado y coloque el proxy en la misma red de Docker. Segundo, el proxy debe eliminar cualquier copia de la cabecera que llegue del cliente. Así, el único valor que verá la aplicación será el que establezca el proxy después de autenticar al usuario.

Compruebe ambos puntos. Ejecute el primer comando desde una máquina externa a su VPS y el segundo directamente en el servidor.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

curl debería fallar al conectarse, y ss debería mostrar 127.0.0.1:8000 en lugar de 0.0.0.0:8000. Una primera línea con HTTP/1.1 302 Found significa que la aplicación responde directamente en Internet pública. En ese caso, cualquiera puede iniciar sesión como cualquier usuario indicando su nombre en una cabecera.

Decida en lugar de quejarse cuando no haya SSO gratuito

Cuatro opciones, en el orden en que las probaría.

1. Elija la aplicación que incluya OIDC. Si dos proyectos hacen el mismo trabajo y uno se comunica gratuitamente con su proveedor de identidad, esa es una diferencia real en el coste operativo.
2. Use forward auth de forma honesta. Para una herramienta de administración con una cuenta y un operador, basta con colocar un proxy delante. La identidad de cada usuario dentro de la aplicación no aporta nada.
3. Pague. Si la aplicación es esencial para su trabajo y el precio por usuario se ajusta al tamaño de su equipo, ese dinero mantiene el proyecto y la alternativa consiste en pagarlo con sus tardes.
4. Pregunte al equipo del proyecto, después de buscar en el gestor de incidencias. La compatibilidad con OIDC de Vaultwarden llegó mediante un fork de un colaborador y una pull request que se mantuvo durante mucho tiempo. Por tanto, una solicitud de funcionalidad respaldada por una implementación operativa puede llegar a incluirse en la edición gratuita.

Nada de esto funciona sin un proveedor de identidad propio, que es el componente que debe crear primero. Ejecutar authentik en un VPS le proporciona un proveedor OIDC y SAML, además del outpost de forward auth utilizado anteriormente. La comparación de Keycloak, authentik y Zitadel explica las diferencias si prefiere no comprometerse todavía.

Historial de licencias y por qué aparece en la lista de comprobación

El último elemento de la lista de comprobación trata sobre el futuro, porque la estructura de niveles actual es sólo una instantánea. Dos casos bien documentados muestran lo rápido que puede cambiar la situación, en ambas direcciones. HashiCorp adoptó la Business Source License 1.1 para todas las versiones futuras el 10 August 2023, mientras que las versiones anteriores siguieron bajo MPL 2.0 (Mozilla Public License). Redis cambió a SSPL (server side public license) en March 2024 y después anunció el 1 May 2025 que Redis 8 también se distribuye bajo AGPLv3 (GNU Affero General Public License).

Considere ambos casos como pruebas sobre el mecanismo, no sobre la motivación. La licencia que lee hoy se aplica a la versión que instala hoy, y un proyecto que conserva todos los derechos de autor puede cambiar por sí solo las condiciones de la siguiente versión. Por eso la pregunta sobre el CLA aparece en la lista de comprobación: la cesión amplia de los derechos de autor es lo que permite relicenciar el proyecto de forma unilateral.

Compruebe personalmente el historial de un proyecto antes de basarse en él.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Una lista breve de commits, principalmente del primer import, es una buena señal. Varias reescrituras del archivo de licencia indican que debe leer el mensaje de cada commit antes de planificar basándose en las condiciones actuales.

FAQ

¿Qué es el impuesto por SSO?

El impuesto por SSO consiste en cobrar el inicio de sesión único como una función premium, mientras el resto del producto es gratuito o barato. En el software autoalojado, se presenta como una aplicación de código abierto que puede ejecutarse sin una clave de licencia, pero cuyo inicio de sesión mediante OIDC o SAML sólo está disponible en un nivel de pago. El nombre procede de SSO Wall of Shame, en sso.tax, que registra a los proveedores que cobran un importe elevado por esta función. Para quien autoaloja servicios, la consecuencia es que cada aplicación mantiene su propia base de datos de usuarios, por lo que las cuentas se crean y eliminan manualmente.

¿La autenticación delegada mediante un proxy inverso es lo mismo que SSO?

No. La autenticación delegada protege la entrada: el proxy consulta al proveedor de identidad antes de que cualquier petición llegue a la aplicación. La aplicación sigue utilizando sus propias cuentas, por lo que, si todos acceden con un único inicio de sesión compartido, se obtiene una sola sesión anónima y un registro de auditoría con un único nombre. Sólo existe una identidad real por usuario cuando la aplicación lee el nombre de usuario desde una cabecera. Grafana con auth proxy, la autenticación mediante proxy inverso de Gitea y PAPERLESS_ENABLE_HTTP_REMOTE_USER de Paperless-ngx pueden hacerlo. Estas opciones sólo son seguras mientras no sea posible acceder a la aplicación excepto a través del proxy, porque la cabecera es una cadena de texto sin protección que cualquier cliente puede enviar.

¿Qué aplicaciones autoalojadas incluyen OIDC en la edición gratuita?

Comprobado en la documentación de los proyectos en agosto de 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk y Vaultwarden admiten OIDC en sus versiones gratuitas, y GitLab Self-Managed incluye SAML en el nivel Tier: Free. La versión de código abierto de Grafana admite OAuth genérico con su propio emisor, mientras que SAML es una función Enterprise. Confirme la información en la página de autenticación del propio proyecto antes de instalarlo, porque estas listas cambian con las versiones publicadas.

¿Debería pagar por el nivel que habilita el inicio de sesión único?

Decídalo con 2 cifras: cuántas personas necesitan cuentas y cuántas aplicaciones tendría que mantener manualmente. Para uno o 2 administradores, la autenticación delegada delante de una cuenta local es suficiente y el nivel de pago aporta poco. En un equipo donde las personas se incorporan y salen, una cuenta que no se desactive durante la baja puede costar más que la licencia, y el pago financia el mantenimiento del que depende. Si el precio no encaja, la opción práctica es elegir una aplicación que incluya OIDC en lugar de buscar soluciones alternativas para una que no lo incluya.