Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

docker-sso-server

Servidor SSO auto-alojado ligero basado en OAuth2 y OTP. Requiere imagen pre-construida soulteary/sso-server:1.1.6. Ideal para integraciones simples con bajo consumo de recursos (<1% CPU, <15MB RAM).

Ficha actualizada 18 sept 2026, 21:27 · upstream 22 sept 2021, 6:42 · release 1.1.6

Ver códigoProblemas y ayudaRepositorio ↗
00

Qué es docker-sso-server

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

docker-sso-server es un servidor de autenticación único (SSO) diseñado para ser auto-alojado y extremadamente ligero. Su objetivo principal es simplificar los flujos de inicio de sesión mediante OAuth2 y códigos OTP (One-Time Password), actuando como una capa de seguridad entre aplicaciones y usuarios finales. El proyecto destaca por su eficiencia en el uso de recursos, consumiendo menos del 1% de la CPU y aproximadamente 15 MB de memoria RAM en funcionamiento normal.

El servidor proporciona una interfaz gráfica minimalista con cuatro vistas principales: inicio de sesión, autenticación OTP, vinculación de dispositivos y gestión de cuenta. Además, expone varias rutas API para integraciones con servicios externos como Traefik Forward Auth, Outline y otros clientes OAuth2 estándar. La configuración se realiza principalmente mediante variables de entorno (.env), permitiendo definir credenciales, nombres de cliente y parámetros de seguridad sin necesidad de modificar código fuente.

Aunque el proyecto no incluye un Dockerfile ni archivos de compose nativos en el repositorio, está diseñado para ejecutarse sobre imágenes pre-construidas. Esto implica que los usuarios deben descargar la imagen oficial desde un registro externo (soulteary/sso-server) o construir su propia imagen si disponen del código fuente completo. La seguridad se refuerza mediante la generación de un 'fingerprint' único al inicio, que debe coincidir con el valor esperado para garantizar la integridad del binario.

CASOS DE USO
  • Integración como backend de autenticación para Traefik Forward Auth en arquitecturas de contenedores.
  • Proveer autenticación OAuth2 estándar para aplicaciones web que requieren un servidor SSO propio.
  • Implementar autenticación OTP (One-Time Password) para usuarios sin necesidad de configurar LDAP o Active Directory.
  • Servir como punto centralizado de inicio de sesión para múltiples servicios internos en una red local.
PUNTOS DESTACADOS
  • Extremadamente ligero: consumo inferior al 1% de CPU y ~15 MB de RAM en reposo/uso normal.
  • Soporte nativo para autenticación OTP con generación de códigos y vinculación de dispositivos.
  • APIs predefinidas para integraciones comunes (Traefik, Outline, OAuth2 userinfo/token).
  • Configuración simplificada mediante variables de entorno sin necesidad de editar código fuente.
  • Mecanismo de verificación de integridad mediante 'fingerprint' al inicio del servicio.
PRECAUCIONES
  • No incluye Dockerfile ni docker-compose.yml nativos; requiere imagen pre-construida o construcción manual.
  • Soporte limitado a 5 clientes OAuth2 simultáneos mediante variables CLIENT_1_ID hasta CLIENT_5_ID.
  • La autenticación L2TP está planeada pero no implementada en la versión actual.
  • El usuario por defecto es 'username' con contraseña configurable; requiere cambio inicial para producción.
  • No hay documentación detallada sobre gestión avanzada de sesiones o revocación de tokens.
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU1 vCPUrecomendación inicial
MEMORIA1 GBRAM estimada
DISCO10 GBalmacenamiento base
COMPLEJIDADlownivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Despliegue manual

Desplegar usando la imagen oficial soulteary/sso-server:1.1.6 en un contenedor Docker. Asegurar que el puerto 3000 esté mapeado al host y configurar las variables USER_PASS, CLIENT_ID y CLIENT_SECRET obligatoriamente antes del arranque. Verificar el fingerprint de seguridad tras el inicio para confirmar integridad del binario. No es necesario acceso a internet si se restringe el outbound del contenedor mediante herramientas como fruty_docker-outbound-restriction.

—Dockerfile
—Compose
—One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
No detectados
SERVICIOS
No detectados
BASES DE DATOS
No detectadas
PUERTOS
3000
05

Puede sustituir a

Relaciones detectadas por el análisis del repositorio y su categoría.

06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.