Minor LTI 1.3 Changes: New OIDC Auth Endpoint, Support for Platform Storage

[xmoffatt]

• For Canvas admins:
• What is changing?
• How is this change being communicated?
• For LTI 1.3 tool developers:
• What is changing?
• What is the OIDC Auth Endpoint?
• Why is it changing?
• What will you need to change?
• What are the consequences of not making this change?
• When is this change happening?
• Who is behind this change?
• LTI Platform Storage Overview and Support Update

Canvas is changing its LTI 1.3 OIDC Auth domain to align with security practices and to support the new LTI 1.3 Platform Storage specification. This specification lets LTI tools function when browsers disable cross-site 3rd-party cookies. LTI 1.3 tool developers, read on for an implementation guide and the full status of Platform Storage support. These are not breaking changes.

For Canvas admins:

What is changing?

We are asking tool developers to update some of the Canvas URLs that they store in their tool configuration. The old URLs will continue to work, but updating will prevent future possible issues with LTI Tools and the Content Security Policy feature, and will allow tools to take advantage of a new 1EdTech LTI 1.3 specification called Platform Storage.

Platform Storage is an 1EdTech LTI specification that allows tools to function when browsers disable cross-site cookies. Until now, tools launching from Canvas have relied on cookies to store information. Browsers have been locking down this behavior to protect users from marketing and ill-intentioned uses. Since tools have a valid need for these cookies, we have enabled a way for them to store information with Canvas instead of as a cookie, so they are not impacted.

As a Canvas administrator, this change will only require work on your part if you have LTI 1.3 tools configured for your account that you needed to configure yourself. For example, if you installed an LTI 1.3 tool and as part of the setup you had to enter URLs from Canvas like the OIDC Auth endpoint or Public JWKs URL, then you will need to update those URLs in the tool's configuration. Specific steps can be found in the "What will I need to change?" section below.

Otherwise, this won't require any work on your part! LTI 1.3 tool providers wishing to use Platform Storage will need to implement the specification on their side in order to allow them to continue working when cross-site cookies are disabled, but those changes should not require any modifications from within Canvas. You will need to work with the tool providers directly to learn more about their plans to implement this specification.

On August 19, 2023 (July 17 for Beta), the Platform Storage API will be fully supported by Canvas, and the OIDC Auth endpoint and other 1.3 configuration URLs recommended in our API docs will change. No existing LTI 1.3 behavior will break after those dates, and tools do not need to switch endpoints before those dates. We recommend that all 1.3 tools move to use these endpoints as soon as possible, but will not be enforcing the change at this time.

If you’re curious, you are more than welcome to read the rest of the article to understand the context behind these changes!

How is this change being communicated?

In addition to being posted here, notices that link to this article will be posted in our API Docs, on the Developer Keys page in Canvas, in the Canvas release notes, and sent to our LTI partners. You are welcome to contact your tool providers to make sure they have seen this information and learn more about their plans to implement the feature.

If you have questions about this process, please contact Instructure support through the normal avenues and be sure to mention LTI Platform Storage.

For LTI 1.3 tool developers:

What is changing?

The domain of the OIDC Auth endpoint and other Canvas endpoints used in configuring LTI 1.3 tools is changing from canvas.instructure.com to sso.canvaslms.com. The reasoning behind this change and the exact modifications you will need to make are all documented below. You can make these changes at any point starting now.

In addition, the 1EdTech specification for Platform Storage will be fully supported in Canvas on August 19, 2023 (July 17 for Beta) for LTI 1.3 tools. Canvas already supports most of this specification, and tools are already developing against it. An overview of the spec and a full implementation progress update is laid out at the end of this article.

Updating the OIDC Auth endpoint is required to fully implement the 1EdTech specification for Platform Storage. This feature is not supported in LTI 1.1, so we want to take this opportunity to encourage you to begin your migration to LTI 1.3 if you have not yet. We are continuing to develop new and exciting features for LTI 1.3 and it will be the go-forward specification. Note that there is not a sunset date for LTI 1.1 at this time and we are committed to providing 12 months of full support after a date is announced as well as an additional 12 months after that where the code is still available though not fully supported. 

What is the OIDC Auth Endpoint?

It's a canvas endpoint that usually looks like https://canvas.instructure.com/api/lti/authorize_redirect that tools redirect to during the LTI Launch process. The LTI 1.3 Launch flow is built on the OIDC (Open ID Connect) spec, which uses the OAuth 2 Client Credentials flow to securely give credentials (in this case, the LTI launch parameters) to a trusted source (the LTI tool). During tool "registration", or the process of creating a trusted relationship between Canvas and a tool using an LTI Developer Key, the tool is required to store some Canvas-specific configuration variables, one of which is the OIDC Auth endpoint.

Why is it changing?

The canvas.instructure.com domain is not only used for OIDC authentication and redirection, but also for our Free for Teacher offering that lets anyone try Canvas for free. As you can imagine, this free domain comes with both happy users and a lot of spam. The main impetus for this change is to separate the distinct functions of 1) a central, authentication-related domain and 2) an actual Canvas instance open to the public.

