@sinequa/atomic

Windows and reverse-proxy SSO

When the transport authenticates every request by itself — and why this mode is the only one that lets the server run its challenge.

In this mode nobody signs in: the request arrives already authenticated. Windows integrated authentication through IIS, a reverse proxy injecting a header, an SPFx host attaching an Azure AD token — from the library's point of view they are the same thing, and the mode is called sso.

Your interface renders nothing. At most a loader while the handshake happens.

the whole configuration
import { AuthMode } from "@sinequa/atomic";

client.configure({ authMode: AuthMode.sso() });
await client.auth.login();

What makes this mode different

Every other mode tells the server not to challenge the request. sso is the only one that lets it:

sso anything else a data request authMode noAutoAuthentication: falseserver, run your challenge noAutoAuthentication: trueI carry my own credentials

That flag is what a Windows or proxy deployment needs. Sent as true, the server answers anonymously and the session is never established — which surfaces as a login form in an application that has no password to ask for.

The handshake is a request to a protected endpoint

Fetching a CSRF token cannot establish an ambient session: that call passes suppressErrors=true, which asks the server explicitly not to challenge. Only a plain request to a protected endpoint — the configured probeEndpoint, api/v1/principal by default — makes IIS or the proxy authenticate. See How it works.

Signing in, and staying signed in

An SSO deployment, start to finish
src/main.ts
import { AuthMode, createAtomicClient } from "@sinequa/atomic";

const client = createAtomicClient({
  app: "<your-app>",
  backendUrl: "https://<your-sinequa-server>",
  authMode: AuthMode.sso(),
});

await client.initializeConfig();

if (await client.auth.login()) {
  // There may be no token at all — see below. Do not test getToken().
  const principal = await client.api.principal.get();
  console.log("signed in as", principal.name);
} else {
  // The handshake failed. The mode is left as sso: nothing proved it wrong, and
  // offering a password form for an authentication that has none is a dead end.
  console.error("The server did not authenticate this request.");
}

A session with no token

This is the part that trips up code written against the other modes: an ambient SSO session may hold no CSRF token at all. The server authenticates each request on its own, so there is nothing to store.

isAuthenticated() handles it — it falls back to a stored flag rather than requiring a token. But your own code must not:

wrong, and right
if (getToken()) start();              // wrong: token-less SSO has none
if (client.auth.isAuthenticated()) start();  // right

Pitfalls

What's next

On this page