Enhanced Token Generation

[RyanNorton]

We have heard from many of you regarding the evolving ecosystem around access token usage and we wanted to share our upcoming plans and strategies.  Our goal is to provide schools with enhanced methods to maintain integrity and confidence around their access token strategies.

The Current State of the World / What We Have Learned

Canvas has always prided itself on providing an open platform.  Our aim has always been to offer a set of standards that encourage people to leverage our APIs in ways that deliver value and impact without being overly restrictive.

Over the past year, we have closely monitored the use of access tokens within educational institutions.  We have identified several areas where improvements are needed to ensure that schools can manage tokens more effectively and securely.  Feedback from our users has highlighted the need for greater control, visibility, and flexibility in token management.

What We Are Doing

To address these concerns, we are implementing the following changes to our API and user interface:

1. Enhanced Token Deletion: We are updating our API to allow administrators to perform a targeted delete against existing tokens.  This will enable schools to better manage access as necessary, ensuring that tokens are only active when required.
2. Enhanced UI for Access Controls: Our user interface will also be enhanced to provide administrators with access controls for visibility, creation, and deletion of tokens.  This will give schools a clearer view of token usage and more straightforward management capabilities.
3. Admin-Generated Tokens: We are introducing a workflow that allows administrators to generate tokens on behalf of users. This new feature will include the option to limit token creation through our permissions model, ensuring that only authorized personnel can create tokens when enabled.

The above changes will also work with our existing purpose and expiration fields, allowing schools to specify the intended use and duration of tokens more precisely and allow for tailored token management options.

Timeline

We are planning to roll out these improvements in Q3 2024, with a release intended for late August or September.  We will provide further updates as we approach the release date to ensure that everyone is aware of the changes.

We believe these improvements will significantly enhance your ability to manage access tokens securely and efficiently.  Thank you for your continued support and feedback!

[ahess4]

The Access tokens API is quite buggy and incorrectly documented. The parameter values are 'token', not 'access_token' as shown in the documentation. We had to dig through the source code to figure this out. Someone changed the parameter array from access_token to token and didn't update the docs.

Canvas live API is passing access_token, so that's broken. Also, GET is only working for self, admins cannot query other users.

PUT and POST require a token parameter, even if null, even though it is not a required parameter. Otherwise, you will get a missing token error. You can pass ANY token parameter you want, even non-existing ones, setting them as null, and it will work. But leave token out, error. For example, you can literally but in blah :

curl -X POST \
--url 'https://<URL>/api/v1/users/<userID>/tokens' \
--header 'Authorization: Bearer <token>' \
--data '{
"token[blah]":""
}'

and it works, but

curl -X POST \
--url 'https://<URL>/api/v1/users/<userID>/tokens' \
--header 'Authorization: Bearer <token>' \
--data '{
}'

does not work.

Finally, PUT parameters are all sticky except for token[expires_at]. If you omit this parameter, the expiry date is reset to null/never expires. Combine this with the inability to do GETs, and it is not possible to update a token without resetting the expiration date, as you can't find out what it is with a GET to set it when doing a PUT.

[RyanNorton]

@ahess4 Thanks for sharing your experience with the API, we'll do some investigation soon and try to ensure that flow works as expected with these new changes.

[Susan27]

Hi @RyanNorton,

We welcome the developments around access tokens. If I am correct, the last addition was in the 21 September release. Can you provide a status update on what of the three "What are we doing" changes have already been rolled out, and whether any additions/changes are coming, and if so, when?

In particular, we are keen to know if it will be made possible to force an expiration date, and set a maximum token duration.

[RyanNorton]

@ahess4 I wanted to provide an update on your notes above.

• We've updated our documentation such that token is correctly documented, instead of access_token. 
• The PUT and POST requests silently required a token but no sub-parameters, so this has been updated to accurately reflect that token[purpose] is now required on creation (as when creating an access token in the UI).
• We have ensured that the expires_at parameter is not overwritten when omitted from requests.

These should be rolling out in the 10/23 deployment next Wednesday.  Thank you for sharing your findings!

[RyanNorton]

@Susan27 Thanks for reaching out!  All three of the changes are available as of 9/21 and are accessible via the details in the in the 21 September release notes.

I'm happy to report that this should satisfy the needs of all of the elements in the Canvas Idea that you linked to, as this allows configurable controls over who can create an access token in accordance with the existing functionality, which allowed defining an expiration date.

You can see more detail on the creation of access tokens and how to configure an expiration date in our Canvas guide here. 

Let us know if this meets your needs, thanks!