I can also confirm that I tested this on Solus and it has resolved the issue.
Thank you.
Just tested this on Fedora 41 with KDE Plasma and it works fine 
there also.
1 Like
I did try the pared down Scope URIs with the KDE ClientID, but as I kind of expected based on your troubleshooting that did not work.
However, your pared down Scope URIs plus the Gnome ClientID and ClientSecret worked just fine.
FWIW, I did also try an App Password, but the password page never took the app password, so your method appears to be the only functioning workaround for the time being.
Thanks for working this out!
1 Like
Thanks a lot. Very smart people here with a lot more skills in this area then I.
1 Like
I’ve done this and it works and that’s cool. However, my understanding of how oauth works is that if an update replaces that underlying file the connections are likely to break when its time for a token refresh, so we should all probably prepare for that.
1 Like
I’ve just come across this too - excuse my ignorance.
I am using Opensuse KDE tumbleweed - I tried swapping the ClientId and ClientSecret for the ones above but I still get the same error. Is the ClientId specific to my particular installation? Where do I find it, if so?
Thank you
Hi - there are also some differences in included URLs and in the parameters between the files - it may be easier to simply back-up the existing /usr/share/accounts/providers/kde/google.provider file, and replace it with the version that @Bruno_Goncalves suggested above.
If you’d rather edit manually, you might need to make each adjustment?
1 Like
Thank you, the configuration file shared by @Bruno_Goncalves worked flawlessly in Debian 12 with KDE!
2 Likes