libs/login/src/index.ts publica LOGIN_ROUTES, LoginService, componentes y rutas de activación/recuperación/cambio de clave. libs/shared/data-access/src/index.ts publica AuthService, guards, interceptores, tokens de configuración y TokenBridgeService.
Los consumidores deberían importar por alias (@nebula/login, @nebula-shared/data-access) y evitar rutas profundas libs/.../src/lib/....
apps/nebula-shell/src/app/app.routes.ts monta las rutas:
LOGIN_ROUTES en login, con loginGuard.ACTIVAR_ROUTES en activar-usuario, pública.RECUPERAR_ROUTES en recuperar, pública.CAMBIAR_CLAVE_ROUTES en cambiar-clave, con mustChangePasswordGuard.LayoutComponent en layout, con authGuard.La app está preparada para lazy routes aunque actualmente entrega algunas con Promise.resolve(routes).
app.config.ts registra provideHttpClient(withInterceptors([tokenInterceptor, errorInterceptor, peticionesEnCursoInterceptor])). También provee API_BASE_URL_TOKEN y AUTH_CONFIG_TOKEN con el apiBaseUrl del perfil de entorno (getEnvProfile()). Login añade el header x-simappe-environment mediante resolveEnvKey().
No registrar de nuevo interceptores o tokens si la app ya usa este appConfig. En otra aplicación que consuma estas librerías, configurar HttpClient/interceptores y los tokens que use el perfil correspondiente.
LoginService es dueño de la petición de credenciales y el mapeo de errores. AuthService es dueño de la sesión y tokens. El componente debe coordinar estados UI y navegación; no guardar tokens directamente desde el componente.
HttpService o el cliente común de la aplicación.tokenInterceptor agregue bearer; no concatenar manualmente el access token salvo si el contrato específico lo exige.errorInterceptor delegue 401 para refresh.Confirmar en el contrato OAuth2: estructura de AuthContent, unidad de expiresIn, validez y rotación del refresh token, cabeceras aceptadas por endpoints, y respuestas de logout/refresh. El frontend calcula token_expiry según la duración recibida; una discrepancia de unidades rompería el refresh automático.