I've been troubleshooting it in many separate occasions since 2018. I THINK I FIGURED IT OUT. Somewhat, at least. Thanks to the video, I can also prove that it's a related problem and actually say what the fix is. I can only speculate on the actual problem though since I still don't know what scenario causes it.
Solution?
Try both specifying *.instructure.com, *.google.com, and allowing third-party cookies while ensuring that any adblockers are disabled for Canvas. Suboptimal to say the least, but it looks like in specific scenarios, the cookies needed to complete the handshake for the Google Drive LTI by Canvas embedding are triggering the "third-party cookie" blocking.
Discovery
So, one thing I started noticing recently is that it says "Third Party Cookies are blocked." Every single time. Which, I should also note that typically in the situations where this bug occurs, Google Drive integration (submitting assignments) is fine, but it's the Google Drive LTI by Canvas plugin (that embeds Google Drive links) that breaks and has the authorization loop. Specifically, Google Drive LTI by Canvas has to generate cookies for what I can categorize as two different site locations: Google (and related subdomains/links such as account.google.com) for authorization and Google Drive LTI by Canvas (https://google-drive-lti-iad-prod.instructure.com/). Google plugins can, simply put, be of two types - site-based, or Google-based. A Google-based plugin can only interact with whatever libraries it contains - however, site-based allows conventional programs and interfaces to be hooked up, at the cost of requiring a site location to host the app integration (in this case, https://google-drive-lti-iad-prod.instructure.com/). Hence why one can break and the other can be fine - they are implemented into Canvas in dramatically different ways even if they appear to be more or less functionally the same.
The strange thing about this is that we would do all the steps outlined (clear cookies, rebuild local profile, reset cache, etc) and it would never work. We would specifically put in an allowance for *.instructure.com, and even those that specified the subdomain and address for specific scenarios, and yet no dice. Only in this scenario, I noticed something different - it was making cookies, but it wasn't accepting ALL of them.
Why? (AKA rambling speculation)
As to what scenario this is caused in - I still don't have enough to do more than speculatively guess, since I'm unable to reproduce the problem for further testing. It seems to be session-specific since even in private mode it functions fine. When I checked the data of the cookies, while they did note their site of origin, most of the fields were blank - my current guess is that cookies that are needed to confirm the "handshake" between the LTI and Google can be improperly generated in a scenario. While suboptimal to say the least, disabling anything that would filter or block cookie generation allows it to once again operate as intended. In this scenario, it actually triggered on a clean install of a computer, as well as Chromebooks in a group.
I want to say...that the problem is related to renewing, modifying or generating the LTI-specific cookies. As far as I can tell, the Google side of the auth isn't failing - it's only ever when the Google-side of the auth completes and the browser focus returns to the Canvas side that the auth fails. It's got to be some way that Canvas is identifying clients or identifying connection paths in some manner that errors out server-side - it almost feels like the client sends it cookie data for it to modify and return, but instead all of the fields in the cookie return as (null).
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.