Skip to main content

​
Authorization model

The orriven MCP server uses delegated user authorization via OAuth 2.1. When an integration is authorized, tool executions inherit the permissions and role assignments of the authorizing user account across all accessible organizations and Business Units. Access permissions strictly adhere to platform Role-Based Access Control (RBAC):
  • Role inheritance: An account with Admin role in a Business Unit can manage API keys and webhooks; an account with Viewer role can only perform read operations.
  • Scope limitation: Access is bounded by the user’s explicit organizational memberships. Unassigned Business Units cannot be queried or modified.

​
Credential boundaries

The MCP server architecture enforces strict separation between integration types and credentials:
  • No password exposure: Authentication occurs entirely within the orriven console; the client receives only standard OAuth access tokens.
  • No session hijacking: MCP access tokens cannot be used to establish interactive console sessions.
  • Separation from event data: MCP tools manage developer resources and configuration. Access to event data (attendees, tickets, orders) requires dedicated API keys provisioned via create_api_key.

​
Token lifecycle

To immediately terminate access for a previously connected client, revoke any API keys generated by that client and suspend or update the roles of the authorizing user account in organization settings.

​
OAuth 2.1 protocol & verification

The MCP server implements the standard OAuth 2.1 authorization framework:
  • Authorization Code Grant with PKCE (RFC 7636) to prevent code interception attacks.
  • Dynamic Client Registration (RFC 7591) for seamless client discovery.
  • Strict Redirect URI validation: Redirect targets must match registered client URIs (for example, claude.ai for Claude.ai, or loopback interfaces for local developer tools).
Always verify the redirect destination during authorization consent. Only authorize requests initiated directly from your active session.

​
Audit logging

All state-modifying actions executed through MCP tools are recorded in the organization audit log:
  • Actor attribution: Log entries record the authorizing user account, marked with the via MCP badge.
  • Execution details: Log records include the invoked tool name, target resource IDs, and input parameters. Sensitive fields (such as signing secrets and API keys) are permanently redacted prior to persistence.
  • Developer API logs: Programmatic calls made using provisioned API keys are logged separately in the Business Unit request logs, accessible via list_api_request_logs.

​
Best practices

  • Principle of least privilege: Authorize MCP integrations using dedicated accounts configured with the minimum role required for the task.
  • Secure credential storage: Ensure agents persist generated API secrets directly into encrypted secret managers or runtime environment variables rather than plaintext transcripts.
  • Ephemeral keys: Use the expiresAt parameter when generating API keys for temporary tasks or testing environments.
  • Regular audit reviews: Periodically inspect organization audit logs for via MCP entries to verify automated administrative actions.