cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Member

What is the best way to manage api tokens?

Jump to solution

I'm looking for a better way to manage API tokens for our SIS imports. At present they are being generated from a specific account admin's account. There some problems with this system. If that person moves on and their account is disabled, the SIS importer will cease functioning until someone makes new tokens and installs them. Whenever we need an additional token for some purpose, that person is the only one who can provide it... unless we want to have multiple account admins providing tokens, which is even more disorganized.

I attempted to set up an account which was not associated with a human, so that active account admins could masquerade as it. It appears to be impossible to generate API tokens while masquerading, however (the button just doesn't appear).

Does anyone have a system for managing API tokens that is not tied to a specific individual?

1 Solution

Accepted Solutions
Highlighted
Lamplighter

chofer@morainepark.edu,

There is a note in the API documentation on Throttling that says that you might be throttled and your API calls fail if you exceed a certain threshold. I've not encountered that myself, but I try to space out all my API calls and use per_page=100 when appropriate to limit the number of requests (although each is a little more expensive). That page might serve to discourage someone from using their own account for system work.

jswink@ucmerced.edu​,

Chris is on the right track. Create an account that you can actually log into and then log into that account. We use multiple service accounts with our systems so it's not a real person making the call. If you're behind an external authentication system like CAS, ADFS, Shibboleth, or LDAP (including Active Directory), then you can bypass the external system and log directly into canvas by appending /canvas/login to the root URL for your instance. That means that the service account doesn't have to be in your external system.

It's actually a good thing (at least in higher ed) that you can't generate a token for someone while you're masquerading as them.

View solution in original post

9 Replies
Highlighted
Navigator

jswink@ucmerced.edu​...

I think your solution is actually a good one...to create a "generic" account that is not tied to any one person that can be "passed on" to anyone in your department.  I'm curious, though, why you are masquerading as that "generic" account?  Why not just log in as that account like you'd regularly do with your own account?  That should solve any issues you are having getting an API token from that "generic" account.  I've done that to obtain an token for a couple things in our Canvas instance, and I've had no issues.  Give that a shot and come back here to let us know of your results.

Hope this helps!!

Highlighted
Lamplighter

chofer@morainepark.edu,

There is a note in the API documentation on Throttling that says that you might be throttled and your API calls fail if you exceed a certain threshold. I've not encountered that myself, but I try to space out all my API calls and use per_page=100 when appropriate to limit the number of requests (although each is a little more expensive). That page might serve to discourage someone from using their own account for system work.

jswink@ucmerced.edu​,

Chris is on the right track. Create an account that you can actually log into and then log into that account. We use multiple service accounts with our systems so it's not a real person making the call. If you're behind an external authentication system like CAS, ADFS, Shibboleth, or LDAP (including Active Directory), then you can bypass the external system and log directly into canvas by appending /canvas/login to the root URL for your instance. That means that the service account doesn't have to be in your external system.

It's actually a good thing (at least in higher ed) that you can't generate a token for someone while you're masquerading as them.

View solution in original post

Highlighted
Navigator

Hi james@richland.edu​...

Thanks for that info about throttling.  I don't work with APIs and on a daily basis (that stuff is pretty foreign to me), but it's good information to have.  So, thanks again...I appreciate it.

Highlighted
Community Member

I would rather not have to log in as the generic account, because that means that we must maintain the password for it. Then when any person who has access moves on, we have to change its password and make that available to the people who need access. Masquerading would be much simpler.

Highlighted
Lamplighter

jswink@ucmerced.edu​,

Your conceptual understanding of tokens is flawed and without correcting that, you will never be happy with any solution that people give you.

An access token is a user account and a password rolled into one value.

Access tokens should be treated like passwords because they are. If you say We can't do this because we have to change passwords when someone leaves, you're missing the security concept that you also need to change/expire/delete any tokens that person had access to while they were here. Because if you don't, that person still has access to all things API in Canvas. They may not be able to log into the web interface, but most of the damage can be done through the API. Of course, you could delete the account that was tied to the token, but you were looking for a way to have it not tied to a specific person.

Designate one person/team to maintain tokens for the system accounts. Create an account inside Canvas for system maintenance. The password to that account is known only to that person/team. It doesn't really matter if they know what the password is or not as any Canvas admin could go in and change the password, login as that person, manipulate tokens, and log out. That team would be responsible for updating the tokens in the code that does the SIS imports and other API calls.

You don't share access to the "fake" Canvas account to everyone who needs a token. What the person/team does is generate a token and share the token with the person(s) who need it for running the back end tasks.

Highlighted
Community Member

Does the Developer Keys factor in here?     I'm not really up-to-speed on what the Developer Keys feature does in Canvas.

Highlighted
Lamplighter

I looked at the Developer Keys before I responded because I thought they might. The documentation about their use isn't very clear, but when I went into them and tried to create one, it looked more like they were for LTI integrations than for API functions.

Highlighted
Lamplighter

jared.flaherty@park.edu,

Correcting myself, I've discovered some more information about Developer Keys. Developer Keys are used so that you can automatically obtain an access token programmatically rather than going through the web-interface to get one. They are "more secure" and thus recommended, but require more work to implement for an individual than just going to the web-interface and requesting one.

The reason I said it looked like an LTI integration was because you had to supply the same information you would for an LTI app (key and secret) and the documentation in the guides didn't explain the purpose, just how to create one. When you go to the API documentation and view all resources, there was no useful mention of Developer Keys. However, if you go to the OAuth2 API documentation, you finally get an explanation.

This answer from Erin Hallmark also helps clarify. Developer key or data access token?  However, it also says "External Tool" and "App" so it still sounds like it's for LTI Apps requesting access to data.

Highlighted
Community Member

Thank you, Sir!     I've passed this along to our 2 main developers that work with our API.

Cheers!

Jared