Last Comment Bug 442373 - Implement/Investigate OAuth support
: Implement/Investigate OAuth support
Status: RESOLVED FIXED
:
Product: Calendar
Classification: Client Software
Component: Provider: GData (show other bugs)
: unspecified
: All All
: -- enhancement (vote)
: ---
Assigned To: Philipp Kewisch [:Fallen]
:
Mentors:
http://code.google.com/apis/accounts/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-27 14:53 PDT by Philipp Kewisch [:Fallen]
Modified: 2014-11-18 11:44 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Philipp Kewisch [:Fallen] 2008-06-27 14:53:33 PDT
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.
Comment 1 Philipp Kewisch [:Fallen] 2008-08-06 18:01:33 PDT
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
request token
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.
Comment 2 Philipp Kewisch [:Fallen] 2008-10-07 02:19:57 PDT
Based on comment #1, -> CANTFIX
Comment 3 ildar 2011-07-11 21:17:47 PDT
(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?
Comment 4 Philipp Kewisch [:Fallen] 2011-07-12 12:14:33 PDT
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?
Comment 5 ildar 2011-07-12 23:52:44 PDT
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.
Comment 6 Philipp Kewisch [:Fallen] 2014-11-18 11:44:28 PST
This issue was fixed with the Provider for Google Calendar 1.0.2, I am therefore closing this bug.

Note You need to log in before you can comment on or make changes to this bug.