Strengthening Security in Canvas: Updates to User Access Token Management

AlexisNast
Instructure
Instructure
27
2263

Canvas.png

You may have noticed that we are updating how we handle User Access Tokens. These changes have been made across the September and October deploys. I wanted to walk through all of these changes together and how they will improve institutions’ security, particularly in light of increasing AI usage.

 

  • All User Generated Access Tokens require that a purpose be set. (Deployed October 8, 2025)

For all API keys, it is best practice to have a single, clear use that the API key be intended for. This ensures that you can identify which API user is doing what, and it also makes it easier to remove keys which are no longer needed. For this reason, we are requiring that User Access Tokens have a purpose set regardless of which user creates them.

 

 

  • User Generated Access Tokens created by users with only student roles must have an expiration date no more than 120 days away. (Deployed October 8, 2025)

To reduce the security risk in the scenario that a token is compromised, best practice is to have an expiration date on all User Access Tokens. That said, we are aware that some schools choose to use User Generated Access Tokens for long-lasting tools. As a compromise, we are requiring expirations for User Access Tokens which are created by users who have only student roles, and will be applying these to all previously created keys of users who only have student roles. 

 

Most students who are using Canvas APIs for legitimate purposes are doing so as part of their coursework and learning. We intentionally set the maximum expiration date as 120 days as this is longer than most courses, so it should not interrupt the use of Tokens created for a specific course.

 

If a User Generated Access Token needs to be created for a longer period of time, this can be achieved by giving the user any role other than student (even with all permissions locked down). Our intention is to strike a balance between allowing administrators to choose what is best for their school and enable long-lived access as they feel is appropriate, while locking the system down enough that students aren’t enabling a key they don’t need (or worse, are using for unauthorized tools such as AI homework completion tools) on a long term basis.

 

 

  • Administrators can see and remove user generated User Access Tokens from a user’s profile. (Deployed October 8, 2025)

As AI proliferates, we have seen an uptick in students setting up AI integrations to automatically review and complete assignments on their behalf. Our priority is to protect the integrity of the learning process, and these changes to User Access Tokens should help . We can also make it so that if misuse is discovered, an administrator can act swiftly to shut it down. In order to do this, we’ve made it so that from the user’s profile page as an administrator, you can see all User Generated Access Tokens for that user, view the purpose, and remove them if needed. 

 

 

  • Administrators can prevent all non-admins or all students from generating User Access Tokens. (Deployed September 10, 2025)

Some schools do not want anyone who isn’t an administrator to be able to offer API access into their Canvas instance. Some want instructors and TAs to have access to the APIs, but would like to prevent students from accessing them. We have made both of these options available on the account settings page. This allows each institution to choose the level of access they are comfortable with and have more control over user and institution data.

 

27 Comments
chriscas
Community Coach
Community Coach

Hi @AlexisNast,

Thanks for posting this summary of the changes!

I did post a comment in the 10/8/2025 deploy q&a, but it may have been missed so I'll put it here too for visibility.

Regarding the "People: Access Tokens Management" update which is now live...  It would be great if the ability to create access tokens was also available there for admins with the appropriate permissions.  Currently we have to act as the user to generate a token, which adds extra steps (and requires that admins have act-as permission, which is only available at the root account).  Adding that button here would make it more convenient as well as give us more freedom in which admins can create tokens (without making us give them act-as permission too).

-Chris

AlexisNast
Instructure
Instructure
Author

@chriscas I can definitely understand how that would be helpful, but we're hoping to move away from User Access Tokens as much as possible in the future. We are starting to make technical plans for features which I believe will replace the need for admins to create User Tokens on behalf of a user. If for some reason that doesn't work out we will look into this though!

dbrace
Community Coach
Community Coach

Thank you for this, @AlexisNast.

I have a question about the "Administrators can prevent all non-admins or all students from generating User Access Tokens." section of this post.

If a user account has at least one student enrollment but also has other types of enrollments, will they be able to create a user access token?

I ask because at my institution all of our faculty are also enrolled into at least one course as a student. Would they be able to create a user access token?

-Doug

bergs
Community Participant

How will this affect the access tokens used by the Canvas mobile app?

SarahBlanton
Community Participant

Hello, @AlexisNast , thank you very much for this article. It helps clarify the various facets of the new access token handling features.

I do have a question about the 120 day expiration date being applied to tokens that were created prior to the 10-08 code release. That day, I logged in with an account that is ONLY a student and created a token before the code release. As expected, it did not require me to supply an expiration date. Later that day, with the same user, I created another token and, as expected, it did require me to supply an expiration date <=120 days.

