Use of Oauth2 instead of developer credentials

[mhalano]

A big improvement for Google-4-TbSync would be use Oauth2 (which Thunderbird already deal with) instead to create a developer's credentials to access the People API

[zanonmark]

Hi,

I admit I'm not a big expert of Google authentication stuff.

But:

• Google-4-TbSync is already using OAuth2, and that's for connecting to different Google accounts and addressbooks;
• still, you need a developer account to run the Google app acting as a bridge for the People API.

So, both are needed.

Is there anything different I should be aware of? :)

Thanks, MZ

[mhalano]

@zanonmark I think getting a developer account can be cumbersome for some people. There is no way to authenticate with People API using Oauth2?

[Giermann]

Google started to send notifications with the subject "[Action Advised] Migrate your OAuth out-of-band flow to an alternative method before Oct. 3, 2022"

Although not directly related this issue, I didn't want to open another one. I also found guides to use an API key instead: https://developer.chrome.com/docs/extensions/mv2/tut_oauth/#enable_people

Could this or something else prevent people from creating own client IDs and receive notifications for something they do not understand at all?

[zanonmark]

I think getting a developer account can be cumbersome for some people.

Unfortunately, it is...

There is no way to authenticate with People API using Oauth2?

Well, You are always using Oauth2 in the background.

I think You mean: by using the everyday username + password only, without first creating the developer account? The answer is: no (or: I don't think so) because You always need an app to act like a bridge between TB and Google.

Why can't I create an app for everyone and hard-code the credentials in the source code? Please see the FAQ(https://github.com/zanonmark/Google-4-TbSync/wiki/FAQ-(Frequently-Asked-Questions)) in this website, "About the project", no. 4.

Please let me know in case You know something more :)

Thanks,

MZ

[zanonmark]

@Giermann

I admit I am no expert of Google authentication stuff, but I think You must use the full Oauth2 chain (with a specific app, tokens, etc.) when You're accessing and managing contact data: see link(https://developers.google.com/people/v1/how-tos/authorizing). Any "API key" way wouldn't be valid in this case.

The Google email was a frightening one - but we, as "testing" users, are not involved.

The only way to prevent this would be for me to make an app for everyone and hardcode the developer credentials in the code. But see the FAQ link I provided a couple of messages above.

Thanks, MZ

[Giermann]

Not directly related to "OAuth2", but at least to "developer credentials" and because we just talked about it:

I constantly receive a new dialog to grant permissions to my API developer credentials. Further, the write permission to contacts is always unchecked and I have to check it again. I feel okay by going through all the guides to set up sync again after gContactsSync has been gone. But I don't want to re-grant the permissions every few weeks... Is there something wrong with my installation, or does everybody receive those dialogs from time to time?

BTW: I'm no Google authentication expert neither, but I always ask silently, how other extensions (i.e. CardBook) do the synchronization...

[dustwolf]

OAuth should be done using the interactive web interface, like you have with Thunderbird, instead of leading the user through a maze in the google developer API stuff. I believe this is what the OP is trying to say.

Looks like this: https://i.stack.imgur.com/3h3Bc.png

[dustwolf]

Why can't I create an app for everyone and hard-code the credentials in the source code? Please see the FAQ(https://github.com/zanonmark/Google-4-TbSync/wiki/FAQ-(Frequently-Asked-Questions)) in this website, "About the project", no. 4.

Why do I need to create my own Google API Console project credentials? Can't they be stored into Google-4-TbSync like other applications do? Google-4-TbSync is an open source project; consequently, hardcoding the Google credentials into the code would still leave them in clear, which is forbidden by Google. So you have to create them by yourself.

This (that it is forbidden by Google) is not true. See documentation: https://developers.google.com/identity/protocols/oauth2#installed

The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)

[dustwolf]

Here is the Thunderbird / Firefox Client ID embedded in the source code: https://searchfox.org/mozilla-central/source/services/fxaccounts/FxAccountsCommon.js#101

No complaint from Google, obviously.

[gwes]

Just adding a +1 to this.

Adding API keys is not something a "normal" user should be trusted (or frankly required) to do.

I'm afraid I can't offer a solution myself but think that there must be one as other programs (TB included) do just pop up the google page asking for authentication without requiring the user to generate keys.

[gwes]

