Documentation / Deployment

Identity & Sign-In

How Nexus authenticates every user and machine through your own Microsoft Entra ID tenant using OAuth2 PKCE, inherits your MFA and conditional-access policies, isolates per-user data-source credentials, and works in both commercial and Government (GCC-High) clouds.

Nexus authenticates people and machines through identity you already control. Because each instance runs inside your own Azure subscription, sign-in is wired to your Microsoft Entra ID (Azure AD) tenant, your conditional-access and MFA policies apply unchanged, and access to everything inside Nexus is governed by Nexus role-based access control (RBAC) layered on those identities. This page is for the IT administrator and security reviewer evaluating how users and applications authenticate, what the token actually asserts, and how the model behaves in a Government cloud.

Sign in with Microsoft Entra ID

When Nexus is provisioned, an Entra app registration is created in your tenant. Every interactive user signs in with their existing organizational Microsoft account — the same credentials, conditional access, and multi-factor policies your company already enforces. Nexus never stores, sees, or handles a user's password; that exchange happens directly between the user and Microsoft.

Because the identity provider is your own directory, this is true single sign-on. Users already signed in to Microsoft 365 reach Nexus without re-entering credentials, and disabling a user in Entra ID immediately severs their Nexus access — there is no separate Nexus password to also remember to revoke.

The OAuth2 PKCE flow

User sign-in uses OAuth2 with PKCE (Proof Key for Code Exchange), the modern public-client authorization-code flow, which never puts a client secret on an end-user device:

The desktop app (or a browser) opens the Microsoft sign-in page for your tenant, sending a PKCE code challenge.
The user authenticates against Entra ID, satisfying whatever MFA and conditional-access policies you have configured — device compliance, trusted-location, sign-in-risk, and so on. Nexus does not weaken or bypass any of it; it is simply a relying application.
Entra returns an authorization code, which is exchanged (with the PKCE verifier) for a short-lived access token.
Nexus validates that token — issuer, audience, signature, expiry — on every request. Tokens are short-lived; the desktop client stores them in the OS keyring, never on disk in the clear.

Because policy is enforced at your Entra tenant, you get one control plane for access: tighten a conditional-access rule in Entra and it takes effect for Nexus without any change inside Nexus.

Who the token represents

Nexus reads the standard Entra claims from each validated token — the user's object id (oid), subject, and tenant — and treats that as the authenticated identity for the entire request. Two properties follow, and both are load-bearing for auditing:

Identity comes only from the validated token. Nothing in a request body, path, header, or query can say "act as someone else." There is no impersonation parameter anywhere in the API. A missing or lower-privilege identity can only ever narrow what happens, never widen it.
Every action is attributable. Reports, pipeline runs, MCP tool calls, and data queries all execute as a real, named identity, which is exactly what makes the audit trail meaningful.

Connected apps and automation

Interactive users are not the only callers. Scheduled jobs, integrations, and external tools need to connect with no human present. Nexus issues app credentials for this:

Caller	Identity	Typical use
Interactive user	Entra ID account via OAuth2 PKCE	People using the desktop app, Excel, or a browser
Registered application	App token / API key issued by Nexus	Scheduled pipelines, webhooks, server-to-server integrations

Applications are explicitly registered, can be enabled or disabled, and have their secrets rotated on demand. Critically, an app principal is bound by the same RBAC roles and per-resource grants as a user: a connected app only ever holds the permissions you assign it — least privilege by default, with no ambient authority. The same identity-and-RBAC model governs the embedded MCP server, so an AI agent acts strictly within the permissions of the identity it connects as.

Per-host sign-in and hosted Sites

Nexus can serve hosted Sites and a browser app in addition to the desktop client. Browser sign-in is an Entra SPA (single-page-application) redirect flow, and Entra validates the redirect URI against the app registration's allow-list. This means each host you serve from needs its own registered redirect URI — the default Azure hostname and any custom domain are distinct origins to Entra. The deployment registers the default host automatically, and enabling a custom domain registers the branded host's callback as part of binding it, so browser sign-in works cleanly on both. If you introduce a new host and sign-in returns an Entra redirect-URI error, a missing SPA redirect URI on the app registration is the cause.

Government cloud (GCC-High / Azure Government)

Nexus runs in Azure Government / GCC-High as well as commercial Azure, and a Government deployment is a proven path (a live tenant runs there). The identity wiring differs only in which Microsoft cloud the endpoints point at: a Government deployment authenticates against login.microsoftonline.us rather than the commercial login.microsoftonline.com, and the desktop client and app registration are configured for the Government authority. The model is otherwise identical — OAuth2 PKCE, your MFA and conditional access, token-only identity, the same RBAC. The Nexus container image is the same signed artifact in both clouds (pulled from the publisher's commercial registry, as described in the Marketplace page); only the client-side identity endpoints flip. Note that per-tenant custom domains are a commercial-only convenience and are off in Government.

Credentials to your data sources

Sign-in establishes who you are. Reaching a backing system (a SQL Server, NetSuite, Monday, and so on) requires a connection credential, which Nexus keeps strictly separate from identity and strictly separated by ownership. A connection is a bridge, and every bridge has a scope:

Scope	Owned by	Who can use it
Service bridge	The tenant	Anyone whose RBAC permits the report or pipeline that uses it
User bridge	One individual user	Only that user

Service bridges are managed by administrators and are the right choice for shared, application-level connections. User bridges let an individual supply their own keys — a personal database login or API token — without an administrator ever seeing the value and without any other user being able to use it.

All credential values live in your tenant's Azure Key Vault. The rule across the whole system is absolute: a request can never cause Nexus to resolve another user's credentials. A personal bridge is keyed to its owner's Entra object id, and the single server-side resolver only ever reads the namespace belonging to the authenticated caller. Administrators can configure service bridges and test connections, but Key Vault never echoes a stored secret back — so no one, not even an admin, can read another person's stored credential.

Choosing whose credentials run

Each report and pipeline declares how its data-source credentials resolve at run time:

Mode	Behavior
`service_only` (default)	Always uses the shared service bridge.
`user_only`	Uses the running user's own bridge; fails closed if they have none.
`user_then_service`	Tries the user's bridge, then falls back to the service bridge.

For non-interactive runs (a webhook or a schedule) there is no live human identity, so user_only deliberately fails closed and user_then_service resolves the service bridge. A missing user identity can only narrow access, never widen it — the same one-way property the token model guarantees.

What this does and doesn't do

Nexus is a relying application on your Entra tenant; it enforces your MFA and conditional access but does not define or replace them.
Nexus never holds passwords for users; app credentials it does issue are Nexus-scoped and RBAC-bound, revocable and rotatable at any time.
Identity is token-derived only — there is no impersonation surface anywhere in the API.
Government deployments change only the identity endpoints, not the model.