Looking at the two tokens now, however, I still don't see an expiration date applied to my first token. Is applying those dates retroactively still a work in progress or have I misunderstood that part of the student token expiration date feature?

SarahBlanton_1-1760708284476.png

Thank you.

 

AlexisNast
Instructure
Instructure
Author

@dbrace Great question! Preventing non-admins from generating a user token will allow anyone with any admin role to generate a user token, even if they have a student or teacher enrollment. Preventing students from generating user tokens will allow anyone with any non-student (and soon non-observer) role from generating a token. Another way of saying that is that only users who have ONLY student (or observer) roles will be prevented from creating tokens. Hopefully that clarifies, but let me know if it doesn't and I can write up some example users and their different roles and say how each rule would function.

AlexisNast
Instructure
Instructure
Author

@SarahBlanton You understood exactly how it should work, but the update to past tokens is taking a bit longer to do than we expected. I'm hoping that will go out in the next week or so. It will be 120 days from the day we roll it out.

AlexisNast
Instructure
Instructure
Author

@bergs This only impacts tokens generated by users manually, on the user page.

Approved Integrations section of the user's Settings page.Approved Integrations section of the user's Settings page.

This will not impact the Canvas mobile app.

dbrace
Community Coach
Community Coach

Thank you, @AlexisNast!

-Doug

froye001
Community Participant

We're in need of better reporting to understand the state of tokens in our instance. Since user-generated tokens are not represented in CD2, we rely solely on the account level User Access Tokens report. Please consider adding values to this report:

CREATION_DATE - Currently the report includes EXPIRATION and LAST USED. Often both these values are "never" which means we're unable to associate a token with a timeframe and we're unable to reliably detect spikes in token generation.

STATUS - The report can be configured to request deleted objects but there is not a status field to distinguish deleted tokens in the resulting report.

PURPOSE - Especially now that PURPOSE is a required value.

A shared value with Canvas UI - Adding user-generated tokens to the User Details page is a great new feature. However, other than the expiration date, there is no unique, shared value between the Canvas UI and the report. The report includes HINT but that is not viewable in the Canvas UI.

AlexisNast
Instructure
Instructure
Author

@froye001 Thanks for the feedback! I'll see what we can do to help more with this issue.

froye001
Community Participant

@AlexisNast TOKEN ID would be great too. As we attempt to delete/update tokens at scale, having the token's ID writes that API call without an intermediate step of first getting a user's list of tokens. 

cms_hickss
Community Contributor

@AlexisNast 
Just to clarify. "Admin" here means = Account Admins, Account Roles created by the institution (this would be like sub-account admins or Support Roles), Teachers, Designers, and TAs

 

So, if we just wanted Account Admins or Account Roles created by the institution (this would be like sub-account admins or Support Roles) to be able to create Access Tokens, this would not currently be possible?

chriscas
Community Coach
Community Coach

Hi @cms_hickss,

Here is my understanding of the two switches options now available around token generation, as shown here:

chriscas_0-1761575087644.png

With "Limit personal access token creation to Admins" enabled, only users with an account admin role (not a teacher, ta, etc) can create tokens.

With "Restrict students from creating personal access tokens" enabled, users who only have student (or observer, I think) roles cannot create tokens.  If the admins setting is enabled, I believe this setting really doesn't have any effect (and probably should be grayed out or something but that probably needs another thread to talk about).

So if you want Teachers/TAs to be able to create tokens, but not students, you'd enable the "Restrict students from creating personal access tokens" option.  If you only wat account admins to create tokens, but not Teachers/TAs/etc, you'd enable the "Limit personal access token creation to Admins." option (this is what we have at my institution).

Does that help at all?

-Chris

AlexisNast
Instructure
Instructure
Author

@cms_hickss What Chris said is exactly right. If that doesn't answer your question or if you have follow ups please reach out though!

cms_hickss
Community Contributor

@AlexisNast & @chriscas 

I'm trying to address this part:  Some want instructors and TAs to have access to the APIs, but would like to prevent students from accessing them. We have made both of these options available on the account settings page. This allows each institution to choose the level of access they are comfortable with and have more control over user and institution data.

chriscas
Community Coach
Community Coach

Hi @cms_hickss,

If you want Instructors/TAs to create tokens, but not students, that would be leaving "Limit personal access token creation to Admins" unchecked, and "Restrict students from creating personal access tokens" checked.

Maybe a table would be better (@AlexisNast please correct me if any of this is wrong)...

Limit personal access token creation to Admins Restrict students from creating personal access tokens Net Effect
unchecked unchecked Anyone can create their own access token
unchecked checked Account Admins, Teachers, TAs can create their own access token.

Users with exclusively student/observer enrollments cannot create a token
checked unchecked Users with an account admin role can create tokens

Users without any sort of account admin role cannot create tokens
checked checked Users with an account admin role can create tokens

Users without any sort of account admin role cannot create tokens
AlexisNast
Instructure
Instructure
Author

@chriscas I think lines three and 4 (where the first column is checked) should be Users WITHOUT any any sort of account admin role cannot create tokens.

Other than that it looks correct. So: 

Limit personal access token creation to Admins Restrict students from creating personal access tokens Net Effect
unchecked unchecked Anyone can create their own access token
unchecked checked Account Admins, Teachers, TAs can create their own access token.

Users with exclusively student/observer enrollments cannot create a token
checked unchecked Users with an account admin role can create tokens

Users WITHOUT any sort of account admin role cannot create tokens
checked checked Users with an account admin role can create tokens

Users WITHOUT any sort of account admin role cannot create tokens
chriscas
Community Coach
Community Coach

Thanks @AlexisNast! I edited my original post to correct that typo too just in case others find this thread in the future.

-Chris

jchapes
Community Participant

These seem to be very good improvements for Access Tokens. I think the only thought I have is that it would be nice to require users with any role other than admin to have an expiration date for their access token. Our team considered it a best practice to have an expiration date and it would be nice to enforce that with settings. 

dbrace
Community Coach
Community Coach

@jchapes, I am just curious (maybe I am misunderstanding), why do you think that access tokens for admins should not have an expiration date? In my opinion, because of the amount of access that admins have, having an expiration date for admin access tokens is more important.

-Doug

jchapes
Community Participant

@dbrace I would agree that its a best practice here, but I'm still open to the idea that service accounts (for automated processes or custom tools) could be set up with a custom admin-level role and with an access token. While it may be best to still use expiration dates for these cases too, I'd leave it up to the admin team of the specific instance on how they want to manage those tokens. Saying all of that, I'm not opposed to the idea of a setting that requires all users having to set an expiration date, but having layers of customization for this setting for different roles here could be useful. 

dbrace
Community Coach
Community Coach

Thanks for that, @jchapes.

Without working for Instructure/Canvas or having any specific additional insider information (even as a Coach), I think part of what Instructure/Canvas wants is for other authentication methods (e.g. developer keys) to be used for custom tools.

-Doug

marco_divittori
Community Participant

I agree @dbrace but the complication arises with system-to-system integrations that use a service account as opposed to a user app authorization, as @jchapes mentioned.

chriscas
Community Coach
Community Coach

Just to chime on the admin/service account issue, while I agree that most LTI user-land applications should use a developer key with each user-s own authentication if they need API access, that doesn't cover all use cases (this is where service accounts that others mentioned come in).

One example for us would be our SIS-upload service.  We have a custom role created for that, with a service account assigned that role.  We created a token with that service account and use it for our SIS scripts.  Realistically we could use a developer key, but we would then need to make sure the token was for the service account.  We don't want a system process using a person's account, as jobs change and may invalidate that token.  I really wouldn't want to have to change out the token for our SIS process every 120 days (or even every year) as that initiates a lot of change management and is also something that could be easily forgotten and break key data flows.

With that said, I wouldn't be opposed to having an OPTION to have a time limit on admin tokens for schools/universities who want to go that route, I just wouldn't want that option to ever be forced on all of us.

-Chris

marco_divittori
Community Participant

@chriscas we do the exact same thing for our SIS upload process and I too would prefer an expiry option vs forced approach.

AlexisNast
Instructure
Instructure
Author

What Chris mentioned is exactly why we didn't want to force expiration dates for everyone even though we do think it's generally best practice. We're continuing to look into ways we can improve this system and planning what that might look like for our 2026 development efforts. The goal with this update was to do the work that we knew would be minimally disruptive while providing meaningful improvements. I agree that an option would be nice, but as there are so many customizable settings in Canvas already, I'm hoping to explore alternative ways to improve the system (like making Dev Keys usable for more purposes to move people off of user generated tokens entirely) rather than adding yet another checkbox. It means waiting a bit longer, but I'm hopeful we'll be able to develop something that addresses the problems holistically.