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 |