LTI 1.3 OIDC login process

AitorCuesta
Community Explorer

I'm involved in an LTI 1.3 integration with Canvas and I'm struggling with the parameters I'm receiving in the POST init request.

I've been involved in other LTI platform integrations like Blackboard, Moodle and I also have my own IMS Reference Implementation Test Tool integration. In all of those integrations, I'm receiving client_id and lti_deployment_id parameters within this initial login request. That's great because I have a unique way to identify which platform is invoking me, get the right configuration and redirect the login request to the proper OIDC Authentication endpoint.

But from Canvas, I'm only receiving the client_id which doesn't seem to be a unique value. I have configured a self-hosted Canvas and some developer keys which seem to use a sequential starting in 10000000000001 and that's the value I'm receiving within the client_id. That sequential looks a bit problematic because two different installations will probably get the same identifier.

I have also checked some resources like https://canvas.instructure.com/doc/api/file.lti_dev_key_config.html and I'm starting to think that I'm looking at this integration from the wrong perspective.

According to that latest link, it seems that Canvas uses/recommends a kind of cloud-hosted solution. That's why all the OIDC auth redirects should be to the same URL. Am I right?

But, what happens with self-hosted installations? I can't redirect their login requests to https://canvas.instructure.com/api/lti/authorize_redirect because it won't work. In this situation, how do you identify the Canvas installation?

Thanks in advance

Labels (3)
0 Likes