---

name: canva-enterprise-rbac description: 'Implement application-owned authorization from Canva scopes, user capabilities, resource ownership, and tenant policy. Use when gating Enterprise or privileged operations without inventing a Canva custom-role API. Trigger with: "Canva RBAC", "check Canva capability", "authorize Canva action".' allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[action-and-tenant-context]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:

• saas
• canva
• authorization
• operations compatibility: 'Requires a documented application role model plus current Canva scope and capability evidence.'

---

Canva Capability-Aware Authorization

Overview

Use Canva scopes and capabilities as provider inputs to your own authorization decision. Do not equate OAuth consent with tenant role, resource ownership, feature entitlement, or approval to process content.

Prerequisites

• Application roles, actions, tenants, and deny-by-default policy
• Current explicit Canva scopes and capability response contract
• Resource ownership and data-classification checks

Instructions

Step 1: Define the decision tuple

Name subject, tenant, application role, action, resource, environment, requested Canva operation, and data class.

Step 2: Separate provider inputs

Treat granted scopes, capability fields, resource access, and preview availability as independent facts. Absence, unknown values, or stale evidence must deny.

Step 3: Map application policy

Use Write or Edit to map each application action to minimum scopes, required capability evidence, ownership rule, approval, and audit class.

Step 4: Enforce server-side

Resolve the policy after authenticated tenant identity and before dispatch. Keep the generic Canva client unaware of business roles.

Step 5: Handle changes

Invalidate cached decisions after scope, membership, consent, capability, policy, or resource-owner changes; require reauthorization only when scopes changed.

Step 6: Audit without content

Record policy version, opaque subject/resource references, decision inputs, allow/deny result, and reason code without tokens or design contents.

Authentication

Canva Connect calls use Bearer access tokens obtained by a backend through OAuth 2.0 Authorization Code with SHA-256 PKCE. Request explicit least-privilege scopes, keep client secrets and tokens out of browser-visible state, and serialize refresh so the replacement single-use refresh token is stored atomically.

Tool Discipline

Use Read and Grep for discovery and evidence. Use Write or Edit only for the approved artifact, code, configuration, test, or receipt described by this workflow; do not make an unapproved Canva-side change.

Output

• Scoped decision or implementation artifact
• Redacted operation and validation receipt
• Failure, rollback, and follow-up ownership record

Examples

An application editor requests brand-template autofill. The backend checks tenant role, explicit design and template scopes, current capability/availability, template ownership, and data approval before submitting one job.

Error Handling

Failure	Response
Capability field is unknown	Deny and update the pinned response contract
Scope exists but role denies	Deny; OAuth consent does not override application policy
Tenant cannot be resolved	Stop before any Canva request
Policy cache is stale	Invalidate and recompute from current evidence

Resources

• First-party source notes
• Capabilities
• OAuth scopes