The default bug view has changed. See this FAQ.

Implement/Investigate OAuth support

RESOLVED FIXED

Status

Calendar
Provider: GData
--
enhancement
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: Fallen, Assigned: Fallen)

Tracking

Details

(URL)

(Assignee)

Description

9 years ago
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.
(Assignee)

Comment 1

9 years ago
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.
(Assignee)

Comment 2

9 years ago
Based on comment #1, -> CANTFIX
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX

Comment 3

6 years ago
(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?
(Assignee)

Comment 4

6 years ago
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?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 5

6 years ago
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.
Status: REOPENED → NEW
(Assignee)

Comment 6

2 years ago
This issue was fixed with the Provider for Google Calendar 1.0.2, I am therefore closing this bug.
Assignee: nobody → philipp
Status: NEW → RESOLVED
Last Resolved: 9 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.