As an aside, if as an IT Support provider, I were to want multiple users to have Google-4-TbSync installed, could I just use one set of API credentials?

[Giermann]

I have been away for a few months, as I found that DAV-4-TbSync was still supporting Google Contacts with a hidden preference. Today, thunderbird decided to automatically update to 102, which removed this feature according to this issue: https://github.com/jobisoft/DAV-4-TbSync/issues/240

As I do not like CardBook at all, I'll be back with Google-4-TbSync. But I already know, that I will annoyed by the repeated confirmations of granted permissions...

Maybe you can ask jobisoft, how OAuth2 was handled in DAV-4-TbSync in the past?

[zanonmark]

Hi all,

too many questions here... trying to address the main ones:

@dustwolf About the credentials not to be released in open source projects. https://developers.google.com/terms/#b_confidential_matters " Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects. " Only because Google is closing their eyes on Firefox, it doesn't mean they're allowing everyone to violate their own terms.

@gwes I'm not happy with this solution myself, I know it's cumbersome, but I currently am not able to find another one. But I'm open to new advices of course.

@gwes Yes, You can create one set of credentials for Your Company and use them on every PC.

@Giermann About You repeatedly granting permissions. There's something wrong in Your installation. I never had to re-grant the permissions in mine. Please remove the add-ons, install the latest one, reinstall it and make the Google-4-TbSync account configuration from scratch. If the problem persists, please open a new ticket.

Thanks, MZ

[dustwolf]

I quoted above in Google's own words how what you quoted does not apply in this case.

[zanonmark]

@dustwolf I see Your point, but I cannot fully agree.

So far, we have:

Google: " In this context, the client secret is obviously not treated as a secret. "

Google: " Developer credentials may not be embedded in open source projects. "

various Stack Overflow posts, among which this one, this one and especially this one.

All in all, I can't say I'm 100% sure it's forbidden... but You can't say it's 100% allowed. The situation is not clear at all.

At this point - until any other modification to the Terms - I don't feel like trying and see what happens. It's better be safe, and let users create their own credentials.

Thanks, MZ

[dustwolf]

Basically means this bug will not be solved until someone forks the project and does it right.

[gwes]

Ciao Marco,

Thanks for the response.

As others have stated I think there must be a way that you can include whatever is required to make the auth work but I understand that, from what you can see, this is not allowed and it's your project. Anyone who wishes to could fork the project and include their keys if they so wish.

I'll work out how to use 1 key for all of my customers who use TB and work around the problem that way.

Thanks for making this project.

[zanonmark]

Hi @dustwolf, @gwes,

of course this project can be forked; if anyone is willing to do so, just change the project name after the fork (to avoid confusion between the versions).

I'm keeping this issue open because I hope Google can modify the Terms one day...

Thanks, MZ

[jgato]

the problem is if you have a Google Workspace account, where the account belongs to an organization. I cannot create my own project/app under the organization. So, I dont see how I can use this extension :(

[zanonmark]

@jgato The Google account used for creating the credentials and the one You want to synchronize with may be different.

So You, as a developer, with a "normal" Google account (say "foo@gmail.com"), can create the credentials. Then You, as a user, can use Google-4-TbSync to synchronize with another "bar@gmail.com" addressbook.

MZ

[jgato]

worked, thanks :)

@jgato The Google account used for creating the credentials and the one You want to synchronize with may be different.

So You, as a developer, with a "normal" Google account (say "foo@gmail.com"), can create the credentials. Then You, as a user, can use Google-4-TbSync to synchronize with another "bar@gmail.com" addressbook.

MZ

[Giermann]

All in all, I can't say I'm 100% sure it's forbidden... but You can't say it's 100% allowed. The situation is not clear at all.

At this point - until any other modification to the Terms - I don't feel like trying and see what happens. It's better be safe, and let users create their own credentials.

Thanks, MZ

I was reading https://developers.google.com/terms/#b_confidential_matters again and wondered, if they distinguish between "Developer credentials" and "Normal/production credentials"... It is only said, that "developer credentials" may not be embedded in open source projects. But as @dustwolf already said, here is another publishing of client secrets in their open source code: https://github.com/mozilla/releases-comm-central/blob/master/mailnews/base/src/OAuth2Providers.jsm#L68

Unfortunately, these may not be used to access the People API...