Securing LTI app communication after launch

[z_dusatko]

Hello,

I was wondering if anybody has some input on best practices to secure tool provider after successful launch. I will have a rest api server (Java Spring with React.js) as a provider and I think it should create some web token (jwt or Spring might provide something already) for the current Canvas user and attach this web token with each http request in Authorization header. Since LTI was already successfully launched I assume I don't need another user login and this web token should be created automatically on providers server side. Basically how can I prevent middle man attack after LTI launch?

Thanks,

Zbynek

[ColinMurtaugh]

Hi Zbynek --

The LTI launch is secured in two ways: the request itself is encrypted via SSL (so make sure that your tool provider is always served using HTTPS), and the contents of the launch are signed by Canvas using the tool provider's key+secret. This means that nobody should be able to read the encrypted request during transit, and by checking the signature, you can verify that the contents of the request were not changed in transit. 

These two security mechanisms mean that your tool can trust the user identity data that's provided in the request, and you don't need to present the user with another login form. Typically the tool provider will use the name/email/unique ID found in the request to look up or create a user account, and then create a session. The details really depend on the particular needs of the tool, the framework you're using, etc. 

Hopefully this is helpful; let me know if you have questions!

--Colin

[z_dusatko]

Hi Colin,

thanks for the input. I also want to store canvas access tokens for each user (after successful LTI launch I am doing OAuth2 request for user access token). Is it good practice to separate my LTI app session information and user related canvas access tokens in database? I was even thinking to use access token as the session password since it would simplify everything but that doesn't sound too secure.

Thanks,

Zbynek

[ColinMurtaugh]

Hi Zbynek --

Storing the user access token is ok, but you should just be very careful about how and where you store it. Exactly how you do that it is going to depend on your particular application/framework/etc., but you might consider encrypting it before you write it to your database or filesystem (and then you'll need to be very careful with your encryption key). 

--Colin

[pklove]

If you are storing the access tokens, you might also want to store the refresh tokens.   This will let you get a new access token for a user before/when the access token expires (1 hour) without them having to authorize your application again.

I'd be interested knowing in what you come up with for securing the stored tokens.  Like Colin mentioned, they should be encrypted, and you then also have to deal with handling the encryption key.  I think the latter is the interesting question.

[jb3]

Is there a setting in Canvas to allow cookies in IFrames?

Currently our instance of Canvas LMS does not allow cookies in the tool launch IFrame so we are unable to use session in our LTI's as the LTI page gets a new session for each postback since the id can not be stored in a cookie.

Any suggestions?

[pklove]

I'm not sure this is a Canvas issue.  What browser(s) do you have the problem with and what value does your cookie have for SameSite?

We recently found that setting SameSite caused problems with chrome.  Setting it to Lax was fine for other browsers.