UM Information Security justification for disabling Canvas API Tokens

The information below is directly from UM System Information Security.

Rationale for disabling Canvas user‑generated API tokens

The ability for end users to generate personal API tokens in Canvas should be disabled due to security and privacy risks that cannot be adequately mitigated at this time. Canvas API tokens provide unrestricted, long‑lived access to a user’s account, bypass institutional authentication controls such as multi‑factor authentication (MFA), lack granular permission scoping, and offer limited audit visibility.

With the rapid growth of third‑party tools and AI services that request these tokens to act on behalf of users, the risk of unauthorized access, account misuse, and data exposure has increased significantly. Disabling user‑generated API tokens is a preventative control to protect student data, maintain compliance with institutional security standards, and reduce the impact of credential compromise.

Security position statement

Allowing unrestricted, long‑lived API tokens for end users creates a risk profile that is inconsistent with institutional security standards, particularly with the requirement for MFA protections on account access. Until Canvas supports scoped, auditable, short‑lived tokens with MFA enforcement or equivalent safeguards, user‑generated API tokens pose an unacceptable risk to account integrity and student data protection.

Detailed security justification

API tokens bypass MFA and central authentication controls

Canvas API tokens are used to authenticate requests independently of the institution’s primary identity provider. Once issued, a token:

  • Is not subject to MFA challenges
  • Remains valid until manually revoked or expired
  • Can be used from any location, system, or service

This means that even if MFA effectively protects interactive logins, API tokens circumvent that control entirely, undermining one of the institution’s strongest safeguards against account compromise. If a token is leaked, stolen, or reused by a third‑party service, it provides continuous access without detection by normal authentication monitoring.

An API token is functionally equivalent to a permanent password that ignores MFA.

Tokens are full‑privilege and cannot be scoped

Canvas user‑generated API tokens inherit all permissions of the user account:

  • No ability to restrict to read‑only actions
  • No limitation to specific courses or datasets
  • No task‑based or time‑limited permissions

As a result:

A student token grants access to all courses, grades, submissions, messages, and profile data the student can access

A faculty or staff token could allow grade changes, content modification, user data access, and messaging. Additionally exposing multiple students and courses to the risk of unauthorized access.

This violates the principle of least privilege, a core security control required by the institutional security program.

Limited audit logging and accountability

Canvas provides insufficient logging and attribution for actions taken via API tokens:

  • API activity is difficult to distinguish from legitimate user actions
  • Logs do not reliably identify the system or service using the token

This creates challenges for:

  • Incident investigation
  • FERPA/privacy reporting
  • Responding to student or faculty disputes
  • Legal and compliance obligations

Elevated risk from AI and third‑party services

Many AI tools and browser extensions now request Canvas API tokens to:

  • Analyze coursework
  • Generate summaries or feedback
  • Automate downloads, grading insights, or submissions

These tools often:

  • Are hosted externally
  • Store tokens insecurely
  • Have unclear data retention policies
  • Are not contractually vetted by the institution

In effect, users are being asked to delegate full account access to unvetted third parties, creating unacceptable risk to student records and institutional systems.

Increased impact of token compromise

Because API tokens:

  • Do not expire promptly
  • Are often reused across services
  • Are copied into scripts, extensions, or cloud tools

They are significantly more likely to be:

  • Accidentally exposed
  • Stored in plaintext
  • Included in screenshots or shared files

The downstream impact of a compromised token can exceed that of a stolen password, especially since MFA provides no protection.

Clarification on API usage

API access is not prohibited, but must be:

  • Provisioned centrally with a managed lifecycle
  • Used for approved integrations only
  • Secured appropriately
  • In support of a legitimate and justified business or academic need

Institutional integrations can still be supported using:

  • Admin‑managed tokens
  • Vendor‑approved LTI tools
  • Contractually reviewed third‑party services
Print Article