HttpClientapps/nebula-shell/src/app/app.config.ts registra tokenInterceptor, errorInterceptor y peticionesEnCursoInterceptor con provideHttpClient(withInterceptors(...)).
tokenInterceptorUbicación: libs/shared/data-access/src/lib/auth/token.interceptor.ts.
/login, /refresh, /jwt, /jwt-get o /jwt-select-company.Authorization: Bearer <token> y Accept: application/json.errorInterceptorUbicación: libs/shared/data-access/src/lib/http/error.interceptor.ts.
HttpErrorResponse.AuthService.handle401Error(req, next); errores de otros estados se propagan.En la repetición tras refresh, AuthService coloca Authorization: Bearer ... y AccessToken: ..., porque algunos endpoints del ecosistema esperan la segunda cabecera.
authGuardProtege /layout. Si el access token está vigente, permite entrar salvo que exista cambio obligatorio pendiente; en ese caso dirige a /cambiar-clave. Si está expirado intenta refresh cuando existe refresh token. Sin refresh, o si falla, limpia sesión y manda al login.
mustChangePasswordGuardPermite /cambiar-clave solo si hay sesión activa y la marca must_change_password está pendiente. En otro caso limpia sesión y devuelve al login.
loginGuardEn /login, permite mostrar el formulario cuando no hay sesión válida y limpia datos de una sesión ya vencida. Si la sesión sigue activa, redirige a /layout. También contiene un camino especial para logout=true que limpia local/session storage y cookies del documento.
authGuard verifica autenticación de sesión para /layout; no decide si un usuario puede ejecutar cada acción de negocio. La autorización por recurso/acción se resuelve aparte, mediante AuthorizationStore y la configuración de roles/acciones de Maestros. El backend debe validar operaciones protegidas.