I'm currently making some test on canvas, my issue is I already have an API installed on my instance (with one token), but what would it happen in the case that I want to use a different token for the same API in the same Canvas instance?
In others LMS what I usually would make is create a different institution for the same instance and share the API just for one institution.
In the case that two institutions share an API but they want to use different token for control reasons, What should I do?
Thanks in advance!
Solved! Go to Solution.
Hi @grismolina1986 ,
Welcome to the Canvas Community.
There are different authentication types.
Oauth with Developer Keys vs User Access Tokens
One of the first things you must decide is how you connect to the API (i.e. with which type of authentication method). The method you choose will largely depend on your needs.
- User Access Tokens (generated from within an individual user's settings page) are useful for tinkering, or a single-user run script. They will only provide the equivalent permissions of the owning-user.
- OAuth. OAuth is a little different as it enables user logins for an application, then the application can interact with the API as that user. You can read more about this at OAuth2 - Canvas LMS REST API Documentation. The best way to describe this would again be with the Canvas mobile apps. The apps use a shared key and secret (developer key) to permit a user to authenticate to Canvas and log in, without the app itself ever storing the password, Canvas generates a session key and provides this to the mobile app for that user. For any user-facing apps or development, you must use OAuth to protect your user's credentials.
For tokens, and the question specifically...
If your API program only needs permissions of 1 user, like an admin, you can use the same token for any number of API tasks, projects, backend integrations, and automation.
The API token respects the permissions of the user. If you're developing the API tool and have the permissions for the instance there's nothing wrong with using the same token. If it's appropriate for your institution, permissions, security to use the same key for the same API go ahead. Since sharing tokens is against the Canvas Terms, you could create another user for yourself and generate tokens with a Limited Admin role at that institution, sub account...
For clarity, around here we often consider an institution to be a University, College, School District. Where a Canvas Instance would contain everything for that institution. The instance for the institution may contain be sub accounts to deal with different colleges/programs within the institutions organizational structure.
If you're dealing with 2 different instances, it's seems impossible to generate the same key from 2 instances or twice for that matter. So if the API is interacting with 2 Canvas instances use 2 tokens, 2 users, and keep your work separately.
If you are just running a task for multiple groups/organizations/sub accounts, or the whole institution/instance, you would be ok using the same token. I have 320 schools in the same instance, if they all use the same API they are all using the same token.
I use roughly the same handful of keys and replace them regularly. The keys generated on production are copied to Test and Beta, which means I can continue to use them fluidly.
1 option, and this more preference or forward looking when collecting Canvas' downstream Data Products like Canvas Data and Live Events, both come with user_agent information. Many API requests will look exactly like the requests made by the user within Canvas, because it's all the same browser or backend. So, in my API tasks and programs I set the user_agent string. I use the same string for every API project or task, but not for PAW or Postman. The string then takes some modifiers to help me identify which project it came from with the ability monitoring those requests. My user agent string looks like, the first one is generic use, it's the default in almost any API project.
Where edu is our instance.instructure.com