The need for this change was emphasized by problems with two separate features, stemming from the browser security feature called the Content Security Policy. The CSP Header helps to mitigate XSS (Cross-Site Scripting) attacks on one domain from another. As you will see, these aren’t capital-P problems like “Canvas doesn’t protect against XSS attacks”, but are instead reinforcements to existing security.

1. Canvas supports configuring this header at the root account level, so that institutions can allow only certain websites to be rendered inside <iframe> elements in Canvas. Domains for installed LTI tools are automatically added to this list, but the LTI 1.3 launch flow also requires the OIDC Auth domain (ie, canvas.instructure.com) to be added to this list.
2. The LTI Platform Storage spec (more on this at the end if you aren't familiar with it) requires that tools send Javascript postMessages to Canvas using the OIDC Auth endpoint for the target origin. This requires a message listener running on that domain, which makes for an interesting engineering puzzle. Since Canvas is a multi-tenant application and domains vary by institution, this required work on our side. The spec allows a platform like Canvas to direct tools to send postMessages to a specific named browser frame, which helps to solve this specific problem. However, rendering this listener frame also requires the OIDC Auth domain to be added to the CSP list.

This is where the duties of canvas.instructure.com start to work against one another. As the OIDC Auth domain, it's required to be present in the CSP header so that it can serve content inside iframes in Canvas. But, as the Free for Teacher domain, there is a lot of content that it serves that can be spammy or even malicious. We aren't comfortable making that tradeoff and don't want to enable content from canvas.instructure.com to be served to every other Canvas institution.

Enter sso.canvaslms.com, a newer domain that performs just the right function we need - centralized authentication and SSO login. This domain has been around for a while, and presented the perfect solution to this CSP dilemma. Content served from this domain is only from Instructure, and so can be confidently added to the CSP header, and used as the new OIDC Auth endpoint for all LTI 1.3 tools moving forward.

What will you need to change?

Right off the bat, it's crucially important to note that the Issuer Identifier (iss) is not changing. That will continue to be canvas.instructure.com, since that is a unique identifier for Canvas as an LTI Platform, and not actually a URL.

Other than that, any Platform-related URLs that live in your tool's datastore that use canvas.instructure.com should switch to using sso.canvaslms.com.

URLs that will change:

• The OIDC Auth endpoint, also called the Authorization Redirect URL
• Old: https://canvas.instructure.com/api/lti/authorize_redirect
• New: https://sso.canvaslms.com/api/lti/authorize_redirect
• The Canvas Public JWKs endpoint
• Old: https://canvas.instructure.com/api/lti/security/jwks
• New: https://sso.canvaslms.com/api/lti/security/jwks
• The Grant Host endpoint, sent as the aud claim in LTI Advantage API tokens
• Old: https://canvas.instructure.com/login/oauth2/token
• New: https://sso.canvaslms.com/login/oauth2/token

In addition, any references to other Canvas environments like Beta and Test should also change in the same manner:

• canvas.beta.instructure.com becomes sso.beta.canvaslms.com
• canvas.test.instructure.com becomes sso.test.canvaslms.com

As a side note, there are some tools and institutions that use their direct Canvas domain in place of canvas.instructure.com for these endpoints. Though this practice doesn't technically conform to the LTI spec, it's accepted and will continue to work with both *.instructure.com domains, and all vanity domains. These configurations do not need to switch to the new endpoint to continue working, although we recommend using the new endpoint to conform to the LTI 1.3 spec. However, note that to fully conform to the Platform Storage spec, postMessages must be addressed to the OIDC Auth endpoint defined by the platform, which in this case will be sso.canvaslms.com.

What are the consequences of not making this change?

You may have already picked up on the fact that even though we are asking you to use sso.canvaslms.com, canvas.instructure.com still exists and works. These endpoints are accessible from every Canvas institution, even your own. There isn't a point in time where using https://canvas.instructure.com/api/lti/authorize_redirect during the LTI 1.3 launch flow will suddenly stop working.

But, there are consequences for not making this change. You can decide how severely these will impact your tool. If a tool does not switch domains:

1. The tool will not be able to fully conform to the Platform Storage specification. For now, Canvas will still accept postMessages with a target origin of *, even though this limits postMessage security. Eventually, all tools will need to use the new OIDC Auth domain for the target origin for all postMessages. LTI launches that don't properly use the Platform Storage spec will be open to MITM (man in the middle) attacks. LTI tools can decide whether to use cookies or the Platform Storage spec in most browsers, but in browsers that block 3rd party cookies (like Safari), they will need to correctly store the state parameter in Platform Storage.
2. In the future, if a Canvas institution in which the tool is installed decides to enable the CSP feature and restrict domains that can serve content in that institution, launches to the tool will fail unless the institution admins explicitly add the old canvas.instructure.com domain to the CSP Domain Allowlist. The tool developers will need to communicate with the institution admins directly, as Instructure won't provide support for making this change. We do not yet have an enforcement date for this, as we want to provide tools with the necessary time to make the change so that we minimize impact on educators. We will announce the enforcement date as we monitor tools’ migrations to the new endpoint.

When is this change happening?

Tools are free to change their stored config for Canvas and use this new endpoint starting right now. We recommend that all 1.3 tools begin using this new endpoint as soon as possible, but it's important to note that no current LTI 1.3 behavior will break if tools do not update their configuration. This is an opt-in change for now, and enforcement of consequence 2 listed above will happen on a later, unspecified date - accompanied by a 90-day change notice.

However, tools wishing to use Platform Storage should note that the consequence listed in point 1 above will take effect in Beta on July 17, 2023, and in Production on August 19, 2023. In addition, the full implementation of the Platform Storage API will be enabled that day, including the requirement to use sso.canvaslms.com for the target origin of Platform Storage postMessages (see the support update below for exact details).

Notices that link to this article will be posted in our API Docs, on the Developer Keys page in Canvas, in the Canvas release notes, and sent to our LTI partners via newsletter.

If you have questions about this process, please contact Instructure support through the normal avenues, and be sure to mention LTI Platform Storage.

Who is behind this change?

The Interoperability (or Interop) team focuses on LTI in Canvas and enabling all of our 3rd-party tools and partners with LTI APIs, Developer Keys, and a few other tools like Live Events. We wanted to take this opportunity to introduce a couple of ourselves to the Canvas community!

My name is Alexis Nast, and I joined Instructure in January 2022. Before this, I worked as a middle school math teacher and then as a product manager at other software organizations. I’m the product manager for the Interop team, and I look forward to continuing to work closely with both schools and ed-tech integrators.

And I'm Xander Moffatt, a software engineer on the Interop team. I first joined Instructure in 2017 for an internship and never (really) left. I've been working on LTI-related code for a while now, and contributed to the Platform Storage spec as a member of the LTI working group.

LTI Platform Storage Overview and Support Update

Some browsers (as of writing, only Safari) block 3rd party cookies inside iframes - that is, cookies set on a domain that is different from the domain of the parent frame. The main reason for this change is to discourage tracking for ad/marketing purposes. This interrupts some LTI 1.3 functionality, including securing the two halves of the launch process together, and setting cookies as a tool inside an LTI iframe.

The LTI working group established the Platform Storage spec to let tools still accomplish these goals by treating the platform (in this case, Canvas) as a storage method for cookie-like data, using the window.postMessage API, the standard for cross-frame Javascript communication. This will help tools secure their launches, prevent MITM (man in the middle) attacks, and continue to function inside Canvas as they have in the past.

There is work required on the tool side to take advantage of these new APIs, mostly during the login and launch requests to store and retrieve the state parameter. There is a tool-side implementation guide that is part of the LTI spec, and for other information about using postMessage in Canvas, please see our API documentation.

Canvas supports almost all of the spec, with a few important exceptions. Until August 19, 2023 (July 17 for Beta), Canvas will not accept any messages that use the OIDC Auth URI origin as the target origin, which is an important part of securing these messages to provide the same end-to-end launch security as using a cookie to store the state parameter. After August 19, 2023 (July 17 for Beta), Canvas will conform fully to the spec in all regards. Details are laid out below, organized by the section of the specification they regard, as well as links to the various spec documents:

LTI Client Side postMessages

• ➖ 2: Canvas supports most of this section, with some caveats below.
• ✅ 2.2: target frame will be provided by the lti_storage_target body parameter in both login and launch requests, as well as in the response to the lti.capabilities postMessage. Until August 19, 2023 (July 17 for Beta), this value will be _parent or not present, which signifies that tools should use the parent frame. After then, the value will be post_message_forwarding, which signifies that tools should use the frame with that name.
• ❌ 2.3.2: the OIDC Auth URI Origin will not be accepted as a target origin until August 19, 2023 (July 17 for Beta). Until then, tools should use the * target origin for all messages, which isn’t part of the spec.
• ✅ 3: Canvas supports all request parameters and conforms to all response parameters and error codes in this section.
• ✅ 4: Canvas supports the lti.capabilities message and response in its entirety. Until August 19, 2023 (July 17 for Beta), all returned subjects will not have a frame parameter, signifying that tools should send these messages to the parent frame. After then, the lti.get_data and lti.put_data subjects will have frame: 'post_message_forwarding' to signify that those messages should be sent to the frame with that name.
• ❗Note that in a previous version of this spec, the subject for this message was org.imsglobal.lti.capabilities, and was simplified after IMS Global was renamed to 1EdTech. Canvas currently supports both formats, and will remove support for this previous format after August 19, 2023 (July 17 for Beta).

LTI postMessage Storage

• ➖ 1: Canvas supports most of this section, with some caveats below.
• ❌ 1.1.1.1: Until August 19, 2023 (July 17 for Beta), Canvas will not accept any messages with the OIDC Auth URI origin as its target origin. After then, Canvas will conform fully to this portion of the spec.
• ✅ 2: Canvas conforms to all request and response message definitions for lti.get_data and lti.put_data.
• ❗Note that in a previous version of this spec, the message subjects for this section were org.imsglobal.lti.get_data and org.imsglobal.lti.put_data, and were simplified after IMS Global was renamed to 1EdTech. Canvas currently supports both formats, and will remove support for this previous format after August 19, 2023 (July 17 for Beta).
• ✅ 3: Canvas provides the minimum storage limits for each tool to use.
• ✅ 4: Canvas uses localStorage as the backing for this API, which has no Time-to-Live. It does not encrypt any data before storing it. If tools wish their data to be encrypted, they should do it before storing it.

Implementation Guide

✅ 2.1: Canvas sends lti_storage_target as an extra body parameter in both the login and launch requests. Until August 19, 2023 (July 17 for Beta), this value will always be _parent, signifying that tools should send all messages to the parent frame. After then, the value will be post_message_forwarding, signifying that the Platform Storage messages should be sent to the frame with that name.

[suave77]

Hello! This article was helpful, however I am wondering if the timing on this could be adjusted. Many people head back to school in August, this is a short time frame for some to make these changes. This looks like it could affect a number of institutions potentially.

[bryan_melville]

Hi, is the new Developer Keys report in Account>Settings>Reports (also available in Subaccounts) the best way of identifying the 1.3 LTIs?

[SarahBlanton]

I’m concerned about the timing of this change - just two days before our fall semester starts. What will the impact of this change be for 1.3 tools that we currently have installed?

[AlexisNast]

@suave77 and @SarahBlanton These changes should not require any work on the part of administrators. You may choose to reach out to the tools, but the only thing that will be impacted by this change is the new Platform Storage specification. Since the specification support in Canvas is new with this same release, we do not believe any tools are using it with Canvas at this time. The old endpoints will continue to work for every other LTI endpoint. This change will also be available ahead of time in Beta (July 17th) and if you test and find issues we will do our best to ensure they are resolved before production launch.

The reason we are pushing this out now is that we have heard from some browsers that they intend to lock down cross-site cookies in 2024. This would break many of our 3rd party tools if we weren’t able to provide Platform Storage. We want to ensure we provide support for Platform Storage with enough lead time for the tools to develop solutions using it before the browsers lock down cookies to minimize impact to schools. We understand the stress of any changes happening at back-to-school, and did not make this decision lightly and want to ensure continuity of services as best we can.

@bryan_melville That report is a great way to identify all of the LTI 1.3 tools your org uses!

[SarahBlanton]

@AlexisNast Thank you very much for clarifying. That helps immensely.

[schillingt]

As a tool developer, what changes should I expect from self hosted canvas instances? Will the recommended self-hosting path involve changing the domains from myschooldomain.edu to something like sso.myschooldomain.edu?

Additionally, do you expect the `postMessage` origin parameter to also require the school's domain?

[xmoffatt]

@schillingt Great question! Self hosted canvas instances can continue to choose their own OIDC Auth domain (usually the same domain that their instance is hosted at). This switch is only for Instructure-hosted Canvas instances. I would recommend that self-hosted instances don't change their OIDC Auth domain.

Yes, to conform to the Platform Storage spec, postMessages sent to self-hosted Canvas instances would need to be sent to that same domain. does that help?

[xmoffatt]

All,

I posted a slight update to this post to address some of the questions that Alexis has kindly already answered. Thank you all so much for your great feedback!!

[n00831987]

@xmoffatt we've switched our internal LTIs in beta and then the only output we get is this when trying to load it: 

Despite adding it to the CSP whitelist. 

Refused to frame 'https://sso.canvaslms.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' sso.canvaslms.com sso.staging.canvaslms.com sso.beta.canvaslms.com sso.test.canvaslms.com sso2.canvaslms.com sso2.staging.canvaslms.com sso2.beta.canvaslms.com sso2.test.canvaslms.com".

[xmoffatt]

@n00831987 that's concerning! I just tried it to make sure and saw that it was working for me. During the authorize redirect step of the launch, are you POSTing to "https://sso.canvaslms.com/api/lti/authorize_redirect" or "https://sso.beta.canvaslms.com/api/lti/authorize_redirect" or a different URL entirely?

[schillingt]

Hi @xmoffatt, I had a follow-up question. The go-live for this is Aug 19th for production, but when is the cut off date for the wildcard value?

Edit: re-reading the post indicates it's an eventual thing and likely a date hasn't been set. You can ignore that question.

I do have a different question, what about LTI 1.1 integrations that need to communicate with the parent window. Would those also need to use "sso.canvaslms.com"?

[xmoffatt]

@schillingt yep no currently set cut off date for the wildcard 👍

none of this applies to LTI 1.1 tools, so any postMessages sent from 1.1 tools can continue to be sent directly to the parent window with the wildcard target, or using the parent window's domain as the target. In addition, any non-Platform Storage postMessages can continue to be sent by 1.3 tools directly to the parent window. You can reference the API doc page for postMessages as well!

[tbigby]

@xmoffatt Hi Xander, I'm getting the same problem as @n00831987 . Did either of you make any progress? Currently my LTI is failing to load in our school's Beta environment due to this as I am already using Platform Storage to avoid Third Party Cookie problems.

The CSP error is actually coming from `https://sso.canvaslms.com/post_message_forwarding?token=...` .

Firstly on my LTI page (eg. /accounts/1/external_tools/1234) there is an iFrame added with frame name "post_message_forwarding" and URL `https://school.beta.instructure.com/post_message_forwarding`. That gets a 302 redirect to `https://sso.canvaslms.com/post_message_forwarding`. Then that page won't load due to the CSP error, as it is being framed by 'school.beta.instructure.com'.

It makes sense that the 'post_message_forwarding' frame will be used to pass on the Platform Storage Post Message, but unfortunately it can't load.

Of course I believe I am using the new Spec correctly and sending the Platform Storage Post Message to the "lti_storage_target" frame that the LTI launch specifies. I did just test ignoring the "lti_storage_target" and using "window.parent || window.opener" instead, and then the LTI did authenticate correctly.

---

@xmoffatt wrote:

are you POSTing to "https://sso.canvaslms.com/api/lti/authorize_redirect" or "https://sso.beta.canvaslms.com/api/lti/authorize_redirect" or a different URL entirely?

For me, this is happening before the POST to "authorize_redirect". My tool loads its initial Javascript, and tries to send the Platform Storage Post Messages to save the State and Nonce values first. Only after the initial Javascript receives the Post Message Responses from Canvas, does it trigger the "authorize_redirect" call. When the CSP error occurs for "post_message_forwarding", the Post Messages never make it through and therefore the Post Message Responses from Canvas don't either.

I'm happy for you to contact me directly at my school email, hopefully that shows up to you in the backend of this Community - otherwise please let me know if I can assist at all.

Many thanks, Tony Bigby

[xmoffatt]

@tbigby ahhh, thank you for clarifying that. I am seeing the same thing and have tracked it down to the fact that it's trying to render the message forwarder at `sso.canvaslms.com` instead of `sso.beta.canvaslms.com`, to match the OIDC Auth Endpoints for each environment. I will post back here again when that change has been deployed to beta and the postMessages are working again.

@n00831987 and thank you for raising the issue earlier, sorry I didn't totally understand what was happening at that point!

[K-Diddy]

I know this is going to sound ridiculous, but I don't believe I'm alone: This hurts my head. Is there any way you can post a screen shot saying something like, "if this field looks like this, then you need to update here?" Better yet, can Canvas write a script or something to make the necessary updates? I really don't need the hows and whys, but if you're telling me it's important, I want to comply.

I'm also concerned about the timing. Our semester begins August 21. 

[xmoffatt]

@K-Diddy Don't worry, I totally understand. This is a pretty niche change!

> can Canvas write a script or something to make the necessary updates?

These changes have to happen on the tool side of things, which is why we are publishing this post and spreading the word. If we could have written a script, we definitely would have! 🙂 

A screen shot is a great idea! Since this is a tool-side change like I mentioned above, you as a Canvas admin only have to worry about tools that during install required you to configure some things on their site (not in Canvas) like this:

(screen shot from this tool's install guide )

You would change the domain in all the "URL" fields.

> I'm also concerned about the timing

I hear that, but want to stress again that nothing will break if you don't make these changes right when they are first available. The changes to the URLs are purely to enable tools to correctly implement the brand new LTI Platform Storage spec if and when they choose to do so. We will communicate broadly again well before we make these changes into requirements!!

Hopefully that clears things up! Let me know if anything doesn't make sense.

[xmoffatt]

@tbigby @n00831987 the postMessage forwarder is now correctly rendering at `sso.beta.canvaslms.com` and so your postMessages should be working again! thank you again for bringing it to our attention 🙂 

[tbigby]

Thanks very much for the update @xmoffatt ! Unfortunately, it's still not happy.

The 302 is now redirecting to `sso.beta.instructure.com/post_message_forwarding`, which is good. However, a) that page won't load and instead returns a 401 status, and b) the browser wouldn't load it anyway as it still shows the CSP error:

Refused to frame 'https://sso.beta.canvaslms.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' sso.beta.canvaslms.com sso.canvaslms.com sso.staging.canvaslms.com sso.test.canvaslms.com sso2.canvaslms.com sso2.staging.canvaslms.com sso2.beta.canvaslms.com sso2.test.canvaslms.com".

Of course the frame ancestor is `school.beta.instructure.com` so not in that list. I don't have the Canvas CSP policy turned on in our instance, but it is evidently set for `sso.beta.canvaslms.com`.

The Post Messages are therefore still not working, but if I switch back to using target origin `window.parent` the Post Messages and the LTI do work correctly.

Not sure if you can look up the 401 error by this header but one of the examples I had showed the header: `X-Request-Context-Id: caeba23e-5c6e-442c-a693-d26033dc64b2`. Otherwise, I'm happy to share more information offline.

Thanks, Tony

[xmoffatt]

@tbigby thanks again for the quick report and for participating in the "comment section bug bash"! 🙂 that context id was crucial in helping me troubleshoot so thanks a bunch.

I tracked down and fixed this error, which was due to some secrets not getting shared across region boundaries. I verified that a page that was broken this morning is now working, so hopefully everything is working for you.

and if you have further problems keep them coming, this is why we spend time in beta to iron stuff out!

[wilsong]

So, in case things blow up when we start next week, if I use the Report for Developer's Keys as suggested above and do a search for the Old URLs in the Permitted API endpoints and get "No results" am I to assume we don't have anything that will be impacted?

• The OIDC Auth endpoint, also called the Authorization Redirect URL
• Old: https://canvas.instructure.com/api/lti/authorize_redirect
• New: https://sso.canvaslms.com/api/lti/authorize_redirect
• The Canvas Public JWKs endpoint
• Old: https://canvas.instructure.com/api/lti/security/jwks
• New: https://sso.canvaslms.com/api/lti/security/jwks
• The Grant Host endpoint, sent as the aud claim in LTI Advantage API tokens
• Old: https://canvas.instructure.com/login/oauth2/token
• New: https://sso.canvaslms.com/login/oauth2/token

Having a video as an example that goes through exactly what we Admins (who also do a thousasnd other jobs at our schools) need to do and look for would be much appreciated. I just can't get through all the details and be sure I know what to change, if anything, and where.

Thanks!

[xmoffatt]

@wilsong the Developer Key report is a great way to identify 1.3 tools as Alexis mentioned above, but it won't contain any of the old or new URLs in it since as I mentioned above, these are tool-side configuration URLs, and aren't stored in Canvas at all. In addition, this won't break anything unless a specific tool has fully implemented this new spec - and if that was the case, I would expect that the tool would either change these URLs themselves or reach out to you. As mentioned in the article itself, these changes are mostly for tool developers and less for Canvas admins.

A video is a good idea, but since none of these changes happen in Canvas, the process won't be the same for every tool (for example, if when you as an admin installed a new 1.3 tool and followed their guide to enter some canvas URLs into their website, that would be a place you can change to the new URLs).

Sorry, I know this is a little confusing and niche, but I want to stress again that this is not a breaking change and doesn't need to be done by next week! It's an opt-in process for tools that want to implement this new LTI feature.

A good way to reassure yourself that things won't break for you next week is to launch your LTI 1.3 tools in your Beta account, since this feature is live there.

[tbigby]

Thanks again @xmoffatt , I am now getting the `/post_message_forwarding` frame loading correctly and with a suitable CSP also, which is great - really appreciate you getting that fixed.

Unfortunately my next issue - I believe I'm now getting a race condition between sending the PostMessage and your forwarding frame loading its Message Listener.

The result being that quite often, I send the PostMessage for State and Nonce, but never receive the Response PostMessage, so I never redirect on to the `/api/lti/authorize_redirect` endpoint.

What I can see in the Developer Tools - Network panel, for both Chrome and Firefox, is the following order:

• school.beta.canvaslms.com/accounts/1/external_tools/<tool id>
• sso.beta.canvaslms.com/post_message_forwarding
• cloudfront.net/dist/webpack-production/post_message_forwarding....js (first time)
• <my tool OIDC initiation URL>
• cloudfront.net/dist/webpack-production/post_message_forwarding....js (second time, seems to be Webpack requesting the chunk again)

From there I usually don't see `sso.beta.canvaslms.com/api/lti/authorize_redirect` called, although it has happened occasionally, then completing successfully (race condition).

I put a browser debug breakpoint in `/post_message_forwarding` and it usually wasn't hit.

I also tested adding a 3 second sleep delay to my 'tool OIDC initiation URL'. That made it work reliably - the delay in launching the tool meant that your `/post_message_forwarding` frame's Message Listener was ready, before the PostMessages were sent. But obviously adding a delay like that is not great!

I should add that my LTI is running as an Account Navigation placement, effectively the launch happens straight away on page load.

Also since we only use Canvas, I'm not bothering with Spec step 2.2 for checking cookie support or calling `lti.capabilities`; am just getting on with the 2.3 PostMessage calls.

Do you have any advice on how to avoid the race condition? I don't seem to be able to access the `/post_message_forwarding` frame's ReadyState, as it is a cross-origin. Also the Spec didn't seem to have any guidance on this.

The LTI is still working reliably if I go back to sending the PostMessages to `window.parent`, and using a Target Origin of `*`, so I'll leave that in Production, but would be keen to use the new method if possible.

Many thanks, Tony

[xmoffatt]

@tbigby yeah I remember when we were developing this spec that same concern of race condition was brought up, and the advice given then was "repeatedly send the message every 50-100ms until you get a response back". The idea is that the Platform should be responding to these pretty quickly and so timing out after just 100 ms or so is alright, and then if you didn't get a response you can just send it again. Plus, if it happens to get the message multiple times it is just storing the same value and so is ok.

I am surprised that we forgot to include that in the actual spec doc, but I will make sure to add something along those lines to our API docs.

[ish-tex]

I understand that there might be a need to update URLs following the pattern *.instructure.com/login/oauth2/token (institutionA.instructure.com/login/oauth2/token) to https://sso.canvaslms.com/login/oauth2/token. Is this accurate?

[tbigby]

Thanks @xmoffatt , that makes sense, I will set an interval to repeat the Post Message send, that does seem the simplest way to get around it.

Thank you once again for your help on all this! Tony

[xmoffatt]

@tbigby and thank you for all your help with this! I really appreciate it.

@ish-tex yes, but only when being used by LTI 1.3 tools to get API access tokens using the Client Credentials auth flow. So, any normal API Developer Key doesn't have to use the new URL, and as is noted in the article "institutionA.instructure.com/login/oauth2/token" will always continue to work. There are tools that prefer to use a "top-level" or centralized URL like sso.canvaslms.com/canvas.instructure.com as that conforms better to the LTI spec but it's not necessary.

[abbyrosensweig]

Just so I understand fully, is there any way for Admins to see when a tool has updated their URL? I know the update is tool-side, but I'm just wondering if we're given any visibility to that so we can know what still needs updating as any future enforcement date approaches.

[xmoffatt]

@abbyrosensweig great question, as of right now there is not. Likely as we approach that unknown enforcement date and make it more official, we will surface that information somehow. From a Canvas perspective, we would only know when the tool performs a launch and uses the new URLs in the launch flow, but seems like that would be super helpful!

[Charles_Barbour]

@xmoffatt wouldn't you then also know when tools are using the old URLs in the launch flow

[xmoffatt]

@Charles_Barbour yes for sure, it would just be a matter of gathering that info into a useable format and presenting it 👍

[hmoffatt]

Hi Xander,

We have a lot of Canvas customers coming to our tool and we are never quite sure which URLs to use. Our customers often just provide us with their Canvas domain (xyz.instructure.com) or vanity domain (canvas.xyz.edu), plus their client and deployment IDs.

Can we use the sso.canvaslms.com URLs in your post in all cases?

Is it only if they are using an xyz.test.instructure.com site or xyz.beta.instructure.com site that we would need to use different URLs?

Thanks

[xmoffatt]

@hmoffatt Hi there, pretty rare to see another "att" Moffatt out in the wild!

great question!

yes, you can always use the sso.canvaslms.com URLs regardless of the Canvas domain they are coming from. and yes, only when they are coming from a beta or test Canvas domain you will need to use sso.beta.canvaslms.com or .test.

Some of our internal tools just check the incoming domain for ".beta." or ".test." but you can also check the `canvas_environment` parameter in the OIDC Initiation request to your tool (see the docs here: https://canvas.instructure.com/doc/api/file.lti_dev_key_config.html)

[hmoffatt]

Thanks @xmoffatt that is very helpful.

Is there any way we can detect that a customer may be running self-hosted Canvas (and presumably then the sso.canvaslms.com URLs would not apply), if we only know their vanity domain? Or is that pretty unusual?

[tbigby]

Hello again @xmoffatt , sorry I have only today got back to the 'race condition' scenario with the Post Message listener, but I wanted to report back that I have now implemented the '100ms retry' and it does work well.

Some logging I did showed that it could take 300-600ms before I got the `put_data` responses, in which case I do receive duplicate responses for some of the `put_data` messages, but as you said the data being stored is always the same so no harm for it to run more than once.

I have rolled out the use of the `post_message_forwarding` frame, and the target origin, to production now - all working well.

Thanks once more for your help! Tony

[xmoffatt]

@tbigby love to hear it!! thanks for your help as well.

@hmoffatt yes there is! I think running into a self-hosted canvas _would_ be pretty unusual, but if that's the case then the `canvas_region` parameter of the OIDC initiation request will have a value of "unknown". In addition, I am pretty sure most if not all self-hosted instances use a different `iss` than us (canvas.instructure.com).

[xmoffatt]

We've edited this post to reflect a temporary change in availability for LTI Platform Storage:

Due to unforeseen issues, Platform Storage access is being temporarily limited to only LTI tools launched in Safari. All non-Safari launches that may be using Platform Storage should fall back to using cookies to secure the LTI 1.3 launch for now, as described in the Platform Storage specification.

We expect to resolve this issue soon in upcoming releases so that LTI launches from all browsers can continue using Platform Storage.

You can direct any questions to me here or in the #canvas-lms IRC channel, but this truly is just temporary while we address some things behind the scenes! Our thought process behind allowing it only for Safari is that right now that's the only browser that truly requires it, since other browsers still allow tools to set cookies. Early adopters, thanks for hanging with us while we iron out some kinks.

A reminder that this only affects the Platform Storage feature, and not the OIDC Auth domain change, which will continue to now be `sso.canvaslms.com`.

[tbigby]

Hi @xmoffatt , thanks for the notification; I just came here to check for details as to why `lti_storage_target` was not being passed through in our Beta environment.

Unfortunately for me, since I was originally trying to avoid third-party cookie issues for the future, I never implemented cookies and went straight for the Platform Storage early this year when the Platform Storage spec was implemented in Canvas in a beta form. Therefore it will be quite a change needed to implement the old cookie method.

I would also like to point out that Firefox, in its 'Strict' Tracking Prevention mode, and Chrome, when 'block third-party cookies' is enabled, do also block third-party cookies. We have had several privacy-conscious staff and students enable these options and then notice issues with other LTIs.

I'm obviously not aware of what issues you have behind the scenes, but from my perspective the Platform Storage beta functionality worked great earlier in the year, and then the recent change needed a little tweaking but also worked well in every browser and case that I saw. If I were to revert to the Platform Storage beta method from earlier this year, of sending postMessages to `window.parent`, would that work anyway, or have you disabled the `put_data`/`get_data` calls?

Also - can you please clarify, will the 'temporary limit to Safari only' apply from the next Production Deploy (which I have as Oct 25th), or from the date above (Nov 13th)? I note it is 'temporarily limited' in Beta now. Sorry, I can't quite get my head around the 'Production Deploy' and 'Production Environment Updated' date differences 🙂

Thank you very much! Tony

[xmoffatt]

@tbigby sorry for the hassle - this ended up breaking some other things for us too and wasn't as helpful for addressing the issues we are looking at, so we have rolled this back! Production was rolled back on Friday and Beta this morning, so you should be seeing that everywhere again.

The date for the now-defunct temp Safari limit was actually "As of Oct 13 until needed", but like I said now it's gone. Platform Storage is once again fully functional!

Very valid point that it's technically not Safari only anymore 🙂 

[xmoffatt]

We've edited this post to remove the references to a temporary change in availability for LTI Platform Storage (see above comment for details). Platform Storage is now available in all browsers again and we do not anticipate making a change like this again! Thank you all for your patience.

[tbigby]

Thanks very much @xmoffatt ! Yes, I can confirm I can see both Production and Beta working again.

Thanks, Tony

[Charles_Barbour]

@xmoffatt , you said:

"You can direct any questions to me here or in the #canvas-lms IRC channel..."

Canvas IRC channel? What is that? I know what IRC is, but I haven't heard of anyone using it in about a decade.

Is it very active and what's the intended usage? Is this something we should have known about?

Thanks!

[xmoffatt]

@Charles_Barbour 

yeah the #canvas-lms on Libera.Chat channel has existed for many, many years as an informal place to hang out and ask questions. It's mirrored to our Slack and occasionally Instructure engineers will jump in and answer questions. It's somewhat active, with a few posts a day. It's not an official support channel but is more for canvas-adjacent developers or school admins.

[Charles_Barbour]

Interesting. When you say "It's mirrored to our Slack..." Is that referencing an internal Instructure only Slack workspace or a public one?

I'm just always fascinated when I find out about these alternative, lesser-known communication channels.

[chriscas]

I had the same question as @Charles_Barbour.. It would be awesome to see that IRC channel content in our slack, but I am definitely not a slack expert and from my simple google searches, I don't see an easy way to mirror IRL content over to Slack.  @xmoffatt, even though this might be a bit off topic, do you know how that setup works exactly?

-Chris

[xmoffatt]

@chriscas it uses https://github.com/instructure/irc-slack-echo to mirror it, which is a custom home-grown little thing that I've never really touched at all.

@Charles_Barbour our internal Slack, yup.

[SP16]

Hey @xmoffatt 
would you elaborate this: " only when being used by LTI 1.3 tools to get API access tokens using the Client Credentials auth flow. So, any normal API Developer Key doesn't have to use the new URL".
As it's quite not clear for me when to change urls and any url with pattern "instituteA.instructure.com" should be changed to "sso.canvaslms.com" or is there any predefined format that needs to be followed?

[xmoffatt]

hey @SP16 , sure I can elaborate.

when to change urls: this change in urls is only for LTI 1.3 tools, and only in places where these 1.3 tools need to make a request to the canvas "OIDC Auth" endpoint - during an LTI 1.3 launch, and in the process getting an LTI 1.3 access token. in any other situation you do not need to change them.

which urls: not quite, the url switch is only from "canvas.instructure.com" to "sso.canvaslms.com". so any thing that you're doing that refers to "institutionA.instructure.com" (like making any API calls, etc) should keep on referring to that without any change. 

does that help?