How to determine LTI 1.3 login / oauth / authorize / jwks URLs

[marcspringshare]

Hi all,

I am finalizing my LTI 1.3 tool implementation, and I am down to one remaining question.  During development I hardcoded some Canvas URLs into my configuration:

const CANVAS_OIDC_LOGIN_URL = 'https://my-canvas-hostname/api/lti/authorize_redirect';
const CANVAS_OIDC_TOKEN_URL = 'https://my-canvas-hostname/login/oauth2/token';
const CANVAS_OIDC_JWKS_URL = 'https://my-canvas-hostname/api/lti/security/jwks';

Now it is time to replace my development URLs with some real values, and I am unsure what I should be using.

This post, https://community.canvaslms.com/t5/Developers-Group/LTI-1-3-Integration-Testing-Error/m-p/227067/hig... indicates you can use "canvas.instructure.com" or "yourserver.instructure.com" for instances hosted by Canvas / Instructure.

I'm assuming that for self-hosted instances, "canvas.instructure.com" will not work and I will need to hit "canvas.myschool.edu" instead.  (Is that right?)  But as a 3rd party, I wont know if a given Canvas site is self-hosted.

Is the best bet to forget about "canvas.instructure.com" and always request over the customer's Canvas domain?  Or do we assume that all Canvas instances are hosted, and see if we run into any edge cases that are self-hosting?

Maybe I'm over thinking things...

Thanks!

[matthew_buckett]

I think you are fine to just always use the customer's domain.

One advantage of using canvas.instructure.com when possible is that because the same JWK file is valid for all Instructure hosted customers you are much more likely to have the JWK cached and so use less resources on your side, but also process the login faster as you don't have to request the JWK when you haven't seen a login for that domain for a while.

[marcspringshare]

Thx for the reply!  This means adding another configuration field to track the Canvas hostname for each customer, but I don't think that is too difficult.  I will give it a try.

[svickers2]

If you are the tool side of the connection, then your customer should provide you with the details of their platform configuration which would include the endpoints you refer to, as well as the Platform (issuer) ID, Client ID and Deployment ID.  (Note that for Canvas the Authorization, or Access Token, Server ID will be the same as its endpoint.)

[hmoffatt]

I didn't see anywhere in Canvas that the admin can easily get all the required details to supply to the vendor - issuer, client_id, deployment_id, and the oauth URLs. In other LMSs all this information is displayed together for easy copy and paste.

Is there a way for the admin to view the oauth URLs?

They are well known for canvas.instructure.com but I have customers using hosted Canvas with vanity URLs (canvas.xxx.edu etc) and I am not sure if the URLs should refer to their domain or to canvas.instructure.com. And some customers may be using self-hosted Canvas where the issuer and all the URLs will be different.