OAuth looks quite promising. Possibly its a more secure source of authentication than the current ClientLogin.
Since OAuth is used for other apis too, this code could possibly be shared with the Google Contacts GSoC Project.
I quote from an Email:
On the OAuth side, Google's OAuth implementation requires RSA signing of
requests in order to validate that the application which the user granted
access to is actually the application which is accessing their data. In
order to sign desktop/installed applications, you would need to send the
private key used for the signing to the client machine. This negates the
benefits of securing the user's data, as any developer could steal" that
private key, use it in their own applications to make requests as if it
was the registered application. OAuth is very much like Google's secure
AuthSub in that respect.
The OAuth token dance works like this:
1) The application requests an OAuth 'request token'
2) The application generates a URL pointing over to Google including the
3) The user authorizes access to their data, and the request token is
'validated' to an authorization token
4) The application exchanges the authorization token for an access token,
which is then used with calendar
So, while theoretically OAuth can work for desktop applications, we don't
have that option available right now.
Based on comment #1, -> CANTFIX
(In reply to comment #1)
> In order to sign desktop/installed applications, you would need to send the
> private key used for the signing to the client machine. This negates the
> benefits of securing the user's data, as any developer could steal" that
> private key, use it in their own applications to make requests as if it
> was the registered application.
Philipp, what do you think of storing the key in password storage area? Could that possibly solve the security problem above?
I think OAuth 2.0 fixes this security issue. This could be implemented if need be. Is there any reason you specifically need OAuth to work here?
Philipp, I consider OAuth as a way to avoid keeping the Gmail password. I suggest having a key is better then a plain-text password. (Though having master password might be more secure).
Anyway having alternatives would help addon developers.
This issue was fixed with the Provider for Google Calendar 1.0.2, I am therefore closing this bug.