clinch
Clinch es un portal de identidad y SSO autocontenido en Docker, diseñado para simplificar la gestión de usuarios y autenticación en aplicaciones web sin necesidad de mantener cuentas separadas.
Ficha actualizada 23 sept 2026, 13:05 · upstream 23 sept 2026, 12:59 · release sin release detectada
Qué es clinch
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Clinch ofrece una plataforma centralizada para administrar usuarios y permite que cualquier aplicación web se autentique contra él sin gestionar sus propios usuarios. Funciona como un portal de identidad y SSO (Single Sign-On) ligero, autocontenido en un solo contenedor Docker. Utiliza SQLite como base de datos, Solid Queue para el procesamiento de tareas y Solid Cache para la caché compartida. El servidor web Puma ejecuta el bucle de trabajo directamente dentro del contenedor, evitando la necesidad de contenedores adicionales.
Clinch se sitúa en un punto medio entre soluciones de identidad open source excelentes como Authelia, VoidAuth o Authentik. Mientras que Authelia ofrece una gestión externa de usuarios mediante LDAP y una configuración YAML completa, Clinch proporciona una experiencia más integrada con autenticación nativa, interfaz web moderna y capacidades SSO enfocadas (OIDC + ForwardAuth). Es ideal para usuarios que buscan simplicidad sin dependencias externas o complejidades empresariales.
La arquitectura se basa en un único contenedor Docker que contiene SQLite como base de datos, Solid Queue para la cola de tareas y Solid Cache para la caché compartida. El servidor web Puma ejecuta el bucle de trabajo del job queue directamente dentro del contenedor, eliminando la necesidad de contenedores adicionales.
Clinch respalda múltiples protocolos SSO: - **OpenID Connect (OIDC)**: Un proveedor estándar OAuth2/OIDC con endpoints completos para descubrimiento, autorización, tokenización y revocación. Incluye tokens de refresh con rotación automática, familia de tokens con seguimiento avanzado, firmas HMAC-SHA256 y identificadores de sujeto pairwise únicos por aplicación. - **ForwardAuth (SSO Trusted-Header)**: Funciona a través de proxies como Caddy o Traefik, permitiendo que las aplicaciones accedan al portal sin necesidad de cookies ni sesiones. Los tokens API Key (Bearer) funcionan como credenciales para servicios remotos. - **SMTP**: Envío de invitaciones y enlaces de reset de contraseña mediante correo electrónico.
La gestión de acceso se basa en grupos lógicos que definen qué usuarios pueden acceder a cada aplicación, con permisos granulares por rol
- Gestionar múltiples aplicaciones web (MeTube, Kavita, Audiobookshelf) desde un solo lugar sin mantener cuentas separadas por aplicación
- Implementar autenticación centralizada en infraestructuras como Proxmox o Gitea donde no se puede gestionar usuarios manualmente
- Automatizar la creación de usuarios al registrarse en aplicaciones con OAuth2/OIDC mediante tokens de invitación y reset de contraseña
- Permitir acceso diferenciado por roles (admin, editor, lector) a través de grupos lógicos asignados a cada aplicación
- Implementar autenticación sin contraseñas (Passkeys/WebAuthn) para usuarios finales y API Keys para servicios remotos
- Centralizar la gestión de sesiones y revocar accesos individualmente en caso de compromiso o inactividad
- Soportar aplicaciones que requieren acceso a servicios remotos (WebDAV, rclone, etc.) mediante tokens Bearer sin necesidad de cookies ni navegadores
- Soporta convalidación completa contra los tests oficiales de OpenID Connect (670 pruebas, 2600+ assertions)
- Arquitectura monolítica en un único contenedor Docker con SQLite, Solid Queue y Solid Cache
- Sistema de grupos lógicos que permite control granular de acceso por roles y atributos personalizados
- Tokenización avanzada con soporte para tokens de refresh, familia de tokens y revocación
- Soporte nativo de ForwardAuth (SSO Trusted-Header) a través de proxies como Caddy o Traefik
- API Keys (Bearer Tokens) que funcionan como credenciales para servicios remotos sin necesidad de cookies ni navegadores
- La base de datos SQLite no soporta transacciones ACID en modo producción, lo que puede causar inconsistencias si se realizan operaciones concurrentes
- El uso de Solid Cache y Solid Queue dentro del mismo contenedor puede generar cuellos de botella bajo carga extrema
- No incluye autenticación multi-usuario (MFA) ni gestión de usuarios por roles dinámicos
- La configuración de grupos y permisos se realiza manualmente en el admin panel, sin un sistema de roles basado en atributos
- El soporte para aplicaciones que requieren múltiples dominios o certificados SSL independientes no está documentado
Capturas del proyecto
Imágenes reales detectadas en la documentación del repositorio.
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Instala Clinch con `docker run -d --name clinch -p 3000:5870 -e CLINCH_DB=sqlite -v /var/lib/clinch:/data clinch`. El contenedor inicia automáticamente al arrancar. Para producción, considera usar un contenedor de base de datos separado (como PostgreSQL) y migrar el estado de sesión a una tabla externa. En modo desarrollo, la caché compartida puede causar problemas de rendimiento con múltiples instancias del mismo contenedor.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
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.