Asking users to generate an access token

[gruetzmacherr]

Is it acceptable to ask users to generate a Canvas access token and enter it into an application? I'm not asking if it is ideal (over using OAuth2 to request tokens,) but rather if it is "legal" and allowed within Canvas's terms of service.

I was under the impression that it is not permitted by Instructure/Canvas to ask users to enter their access tokens into an application. In fact in the Canvas OAuth documentation it states the following.

For testing your application before you've implemented OAuth, the simplest option is to generate an access token on your user's profile page. Note that asking any other user to manually generate a token and enter it into your application is a violation of Canvas' terms of service. Applications in use by multiple users **MUST* use OAuth to obtain tokens*.

What has me asking this question then, is that I recently came across some of  @James 's work (I'm a big fan, James!) and in his tools he asks users to generate and provide access tokens to use his tools. His work has even been promoted by Instructure/Canvas and featured on CanvasLive showing his due date changing Google Doc spreadsheet, during which they show users how to generate an access token and then enter it into his Google Docs spreadsheet. All of this has left me a bit confused on what is permitted and what is not around this topic.

I have written a few LTI integrations now and have become familiar with the OAuth2 flow to request access tokens. If I am able to legally bypass that for smaller-scale applications/integrations it would certainly change my approach. Up to this point I thought it was illegal for me to request users enter an access token, but it seems to be a somewhat accepted practice.

Thank you,

Raymond

[themidiman]

I'm not an expert on the legality of such a thing, but I believe there are some instances where Oauth doesn't lend itself in a way that makes sense to an external application's design. One system we subscribe to needs a root level admin key to be able to read in all the courses and sub-account information to aggregate in a way that makes sense to its design. For that we had to create a separate api key and copy/paste it into their system. Oauth usually means that the Canvas needs to be able to launch and display the LTI provider's UI in an iframe of some sort, and this system we subscribe to isn't written in that way where a root admin launches the tool from within Canvas. We use a separate login directly to their system. But it works the way it is designed and we have no issue with it except for the fact that this system has the keys to the kingdom for all our Canvas data and our privacy/legal department had to sign off on it. 

[themidiman]

Amendment to my previous reply: this LTI consumer is one of Instructure's partners, so if your questions is about the appropriateness of how Instructure wants you to use API Keys, just know that their recommendation is usually OAuth and store the key or at least a hashed version of it in a data store of some sort that is properly secured. 

[gruetzmacherr]

Thank you for your comments, Jeffrey! I think it's really powerful to allow users to generate their token and enter it into a tool, but I understand why Instructure frowns on it's regular use. I would like to use that feature, but I don't want to be in violation of Instructure's terms of service either.

[themidiman]

I don't think it's a violation if users do this...it's just potentially poor security to leave an API key in plain text lying around for someone to find because someone can do things in Canvas as that user without the need for a username and password. 

[James · Accepted solution]

 @gruetzmacherr , 

I struggled a bit with that myself when I first made the sheets available. Here's what I eventually settled upon, remembering that I'm not a lawyer.

Here's the same text you quoted, with some different highlighting.

Note that asking any other user to manually generate a token and enter it into your application is a violation of Canvas' terms of service. Applications in use by multiple users **MUST* use OAuth to obtain tokens*.

I'm not asking them to enter an access token into my software. The first step of the process is to make a copy of the spreadsheet so that it's theirs. I don't have any access to it at that point. I'm not hosting anything on a server under my control. It's essentially like any PHP, Python, Ruby, Perl, or other open source client (not server) software that they choose to download and install on their own machines. They have to configure it before it will work. My asking them to generate a token is akin to providing instructions on how to configure the software. A slight difference is that the software is hosted by Google rather than being installed on their own local machine.

The Google Sheets are designed to be used by a single user, not by multiple users. If an end user does share it with someone, that person has to generate their own token since they're stored at the user property level and not shared between users.

To go along with what JEFHQ12951 has said, there are several people who have written LTIs for their own institution's use that have higher privileges than the users that are using it. That's required in some cases when you want to make something available to the user that they wouldn't normally have access to, such as who liked what messages in a discussion (that's only available to someone with the ability to masquerade) but I might want to make that information available to the teacher. In that case, using OAuth wouldn't help.

Canvas actually has a page that asks people to store an access token before you can use it. It's in the Live API, found by adding /doc/api/live to the end of your Canvas instance. They don't store that, though, which makes it not at all friendly and unsuited for repeated use like an LTI would. It certainly goes along with the notion of testing and development, but I'm not sure Canvas is bound by their own terms of service. If you know how to do OAuth and have the ability to do so (I'm not running any public servers to authenticate against) then I would recommend it. If your server / software is doing any kind of API call with the credentials of that person, then you should use OAuth. If they're running the software themselves as a single user, then they can choose to put in an access token.

Again, I'm not a lawyer, but I was raised baptist and was very legalistic in my youth. As I aged, I started reading things more for their intent than what was actually said. I admit I still struggle with things like driving the speed limit on urban interstates or going 15 miles over the posted speed limit to avoid getting plowed into from the rear.

[gruetzmacherr]

Thank you for taking the time to respond with that thorough post,  @James ! You answered most of my questions and addressed my concerns around the topic.

I like you're approach of using Google Sheets - and you make a great point that once they copy it, it is no longer in your "domain" - it is in theirs at that point. What I was thinking of doing doesn't make that clean break, and would technically be used by multiple users - so I think I'll stick with using the OAuth flow as I have in the past. It's obviously not as quick and easy for end-users to jump in and start using, but that's not a show stopper.

Thank you again for taking the time to respond,

Raymond

[James]

OAuth might actually be quicker for end users than having to create an access token. It's just a few clicks as opposed to clicking, copying, switching apps, and pasting.

[dtod]

Is there a way to report a vendor that does this (and doesn't listen when you tell them not to)?

[dgrobani]

I'd start with your CSM.