# Request: Canvas Developer Key (OAuth2) for ASU Canvas Course Builder

**To:** ASU LMS / Canvas administration (EdPlus / UTO Canvas admin)
**From:** Brent Espineda — Instructional Design, ASU Online
**Re:** API Integration Developer Key so our internal course-build tooling can use OAuth2 instead of per-user personal access tokens

---

## What I'm asking for

A **Canvas Developer Key of type "API Integration"** (OAuth2 authorization-code flow) for an internal ASU Online instructional-design tool. This is **not** an LTI key — no launch, no external tool placement.

## Why

Today every ID/faculty member who uses the tool must manually generate a **personal access token** (Account → Settings → New Access Token) and paste it into a local config file. That is friction on every onboarding, the tokens expire and must be re-minted, and a pasted token is a credential sitting in plaintext.

An OAuth2 Developer Key fixes all three:
- **No manual token minting** — the user clicks "Connect Canvas," approves on `canvas.asu.edu`, done.
- **Expiry handled automatically** — refresh tokens renew access without user action.
- **Identity preserved** — each user still acts as themselves, so Canvas audit trails ("who edited this page") stay intact. (This is why we want OAuth rather than a shared service account.)

## What we need provisioned

| Parameter | Value |
|---|---|
| Key type | API Integration (OAuth2), scopes **enforced** (least privilege) |
| Grant | Authorization code + refresh token |
| Client type | Confidential (issues a `client_secret`) |
| Redirect URI | `https://asu-plugin-api.vercel.app/api/oauth/callback` *(our existing internal proxy; final host TBD, will confirm before issuance)* |
| Owner / contact | Brent Espineda, bespined@asu.edu |
| Scope families needed | Courses (read/write), Pages, Assignments, Quizzes, Discussion Topics, Modules, Files, and `url:GET|/api/v1/users/self`. Exact scope URNs to be finalized with you during provisioning. |

If ASU prefers to start unscoped (matching what a personal access token can already do today) and tighten later, that also works — the tool's capabilities do not exceed what our users' PATs already permit.

## Security commitments

- The `client_secret` lives **only** as a server-side environment variable on our proxy. It is **never** shipped in the distributed plugin, committed to the repo, or exposed to end users.
- Per-user access/refresh tokens are stored server-side, scoped to the authenticating user's own Canvas permissions.
- The tool only ever acts within courses the authenticated user already has access to. No privilege escalation, no impersonation.
- We already domain-pin every API call to `canvas.asu.edu` and validate redirect/next-link hosts before attaching any token.

## Scope of use

Internal ASU Online instructional-design staff and participating faculty building/maintaining their own Canvas courses. Not a student-facing tool. Not distributed outside ASU.

## Interim

Until the key is issued, users continue with personal access tokens (now a one-command `setup_env.py --init` that validates and stores the token locally with `0600` perms, without the token passing through any chat transcript). The Developer Key replaces that path once available.

---

**Ask:** Can we get this Developer Key provisioned, and is there an ASU review/approval step (data governance, security) I should route this through first? Happy to meet and walk through the architecture.
