Druva · OAuth Scopes
Druva OAuth Scopes
OAuth 2.0
searched
Druva uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.
Tokens are issued from https://apis.druva.com/token.
This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.
BackupCyber ResilienceData ProtectionDisaster RecoverySaaS BackupRansomware RecoveryData GovernanceEnterprise WorkloadsMSPLegal HoldEndpointsGovCloudMCP
Scopes: 0
Flows: clientCredentials
Method: searched
OAuth endpoints
Token URL
https://apis.druva.com/token https://govapis.druva.com/token https://apis.druva.com/msp/auth/v1/token
https://apis.druva.com/token https://govapis.druva.com/token https://apis.druva.com/msp/auth/v1/token
Flows
clientCredentials
clientCredentials
Scopes (0)
Druva implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.
Druva declares exactly ONE OAuth scope across its whole 970-operation estate: 'read', on the client-credentials flow, in 11 of 19 specifications. The documentation is explicit that this is not an oversight but the design - 'The Client Credentials have access to all the OAuth Scopes by default' - so scope is not the authorization boundary. The real boundary is the Druva console role attached to the API credential (Cloud Administrator, or the newer Cloud Admin Read Only role for the inSync Cloud and Platform APIs), which is not expressed in any contract. An agent therefore cannot request least privilege at the token endpoint; least privilege has to be provisioned by a human when the credential is minted. The separate MCP server at mcp.druva.com does scope properly - mcp:tools and mcp:resources - and is the only Druva surface where scope carries meaning.
Druva declares exactly ONE OAuth scope across its whole 970-operation estate: 'read', on the client-credentials flow, in 11 of 19 specifications. The documentation is explicit that this is not an oversight but the design - 'The Client Credentials have access to all the OAuth Scopes by default' - so scope is not the authorization boundary. The real boundary is the Druva console role attached to the API credential (Cloud Administrator, or the newer Cloud Admin Read Only role for the inSync Cloud and Platform APIs), which is not expressed in any contract. An agent therefore cannot request least privilege at the token endpoint; least privilege has to be provisioned by a human when the credential is minted. The separate MCP server at mcp.druva.com does scope properly - mcp:tools and mcp:resources - and is the only Druva surface where scope carries meaning.
📄 Provider scope reference: https://developer.druva.com/docs/authentication
Source
OAuth Scopes
Work with this as data
Every scope set here is available over the APIs.io API and to AI agents over MCP.