LTI 1.3 and React/Vue/??

[ColinMurtaugh]

Hi --

We've developed a number of LTI tools over the years using Python/Django on the server and Bootstrap and plain JS on the client. Now we have a need to build some more complex user interfaces, and we're exploring doing more front-end development using a framework like React or Vue. 

I'm interested in hearing any experiences, advice, warnings, successes and horror stories that you have using modern front-end frameworks to develop LTI tools for Canvas. I'm particularly interested in patterns for handling LTI 1.3 launches and authentication/authorization. 

At this point we're focusing on React/NextJS and Vue, but open to hearing about others as well. 

Thanks!

--Colin

[matthew_buckett]

We've been reasonably happy with React as a front end technology for building Canvas tools and enhancements. We went with React because of the Instructure UI support (https://instructure.design/) which allows interfaces to easily match Instructure's style and behaviour. It's reasonably easy to have the tool follow the Canvas local theme and also pickup the users high contrast setting and display appropriately. 

We have extracted out the handling of LTI launches into a backend service which is used by all our tools. This service handles the LTI launch flow and allows a static frontend to retrieve a token that contains all the claims from the launch. We re-sign the token ourselves which allows us to add additional claims in.

We originally built our frontend usings create-react-app (https://create-react-app.dev/) which provided most of the scaffolding but are in the process of switching to vitejs (https://vitejs.dev/) as it's better supported and seems to have more of a future.

We're hoping to open sources the some more of the core parts of our stack in the near future.

[thohoangngo]

Hi Matthew, I'm developing a LTI tool also the app is consist of front-end and a back-end (the back-end will serve the static file for the front-end). What is the method I should use to send the self-issued token by my back-end (I generate it after the end of the LTI flow, extract claims from id_token retrieved from Canvas) to front-end side? Currently, I'm just return a http response redirect and attach the token into the redirect url, but I'm not sure if it's best practice or not? How did you  resolve this problem?

[matthew_buckett]

Hiya @thohoangngo 

Putting the token in the URL works fine but has some downsides:

• The token appears in the browser history and may get leaked (eg to other websites). Depending on your app this might be acceptable, but if for example you're dealing with grading you might want better security.
• The URL is size limited. It can be useful to include lots in the token and you can end up running out of space in the URL to encode all the data. Long URLs can also sometimes get filtered by firewalls and so can end up causing problems sometimes.

Ways around this:

- Have the tokens be short lived and provide an refresh endpoint to allow the frontend to retrieve a new token. You could for example have a 60 second lived token in the URL and then once the frontend is loaded it refreshes and gets a new token that is valid for 60 minutes. This also gives you a nice automatic timeout due to inactivity.

- Put something other than a token in the URL. We put a UUID in the URL and the frontend can then use this to retrieve the token. The service that holds a token only allows a token to be retrieved once which means once the tool has loaded the URL doesn't need to be considered secret any more. This works ok, but means that you can't open your tool outside the Canvas iframe as the token always fails to load. It also means the backend that temporarily holds the tokens needs to have state (eg DB or in memory cache).

All the best.

Matthew

[thohoangngo]

Hi @matthew_buckett, thanks for your time and your wonderful sharing information! 😁 Appreciate it!