Identidad y acceso
El portal es el único que autentica. Los módulos no tienen login: reciben quién eres y con qué token hablar con su propio backend.
Dos puertas
Microsoft (Entra ID) — la que va a usar casi todo el mundo.
Usuario y contraseña — la alternativa, y se queda. No es un resto: el día que el tenant de Microsoft falle es la única forma de entrar, incluida la de quien tendría que arreglarlo.
Cómo funciona el ingreso con Microsoft
Flujo de código de autorización, por el backend. El navegador va a Microsoft, vuelve al backend con un código de un solo uso, y el backend lo canjea usando el secreto de cliente. El front no ve ni el secreto ni los tokens de Microsoft: no valida nada porque no recibe nada que validar.
navegador ──► nexo-hub-backend ──► login.microsoftonline.com
▲ │
└──── código ◄───────────┘
│
└─► canjea el código (TLS, con secreto) ─► identidad
└─► crea el token del portal ─► vuelve al navegador
El tenant va fijo, y nunca es common
Esto es lo más importante de todo el diseño. Con common, el endpoint de
Microsoft acepta cualquier cuenta del mundo —una personal de outlook.com
incluida— y como aquí el usuario se crea solo, eso significa que cualquiera en
internet se da de alta en el portal.
El tenant se comprueba dos veces: en la URL de autorización y contra el
claim tid del id_token. La primera la hace Microsoft; la segunda la hacemos
nosotros.
El alta es automática
Quien entre con una cuenta del tenant y no exista, se crea. Lo que acota el daño
es el rol de estreno: colaborador, no admin (que es el default de la
columna). Quien entra sin módulos ve el portal vacío con un aviso de pedir
acceso, y eso es deliberado.
Dos detalles que parecen raros y no lo son
El state va firmado, no guardado en sesión. Cloud Run corre varias
instancias y la caché es de archivo, local a cada contenedor: lo que escribe una
no lo ve la otra, y fallaría la mitad de los ingresos sin patrón aparente.
Firmado con APP_KEY, cualquier instancia lo verifica sin compartir nada.
No se verifica la firma del id_token. Es correcto aquí: ese token no
vino del navegador, vino de una llamada nuestra al endpoint de Microsoft por
TLS, autenticada con el secreto. No hay nadie en medio. Si algún día llegara por
el navegador, verificarlo contra el JWKS pasa a ser obligatorio.
El emparejamiento es por correo
No por el identificador de Microsoft (oid), que sería más sólido: un correo
liberado puede reasignarse y el nuevo heredaría la cuenta del anterior. Usar
oid pide una columna nueva en una tabla que también lee el módulo de TI, o sea
un despliegue coordinado.
Los tokens del portal
Lo que se guarda en la base es el SHA-256 del token, nunca el token. El valor en claro se muestra una sola vez, al responder el login, y no se puede recuperar. Tienen vencimiento, y desactivar a alguien borra sus sesiones abiertas: sin eso seguiría entrando hasta que el token venciera, que puede ser una semana después.
Lo que falta
La autorización. Ningún backend comprueba roles. El portal sabe leerlos y oculta del menú lo que no corresponde, pero quien escriba la URL del API llega igual, con cualquier cuenta válida. Ocultar una opción no protege nada.