Qué es, y qué no es
dev-identity-server resuelve una cosa concreta: poner un login de Google delante de un panel
interno que por sí solo no tiene autenticación. Hoy su único consumidor es el monitor de colas de
notification-api, y está pensado para que haya más.
No es un sistema de identidad de usuarios finales. Los usuarios de PetID no pasan por aquí — esos
los gestiona petid-api con su propio login. Este servidor es para ti y para quien administre.
Dos anomalías que verás enseguida
No es NestJS. Es Express puro, 7 ficheros, unas 420 líneas. Es el único servicio del ecosistema que no sigue el patrón de los demás, y para lo que hace es proporcionado: no tiene entidades, ni capas, ni casi dependencias.
No tiene base de datos. auth.model.ts es un array en memoria con la forma de un repositorio:
const users: IUser[] = [];
export const UserModel = {
async findOne(query: Partial<IUser>): Promise<IUser | null> { /* ... */ },
async create(data: Omit<IUser, "id">): Promise<IUser> { /* ... */ },
// ...
};
Es deliberado, no deuda pendiente. Las sesiones que emite son para usuarios concretos en situaciones concretas, no un servicio de sesión de propósito general. Pero conviene conocer lo que implica antes de apoyar algo nuevo en él:
- Un reinicio cierra todas las sesiones. Cada despliegue obliga a volver a entrar.
- Una sesión por usuario. Solo se guarda un
refreshTokenpor persona, así que entrar desde un segundo navegador invalida el primero. - No se puede replicar. Dos instancias tendrían arrays distintos. Es instancia única por diseño, y de ahí viene la recomendación de dejar siempre un camino de entrada alternativo —ver cómo proteger un panel.
El control de acceso no está en el repo
Esto es lo más importante de esta página, porque leyendo solo el código parece que no existe:
let user = await UserModel.findOne({ googleId });
if (!user) {
user = await UserModel.create({ googleId, email, name, avatar });
}
No hay lista de emails permitidos, ni comprobación de dominio. La puerta la cierra la consola de Google: la aplicación OAuth está en modo prueba, y ese modo solo deja completar el flujo a los usuarios de prueba dados de alta ahí.
Condición a recordar: ese control vive fuera del repositorio y fuera del despliegue. Si algún día la aplicación OAuth se publica, la lista deja de aplicar y cualquier cuenta de Google podría completar el login. Publicarla exige sustituir ese control por uno dentro del servicio.
El ALLOWED_REDIRECT_URIS que sí está en el código resuelve un problema distinto —a dónde puede
volver el navegador, no quién entra—. Ver
las dos defensas del flujo.
Lo que sí hay
/auth/googley/auth/google/callback— el ida y vuelta con Google./auth/refresh,/auth/check-token,/auth/logout— el ciclo de la sesión propia./health— lo que sondea un monitor externo.- Helmet, CORS por lista,
trust proxy: 2(Nginx y Cloudflare por delante) y límite de 100 peticiones cada 15 minutos, solo sobre/auth. - Validación de entorno estricta: si falta una variable, el proceso sale con código 1 en vez de arrancar a medias.