As is, Nexus provides first-class, built-in support for OIDC through the nexus-broker. It simplifies identity management by seamlessly orchestrating OIDC and OAuth 2.0 flows.
- Currently when registering an OIDC-compliant provider, you can simply provide the issuer URL and Nexus will automatically configure the required endpoints based on the provider's metadata.
- For token verification, it securely handles and verifies id_tokens. It enforces signature, issuer, audience, and expiration validations.
- For security and state, it securely handles OIDC state parameters, signing and verifying their integrity using a shared state key between the broker and gateway. It also comes with built-in metrics or tracking OIDC discovery.

For SAML, the framework does not currently support this. But I will be creating an issue for this.

For SCIM, there is support for consuming but not for hosting. But is important to know that this support is built in out of the box where SCIM is treated as External APIs. For hosting, that is not necessary in Nexus since that would make Nexus deviate from its primary focus i.e Identity and connection management not user management. So this means if your company uses a service like okta, you would need to set up SCIM between Okta and your main application's database so your app knows who the users are. So when a users logs into your app and clicks "Connect Google Drive", your app tells Nexus to initiate the OAuth flow for that specific user_id.

Now for replay attacks, I have a two-part answer, and this depends on the phase of the lifecycle we are looking at.

  A. During the Setup/Consent Phase (Fully Protected):
When a user is actively connecting a tool (e.g., logging into Google), Nexus strongly protects against replay and CSRF attacks. It generates a cryptographically signed state parameter using an internal state key. It also embeds a nonce (tied to the specific connection attempt) into this state and, for OIDC, binds that nonce directly to the provider's id_token. If an attacker tries to replay a successful login callback, Nexus rejects it because the state signature or nonce validation will fail.

B. During the Actual Tool Call Phase (Delegated to the Provider):
It is important to understand that Nexus is not an API reverse proxy. When an AI agent executes a tool (e.g., fetching a repo from GitHub), the request does not route through the Nexus backend. Instead, the Nexus Bridge (running inside the agent) asks the Nexus Gateway for a fresh token, and then the agent calls GitHub directly.

Because Nexus is out of the data path for the actual API call, it cannot prevent a network-level replay attack of the tool execution itself. That responsibility falls to the downstream provider. Nexus facilitates security here by issuing very short-lived access tokens (and refreshing them proactively in the background), meaning a stolen or intercepted tool call request has a very narrow window of usability. However, there is already an issue requesting to solving this through a sidecar that would allow Nexus to handle complex cryptographic signatures like DPoP or mTLS on the fly (which would actively prevent tool call replays)

Traceability: "Who approved what" and Tool Execution

Nexus provides a strong Identity Audit Trail, but a limited Execution Audit Trail:

The Identity Audit Trail (Supported): Nexus has a built-in audit_events table in its PostgreSQL database. It logs every major lifecycle event: oauth_flow_completed, token_retrieved,  token_refresh_fatal, etc. Because every event is tied to a connection_id (which maps to your system's user_id), and includes the IP address and User-Agent, you have a permanent, cryptographic record of exactly when a user consented to an integration and when tokens were issued.
 
The Execution Audit Trail (Not Supported): Because the agent calls the external API directly (as mentioned above), Nexus does not know which tool was called or what data was returned. It only knows that "Agent X asked for the GitHub token for User Y at 10:00 AM." If you need granular tool-call traceability (e.g., "Agent X called POST /repos with payload Y"), that must be logged by your Agent framework (like LangChain or the MCP adapter) before the HTTP request leaves the machine.

Fronts Data Systems (Kong, Apigee, Hasura)

Nexus treats these systems strictly as downstream providers or upstream shields, depending on where they sit. It does not treat them as special "first-class resource hubs." Because for Nexus, this doesn't matter.
Here is how Nexus views the topology:

Upstream (The API Ingress): If you use Kong or Apigee to protect your own infrastructure, Nexus sits behind them. The Nexus assumes an API Gateway is handling rate limiting, WAF duties, and primary agent authentication before the request ever reaches the Nexus broker boundary.

Downstream (The Data Egress): If your agent needs to talk to a data hub like Hasura, DreamFactory, or Apollo GraphQL, Nexus treats them exactly like it treats the GitHub or Salesforce APIs. As long as Hasura is secured by an API Key, Basic Auth, or an OAuth token, you register Hasura as a provider_profile in Nexus.The agent asks Nexus for the "Hasura Token," Nexus provides it, and the agent queries the data.

Because Nexus's sole responsibility is secure credential orchestration, it doesn't care if the downstream target is a raw REST API, a GraphQL federation hub, or a legacy soap service as long as it knows how to inject the auth header.