Showing results for 
Search instead for 
Did you mean: 

Canvas Google Apps LTI authorization failures

Jump to solution
  • UPDATE Jan 18, 2018  —Still broken. No word on a fix....
  • UPDATE Aug 8, 2017  —Canvas recognizes this is a bug and is working on a fix (Cases #01843701, #01865357, #02000557). Not sure how or where to get updates on their progress.
  • UPDATE Aug 4, 2017  —Still broken. Still no error message suggesting the user switch browsers or login to Chrome with another account. Still many confused users getting frustrated because Canvas doesn't work Smiley Sad.
  • UPDATE Apr 24, 2017 —Still broken. Not answered. Don't let the "Assumed Answered" label fool you.
  • UPDATE Apr 20, 2017 —Still broken. No movement to fix on Instructure's part. They say it's "working as designed." If so, their design that forces students to jump through more hoops (see comments below) to access course content is a bad one. The goal should be to minimize navigation efforts and maximize access to content. The Canvas Google Apps LTI fails in this criteria.

ORIGINAL ISSUE, AS IT STILL STANDS — The Canvas Google Apps LTI authorization is failing on me in Chrome in one course (not others), and observed with faculty. Anyone else? Workarounds?The chat with Instructure support helped determine that it worked in Firefox but not Chrome. They suspected it may have something to do with being logged into multiple accounts. His boss suggested that the Google Apps LTI might need to be re-setup (by our Admin). 

Here's a screencast of the issue: Canvas Google LTI failures - YouTube 

More troubleshooting:

  1. I cleared all Instructure and Canvas cookies,
  2. then logged out of all Google accounts in Chrome,
  3. then shut down and restarted Chrome.
  4. Then opened afflicted Canvas course (
  5. Still saw no Google content and was asked to Authorize. Authorization fails.


  • works in Incognito mode in Chrome.
  • works in other Canvas courses in Chrome.
  • works in Firefox.

Final bit of troubleshooting:

  • it seems to definitely be the Canvas tool's issue. 
  • a manual Google Doc iFrame embed works fine in Chrome, in that course.
111 Replies

Honestly, my teachers would be up in arms if we didn't have this LTI available to them. While it isn't perfect, it's still better for us - especially being in a 1:1 Chromebook setting.


Oh yes,! In a 1:1 Chromebook setting, this has got to be so valuable! My only wish is that it worked for others :smileyplain:


Is there an idea that this account conflict is affecting people with Google Edu domain accounts? I'm wondering if it has something to do with it, or if it's further to do with Google Edu domain accounts with specific restrictions on them? 


I imagine it's possible that some of the problems may be edu-specific, but whenever I replicated the 'authorization failed' errors for Canvas Support I used new accounts to rule that possibility out for them (after having initially seen the errors from my edu Google account). The issues I've seen haven't been specific to our edu instance.

Community Member

Still broken as of June, 2018. Both Google Drive and Office 365 absolutely refuse to authorize in Canvas even though I see Canvas as authorized in my actual Google account. Office 365 doesn't work at all.


The only times we have any issue is if the person is logged into the browser with a different account than their institution google account or if they accidentally authorize the lti to a different account.  I had one teacher who authorized the LTI to her child's student account but once we disconnected and authorized correctly all was fine.


An institution Google account is not relevant to the issue in my case. There is no institution Google account to sign in to. We're told to use our own, personal Google log-in. Office 365 doesn't work, either.


Here it is January 2019 and this is still happening. I will submit a new ticket


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.   


Try both specifying *, *, 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.  


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 for authorization and Google Drive LTI by Canvas (  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,  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 *, 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).  

Community Team
Community Team

Hi, John, 

I'd recommend taking a look at the latest news about Google, as they have a new LTI tool that will eventually replace the one that Canvas built: Google Assignments LTI (Beta) for Canvas Users [Course Kit] 



Top Kudoed Authors