Need clarity on OAuth authentication when managing courses

[chrisrockwell]

We have an LTI tool that is currently added to courses individually using the client id.  If, for example, the course admin then clicks on "Our Tool" in the Course Navigation we show them a list of the quizzes in their course.

This works fine for developers because we can grab a bearer token from our account and hard code that in; obviously this isn't a good production solution.

Is it correct that we should be using the Oauth flow so that course admins authorize our LTI tool to make API calls on their behalf, i.e. we get their bearer token?  It seems like a bit of a UX issue that a course admin would add the LTI Tool, and then, upon using the navigation item that the LTI Tool provides, have to authorize the app again (albeit just one time, as long as we can hang onto the refresh token).

Additionally, what is the correct scope for getting course information? I see the scopes provided with the respective endpoints, e.g. Scope: url:GET|/api/v1/courses but I get invalid scopes when I use these.  The only ones I've had success with so far look like "https://purl.imsglobal.org/spec/lti-ags/scope/lineitem" but I can't seem to find a good reference for these.

[matthew_buckett]

It always used to be the case with LTI 1.1 that you could have a tool added to the Course Navigation but disabled by default, this way the user has to actively add it to the Course, rather than it appearing in all courses by default. I'd expect this is still possible with LTI 1.3.

Switching to OAuth is a good thing to do and we've implemented this with a locally developed calendar import tool that allows users to import events in to a calendar from a CSV. It uses LTI to perform the initial launch, but then asks the user to grant the tool access to their account. Once granted we save the token and then use the same token across all their courses so they only have to approve the tool once.

You've got the right scope there for getting a course. For API Developer Keys you don't have to enable scopes and can just have everything granted by default to start with. The scope you've found is for the LTI based Assignments and Grade Services API which can be used by a LTI 1.3 tool by requesting that scope on the LTI launch (https://www.imsglobal.org/spec/lti-ags/v2p0/).

[chrisrockwell]

Thank you for the reply @matthew_buckett .

If I'm understanding you correctly, the flow would should be...
- User adds LTI tool to course
- User click navigation item for tool in the Course Navigation section
- If LTI tool does not yet have a token, initiate the OAuth login flow, ensuring the scope "url:GET|/api/v1/courses" is included (e.g. https://our-instance.test.instructure.com/login/oauth2/auth?client_id=tool_developer_id&scope=url:GE...)
- Finish the Oauth flow to get the bearer token
- Use the bearer token to do things like get quizzes in a course

Is that correct?

Thanks again!

[matthew_buckett]

Yep that's correct, here's how a user has to add our calendar import tool to a course and authorize it. With LTI tools you can limit who can see the tool with either broad role based checks or with a specific permission check as well so it can be simpler to just add the tool to every course (by adding it to an account) and then limit who can see the tool by the user's role or permissions. Here's a short video of how we currently have the calendar import working: