If the same Canvas Studio API client is reused for multiple LMS app installs, we can end up with a situation where an admin authenticating in one install breaks the integration in other installs.
The issue is that on our side, OAuth tokens are keyed by (user_id, application_instance_id, service) (see oauth2_token) table, whereas on the API provider's side, they are usually keyed by (oauth_client_id, user_id). In the event of multiple app installs sharing an OAuth client ID, this means we have multiple entries for the token on our side, but only one on the API provider's side. If a token is refreshed when using one application instance, tokens for other application instances which use the same client ID will no longer be valid (since there is only one token on the provider's side).
The proper fix would be to key OAuth tokens by (oauth_server, oauth_client_id, user_id) on our side, where oauth_server is an identifier representing the server which oauth_client_id belongs to. Then each token on our side would correspond to one token on the authorization server. We might have to find an interim solution as changing this for all API integrations will be quite complex.
If the same Canvas Studio API client is reused for multiple LMS app installs, we can end up with a situation where an admin authenticating in one install breaks the integration in other installs.
The issue is that on our side, OAuth tokens are keyed by
(user_id, application_instance_id, service)
(seeoauth2_token
) table, whereas on the API provider's side, they are usually keyed by(oauth_client_id, user_id)
. In the event of multiple app installs sharing an OAuth client ID, this means we have multiple entries for the token on our side, but only one on the API provider's side. If a token is refreshed when using one application instance, tokens for other application instances which use the same client ID will no longer be valid (since there is only one token on the provider's side).The proper fix would be to key OAuth tokens by
(oauth_server, oauth_client_id, user_id)
on our side, whereoauth_server
is an identifier representing the server whichoauth_client_id
belongs to. Then each token on our side would correspond to one token on the authorization server. We might have to find an interim solution as changing this for all API integrations will be quite complex.