Documentation / Security & Compliance

Identity & Access

How Nexus authenticates and authorizes every principal — Entra ID with OAuth2 PKCE, scoped app tokens and API keys, request signing with single-use replay prevention, near-real-time revocation, and a granular per-resource RBAC and execution-role model.

This page is for identity and access reviewers. It covers how Nexus authenticates users and automation, how requests are protected against replay, how access is revoked, and how the RBAC and execution-role model bounds what any principal — human or machine, including AI agents — can do. Administration mechanics for these controls live under Roles & RBAC, Execution Roles, and Users; this page is the security rationale.

Authentication is Microsoft Entra ID

Nexus does not run its own identity store. Authentication is Microsoft Entra ID, so users sign in with your organization's existing identities and inherit your existing policies — conditional access, MFA, sign-in risk, device compliance — with no parallel credential system to manage or attack.

Users authenticate via OAuth2 with PKCE. PKCE binds the authorization code to the client that requested it, closing the code-interception attack that plagues public clients.
Automation and applications authenticate with scoped application tokens or API keys. These carry only the scopes the application was granted and are subject to the same RBAC as any other principal.
The desktop client stores tokens in the OS keyring — never in plaintext files, never in page JavaScript, never in local storage reachable by a web context.

Request signing with single-use replay prevention

Sensitive operations are protected by request signing. A signed request carries a unique identifier (a JTI/UTI-style nonce) that Nexus records and enforces as single-use: a captured request cannot be replayed, because the second presentation of the same identifier is rejected. This defends the high-value endpoints against a replay attacker who has captured a valid signed request on the wire or in a log.

The signing keys live in your per-tenant Key Vault, are cached in-process with a short (5-minute) TTL behind a circuit breaker, and are rotated on a NIST-aligned 90-day cadence. Because the cache TTL is short and rotation is routine, the exposure window of any single signing key is bounded by design. The env-scrubbed pipeline worker described in Tenant Isolation & Data Custody deliberately does not hold signing material, so a pipeline sandbox escape cannot forge a signed request.

Near-real-time revocation

Access can be revoked in near real time. When a token or application principal is revoked, in-flight authorization checks stop honoring it promptly rather than waiting for a long-lived token to expire on its own. This matters operationally: offboarding a user or killing a compromised automation credential takes effect quickly, not at the end of a token lifetime. Revocation applies to application principals and their secrets as well as user sessions.

Granular, per-resource RBAC

Authorization in Nexus is per-resource, least-privilege, and identical for humans and machines. Permissions are scoped to specific resources — pipelines, reports, bridges, files, sites, tools — rather than granted globally.

The model has three tiers working together:

Tenant roles — the two built-in roles Reader and Admin set a baseline; custom roles (created from individual permissions) express anything in between.
Per-resource scoped grants attach a permission to a specific resource for a specific principal. A user or app can be given access to exactly one report or one bridge without being handed the whole tenant. Grants apply to both user principals and application principals.
Admin edit-locks protect sensitive configuration from casual change.

Every action flows through a permission check before it executes:

identity (Entra user or app principal)
   → permission check (tenant role + per-resource grants)
      → action
         → audit record (persisted in your tenant)

There is no code path that performs a governed action without first resolving the caller's effective permissions. Authorization is checked at the server edge, not delegated to the client.

Execution roles and assume-role: privilege without standing elevation

A recurring problem in automation is that a scheduled job needs elevated access, so someone grants a standing elevated identity — which then becomes a persistent liability. Nexus addresses this with execution roles.

You can pin a curated role to a pipeline or report. When that asset runs, it assumes the pinned role's permissions for the duration of the run only. The principal that owns or triggers the asset does not carry that elevation the rest of the time. This gives you:

No standing elevation — the elevated permission exists only while the specific asset executes.
Auditable, scoped privilege — the assumed role is curated and recorded, so an auditor can see exactly what a run was entitled to and why.
Separation of duties — an author can build a pipeline that runs under a role they themselves do not hold interactively.

See Execution Roles for how to configure them.

The same governance covers AI agents

The embedded MCP server is not a privileged side door. An AI agent connecting over MCP authenticates as a specific identity and is bound by exactly the same RBAC, per-resource grants, credential isolation, and audit trail as any other principal. An agent cannot:

read a resource the connecting identity lacks a grant for;
resolve another user's bridge credentials;
perform an action that would not be permitted to that identity through the REST API.

This means "we connected an AI agent" does not expand your attack surface beyond the permissions of the identity you connected it as. Everything the agent does is attributable and governed. See MCP Server and Connecting AI Agents.

Writes are gated twice

Write operations pass both an RBAC check and a per-adapter writability check. Even a principal with write permission cannot write where the target does not support it: database views are blocked, formula and lookup columns are blocked, read-only collections reject writes, and each adapter declares precisely which operations it supports. Authorization ("are you allowed?") and capability ("is this write even valid here?") are separate gates, so a permission misconfiguration cannot turn into a corrupt write against a surface that should never accept one.

What this does and does not do

It does: anchor identity in your Entra tenant with your policies; prevent request replay on sensitive endpoints with single-use signed requests; revoke access in near real time; bound every principal — including AI agents — to least-privilege per-resource grants; and provide run-scoped elevation with no standing privilege.

It does not: replace your Entra conditional-access and MFA configuration (Nexus inherits it — configure it well); and it does not make an over-broad grant safe. RBAC is only as tight as the grants you author. Nexus gives you the granularity to be least-privilege; using it is your operational discipline.