We are happy to announce that the Google Contacts Data API now
supports OAuth. This is our first step towards OAuth enabling all
Google Data APIs. Please note that this is an alpha release and we may
make changes to the protocol before the official release. I will be
at the OAuth hackathon tomorrow to get feedback and help consumers
integrate.
Caveats:
- We currently only support RSA-SHA1 mode.
- The consumer key is the domain hostname you registered. Currently
there are no consumer_secrets.
- The scope parameter specifies the URL identifying the service to be
accessed. See http://code.google.com/apis/contacts/developers_guide_protocol.html for details about the Google Contacts Data API.
> We are happy to announce that the Google Contacts Data API now > supports OAuth. This is our first step towards OAuth enabling all > Google Data APIs. Please note that this is an alpha release and we may > make changes to the protocol before the official release. I will be > at the OAuth hackathon tomorrow to get feedback and help consumers > integrate.
> Here are the three end points used in OAuth to get a token:
> Caveats: > - We currently only support RSA-SHA1 mode. > - The consumer key is the domain hostname you registered. Currently > there are no consumer_secrets. > - The scope parameter specifies the URL identifying the service to be > accessed. See > http://code.google.com/apis/contacts/developers_guide_protocol.html > for details about the Google Contacts Data API.
In the spirit of Passover, please fill a cup with my name on it and leave it untouched on the table...
A few more weeks and all this East Coast nonsense will be over...
EHL
From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Chris Messina Sent: Friday, April 25, 2008 5:36 PM To: oauth@googlegroups.com Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
YAY!!!!!!!!
I'll definitely sponsor a round of drinks at tomorrow's OAuth Hackathon! ;)
Chris
On Fri, Apr 25, 2008 at 2:29 PM, Wei <weitu+oa...@google.com<mailto:weitu%2Boa...@google.com>> wrote:
Hi folks,
We are happy to announce that the Google Contacts Data API now supports OAuth. This is our first step towards OAuth enabling all Google Data APIs. Please note that this is an alpha release and we may make changes to the protocol before the official release. I will be at the OAuth hackathon tomorrow to get feedback and help consumers integrate.
Caveats: - We currently only support RSA-SHA1 mode. - The consumer key is the domain hostname you registered. Currently there are no consumer_secrets. - The scope parameter specifies the URL identifying the service to be accessed. See http://code.google.com/apis/contacts/developers_guide_protocol.html for details about the Google Contacts Data API.
I've been attempting to get this work with an OAuth consumer &
provider I'm working on in C# - but it appears I'm generating an
invalid signature when requesting a token... as the response from the
server suggests:
I've compared the base_string returned from google to the one I'm
generating and they're identical... so it looks to be a problem with
the way I'm generating the signature.
I've also tested the same request token implementation against termies
test server at http://term.ie/oauth/example/client.php?sig_method=RSA-SHA1 and it works just fine, using the same private key.... so I'm at a bit
of a loss... any chance the certificates changed lately?
We looked and did not see any obvious problems other than that you are escaping the scope URL twice before sending it. However, the base string also shows it escaped twice, so this shouldn't cause a signature failure. However, you may want to try fixing that. One gotcha I have seen with URL escaping from C# clients before is that it uses lowercase letters by default, and the OAuth spec says to always use uppercase letters when generating the base string. Are you sure that your base string really does match bit for bit with the one we returned?
On Fri, May 16, 2008 at 4:26 PM, alex <bitterco...@gmail.com> wrote:
> Hi Wei,
> I've been attempting to get this work with an OAuth consumer & > provider I'm working on in C# - but it appears I'm generating an > invalid signature when requesting a token... as the response from the > server suggests:
> I've compared the base_string returned from google to the one I'm > generating and they're identical... so it looks to be a problem with > the way I'm generating the signature.
> I've also tested the same request token implementation against termies > test server at http://term.ie/oauth/example/client.php?sig_method=RSA-SHA1 > and it works just fine, using the same private key.... so I'm at a bit > of a loss... any chance the certificates changed lately?
I have my consumer implementation working now :) it appears my
signature issues were caused my lack of url-encoding query parameters
prior to including them in the base string, something that wasn't
entirely clear from the first time I read the core spec.
I needed to url encode the "http://www.google.com/m8/feeds" scope
value, prior to the concatenation of parameters and consequent url
encoding in the signature base string (so that it would be encoded
properly).
Cheers,
- Alex
On May 17, 11:56 am, "Jonathan Sergent" <serg...@google.com> wrote:
> We looked and did not see any obvious problems other than that you are
> escaping the scope URL twice before sending it. However, the base
> string also shows it escaped twice, so this shouldn't cause a
> signature failure. However, you may want to try fixing that. One
> gotcha I have seen with URL escaping from C# clients before is that it
> uses lowercase letters by default, and the OAuth spec says to always
> use uppercase letters when generating the base string. Are you sure
> that your base string really does match bit for bit with the one we
> returned?
> On Fri, May 16, 2008 at 4:26 PM, alex <bitterco...@gmail.com> wrote:
> > Hi Wei,
> > I've been attempting to get this work with an OAuth consumer &
> > provider I'm working on in C# - but it appears I'm generating an
> > invalid signature when requesting a token... as the response from the
> > server suggests:
> > I've compared the base_string returned from google to the one I'm
> > generating and they're identical... so it looks to be a problem with
> > the way I'm generating the signature.
> > I've also tested the same request token implementation against termies
> > test server athttp://term.ie/oauth/example/client.php?sig_method=RSA-SHA1 > > and it works just fine, using the same private key.... so I'm at a bit
> > of a loss... any chance the certificates changed lately?
Is there any reason why I'd have no problem getting the tokens, but
would have a problem accessing the protected resources? Is it possible
the certificate is verified only when I try to access the resources?
On Apr 25, 4:29 pm, Wei <weitu+oa...@google.com> wrote:
> We are happy to announce that the Google Contacts Data API now
> supports OAuth. This is our first step towards OAuth enabling all
> Google Data APIs. Please note that this is an alpha release and we may
> make changes to the protocol before the official release. I will be
> at the OAuth hackathon tomorrow to get feedback and help consumers
> integrate.
> Caveats:
> - We currently only support RSA-SHA1 mode.
> - The consumer key is the domain hostname you registered. Currently
> there are no consumer_secrets.
> - The scope parameter specifies the URL identifying the service to be
> accessed. Seehttp://code.google.com/apis/contacts/developers_guide_protocol.html > for details about the Google Contacts Data API.
> We are happy to announce that the Google Contacts Data API now
> supports OAuth. This is our first step towards OAuth enabling all
> Google Data APIs. Please note that this is an alpha release and we may
> make changes to the protocol before the official release. I will be
> at the OAuth hackathon tomorrow to get feedback and help consumers
> integrate.
> Caveats:
> - We currently only support RSA-SHA1 mode.
> - The consumer key is the domain hostname you registered. Currently
> there are no consumer_secrets.
> - The scope parameter specifies the URL identifying the service to be
> accessed. Seehttp://code.google.com/apis/contacts/developers_guide_protocol.html > for details about the Google Contacts Data API.
> I'm running into some issues with the optional callback URL for
> OAuthentication between web applications.
> How and where can I set the callback url?
> I'm looking for the `next=` type of parameter that AuthSub would
> allow.
> cheers, Simon
> On Apr 25, 11:29 pm, Wei <weitu+oa...@google.com> wrote:
> > Hi folks,
> > We are happy to announce that the Google Contacts Data API now
> > supports OAuth. This is our first step towards OAuth enabling all
> > Google Data APIs. Please note that this is an alpha release and we may
> > make changes to the protocol before the official release. I will be
> > at the OAuth hackathon tomorrow to get feedback and help consumers
> > integrate.
> > Caveats:
> > - We currently only support RSA-SHA1 mode.
> > - The consumer key is the domain hostname you registered. Currently
> > there are no consumer_secrets.
> > - The scope parameter specifies the URL identifying the service to be
> > accessed. Seehttp://code.google.com/apis/contacts/developers_guide_protocol.html > > for details about the Google Contacts Data API.
> Is there any reason why I'd have no problem getting the tokens, but
> would have a problem accessing the protected resources? Is it possible
> the certificate is verified only when I try to access the resources?
> On Apr 25, 4:29 pm, Wei <weitu+oa...@google.com> wrote:
> > Hi folks,
> > We are happy to announce that the Google Contacts Data API now
> > supports OAuth. This is our first step towards OAuth enabling all
> > Google Data APIs. Please note that this is an alpha release and we may
> > make changes to the protocol before the official release. I will be
> > at the OAuth hackathon tomorrow to get feedback and help consumers
> > integrate.
> > Caveats:
> > - We currently only support RSA-SHA1 mode.
> > - The consumer key is the domain hostname you registered. Currently
> > there are no consumer_secrets.
> > - The scope parameter specifies the URL identifying the service to be
> > accessed. Seehttp://code.google.com/apis/contacts/developers_guide_protocol.html > > for details about the Google Contacts Data API.
> > Is there any reason why I'd have no problem getting the tokens, but
> > would have a problem accessing the protected resources?
I was experimenting with the Ruby OAuth implementation, and
(after some twiddling with the source) managed to get data
out of the contacts API.
I ended up:
- Switching the scope url to https rather than plain http
(otherwise I got a 401 saying there was an unknown
authorization header)
- Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
to use https rather then http (otherwise I got an authsub
has wrong scope error, which seemed fair enough given that I'd
asked for https in the scope)
- Encode the scope URL (as mentioned above)
Some of those may have been issues with the Ruby OAuth
library (or my hacking of it), but I thought I'd offer it
for the benefit of anyone else trying something similar.
> I was experimenting with the Ruby OAuth implementation, and
> (after some twiddling with the source) managed to get data
> out of the contacts API.
> I ended up:
> - Switching the scope url to https rather than plain http
> (otherwise I got a 401 saying there was an unknown
> authorization header)
> - Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
> to use https rather then http (otherwise I got an authsub
> has wrong scope error, which seemed fair enough given that I'd
> asked for https in the scope)
> - Encode the scope URL (as mentioned above)
> Some of those may have been issues with the Ruby OAuth
> library (or my hacking of it), but I thought I'd offer it
> for the benefit of anyone else trying something similar.
I'm having a similar problem with 401 responses with code that was working a week ago ... I can request a token, exchange it for an access token etc. but when making requests using the access token I now receive a 401 response.. I've tried some of the tips below i.e. switching the schemes to https instead of http for the scope etc. But it doesn't seem to make a difference, what's wrong with the request I'm making to the protected resource?
Here are the requests:
GET /accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fm8%2Ffee ds&oauth_nonce=8a3542c9-e43c-4cdf-ab82-f9e9424fda77&oauth_consumer_key=weit u .googlepages.com&oauth_signature_method=RSA-SHA1&oauth_timestamp=1213834722 & oauth_version=1.0&oauth_token=&oauth_signature=f8lmelPabpvb24GXrsEw9jOZsRsl 7 VQUY4Mv%2B%2FPF1oMYg0Y%2BxzcvpCeyjFayfZXM4FYulKoSmswdcHNjJh8eUIKhSsCLpvlo8% 2 FAq%2F%2FODdTw9tG%2FYALKeN%2FK6ELMH91i9ZvlMpknD4VimO5dKDe4rNQUWwbnljftFuR1m % 2BhYIA8Y%3D HTTP/1.1
GET /accounts/accounts/OAuthAuthorizeToken?scope=https://www.google.com/m8/feeds &oauth_token=CMiJx-LdFxDk9-6r-_____8B HTTP/1.1
* grant access *
GET /accounts/OAuthGetAccessToken?scope=https%3A%2F%2Fwww.google.com%2Fm8%2Ffeed s&oauth_token=CMiJx-LdFxDk9-6r-_____8B&oauth_nonce=49d793bd-9f3c-4b13-89db- 6 a693ab3d5aa&oauth_consumer_key=weitu.googlepages.com&oauth_signature_method = RSA-SHA1&oauth_timestamp=1213834735&oauth_version=1.0&oauth_signature=lldAl a asOsFeddN4%2BpWb3JUr%2B48v0pZTj0nrjyQw1%2FMeUm5mzVzFwM%2BnUfqpmv%2F8h8uMDkG O %2FSSuoGY%2BzolH1evslZZXDin26ZoSkWxYCtgyPvHesPoFSj%2FNbqGEQkMI4AwrWdnVxGW32 L aoSQgfcieD9Psj7TTzIftpes6Jkyc%3D HTTP/1.1
-> oauth_token=1%2FAcsGwK8z4zYQzrm7XX6-KmATiaQZnWPB51nTvo8n9Sw&oauth_token_sec r et=
GET /m8/feeds/contacts/default/base?scope=https%3A%2F%2Fwww.google.com%2Fm8%2Ffe eds&oauth_token=1%2FAcsGwK8z4zYQzrm7XX6-KmATiaQZnWPB51nTvo8n9Sw&oauth_nonce = 40e7f1bf-bb4c-49b1-8f1d-d27693fa6bd7&oauth_consumer_key=weitu.googlepages.c o m&oauth_signature_method=RSA-SHA1&oauth_timestamp=1213834736&oauth_version= 1 .0&oauth_signature=ihwMkduk9CFqqm9rxfn1aXx4eK9HiLhz1U9ULRN%2Butpd2MnUgD%2BU w 2WVaph2tEai7LM8rtlxOgaJmNBegDhgFwOR%2Fvpxfrk4JpLTg1kno21Y4Igo2AIHmgU4MvD39Y 9 zd4WB4uoaxPLVlQWCr3WIS2wv9GjqLPhnS%2BzKttD1fqg%3D HTTP/1.1
> > Is there any reason why I'd have no problem getting the tokens, but > > would have a problem accessing the protected resources?
I was experimenting with the Ruby OAuth implementation, and (after some twiddling with the source) managed to get data out of the contacts API.
I ended up:
- Switching the scope url to https rather than plain http (otherwise I got a 401 saying there was an unknown authorization header)
- Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full) to use https rather then http (otherwise I got an authsub has wrong scope error, which seemed fair enough given that I'd asked for https in the scope)
- Encode the scope URL (as mentioned above)
Some of those may have been issues with the Ruby OAuth library (or my hacking of it), but I thought I'd offer it for the benefit of anyone else trying something similar.
> I'm having a similar problem with 401 responses with code that was working a
> week ago ... I can request a token, exchange it for an access token etc. but
> when making requests using the access token I now receive a 401 response..
> I've tried some of the tips below i.e. switching the schemes to https
> instead of http for the scope etc. But it doesn't seem to make a
> difference, what's wrong with the request I'm making to the protected
> resource?
> I'm sure it's something simple - I just can't spot it.
> Cheers,
> - Alex
> -----Original Message-----
> From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of
> ckstj...@gmail.com
> Sent: Tuesday, 3 June 2008 6:26 a.m.
> To: OAuth
> Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
> On May 26, 6:50 pm, Wei <weitu+oa...@google.com> wrote:
> > Ben and I resolved this offline.
> > On May 21, 12:35 am, blweiner <blwei...@gmail.com> wrote:
> > > I had no problem getting a request token and an access token, but when
> > > I went to requesthttp://www.google.com/m8/feeds/contacts/default/base > > > with the access token, I received a 401 response.
> > > Is there any reason why I'd have no problem getting the tokens, but
> > > would have a problem accessing the protected resources?
> I was experimenting with the Ruby OAuth implementation, and
> (after some twiddling with the source) managed to get data
> out of the contacts API.
> I ended up:
> - Switching the scope url to https rather than plain http
> (otherwise I got a 401 saying there was an unknown
> authorization header)
> - Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
> to use https rather then http (otherwise I got an authsub
> has wrong scope error, which seemed fair enough given that I'd
> asked for https in the scope)
> - Encode the scope URL (as mentioned above)
> Some of those may have been issues with the Ruby OAuth
> library (or my hacking of it), but I thought I'd offer it
> for the benefit of anyone else trying something similar.
OAuth for Google Data APIs
Thursday, June 26, 2008 at 4:36 PM
Posted by Wei Tu, Google Accounts Team
The Google Data APIs have always been built on open standards, and
today we're proud to announce that all of the Google Data APIs support
OAuth - an open standard for authentication.
You'll now be able to use standard OAuth libraries to write code that
authenticates users to any of the Google Data APIs, such as Google
Calendar Data API, Blogger Data API, Picasa Web Albums Data API, or
Google Contacts Data API. This should reduce the amount of duplicate
code that you need to write, and make it easier for you to write
applications and tools that work with a variety of services from
multiple providers.
See the documentation for the full details on how to use OAuth with
the Google Data APIs.
* OAuth also currently works for YouTube accounts that are linked to a
Google Account when using the YouTube Data API.
Wei
On Jun 18, 5:54 pm, Wei <weitu+oa...@google.com> wrote:
> On Jun 18, 5:24 pm, "Alex Henderson" <bitterco...@gmail.com> wrote:
> > I'm having a similar problem with 401 responses with code that was working a
> > week ago ... I can request a token, exchange it for an access token etc. but
> > when making requests using the access token I now receive a 401 response..
> > I've tried some of the tips below i.e. switching the schemes to https
> > instead of http for the scope etc. But it doesn't seem to make a
> > difference, what's wrong with the request I'm making to the protected
> > resource?
> > I'm sure it's something simple - I just can't spot it.
> > Cheers,
> > - Alex
> > -----Original Message-----
> > From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of
> > ckstj...@gmail.com
> > Sent: Tuesday, 3 June 2008 6:26 a.m.
> > To: OAuth
> > Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
> > On May 26, 6:50 pm, Wei <weitu+oa...@google.com> wrote:
> > > Ben and I resolved this offline.
> > > On May 21, 12:35 am, blweiner <blwei...@gmail.com> wrote:
> > > > I had no problem getting a request token and an access token, but when
> > > > I went to requesthttp://www.google.com/m8/feeds/contacts/default/base > > > > with the access token, I received a 401 response.
> > > > Is there any reason why I'd have no problem getting the tokens, but
> > > > would have a problem accessing the protected resources?
> > I was experimenting with the Ruby OAuth implementation, and
> > (after some twiddling with the source) managed to get data
> > out of the contacts API.
> > I ended up:
> > - Switching the scope url to https rather than plain http
> > (otherwise I got a 401 saying there was an unknown
> > authorization header)
> > - Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
> > to use https rather then http (otherwise I got an authsub
> > has wrong scope error, which seemed fair enough given that I'd
> > asked for https in the scope)
> > - Encode the scope URL (as mentioned above)
> > Some of those may have been issues with the Ruby OAuth
> > library (or my hacking of it), but I thought I'd offer it
> > for the benefit of anyone else trying something similar.
Google's OAuth implementation is not as friendly to "standard OAuth libraries" as it could be. It defines a proprietary 'hd' (hosted domain) query parameter in the authorization URL. I think it would be better if the 'hd' parameter was included when getting a request token instead.
Accepting 'hd' in the authorization URL means this URL cannot be a pre-configured static input to an OAuth library. I assume it cannot be listed in an OAuth XRDS discovery document either (at a minimum it would have to be specified as a URI template, not a URL).
OAuth Core 1.0 §4.2 "Service Providers" implies an SP may require additional request parameters -- but only "to obtain a Token". I read this to allow proprietary parameters in requests for an unauthorized request token, but not in an authorization URL. It is reasonable to require them in the request token URL as this is the starting point -- it should identify what access is wanted (eg read access to a calendar for a mycollege.edu user), which will always be service-specific.
From that point on, however, an OAuth library should be able to drive the protocol without SP-specific knowledge.
If Google moved the 'hd' parameter from the Authorization URL to the Request Token URL it could encode the 'hd' value into the request token so it is still passed to the Google Authorization endpoint -- it just doesn't require Google-specific logic within OAuth libraries to do so.
----------
From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Wei
Sent: Friday, 27 June 2008 10:26 AM
To: OAuth
Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
Just want to let you know that we officially support OAuth for all
Google Data APIs.
Very cool. I gave it a go but the responses to the Request URL come
back with integers preceding and after the actual oauth_token and
oauth_token_secret string. I have no idea if these are something on
Google's side or mine - only happens on Google requests though.
Once I can strip those however, it appears to be rolling full
ahead ;).
Paddy
On Jun 27, 1:26 am, Wei <weitu+oa...@google.com> wrote:
> OAuth for Google Data APIs
> Thursday, June 26, 2008 at 4:36 PM
> Posted by Wei Tu, Google Accounts Team
> The Google Data APIs have always been built on open standards, and
> today we're proud to announce that all of the Google Data APIs support
> OAuth - an open standard for authentication.
> You'll now be able to use standard OAuth libraries to write code that
> authenticates users to any of the Google Data APIs, such as Google
> Calendar Data API, Blogger Data API, Picasa Web Albums Data API, or
> Google Contacts Data API. This should reduce the amount of duplicate
> code that you need to write, and make it easier for you to write
> applications and tools that work with a variety of services from
> multiple providers.
> See the documentation for the full details on how to use OAuth with
> the Google Data APIs.
> * OAuth also currently works for YouTube accounts that are linked to a
> Google Account when using the YouTube Data API.
> Wei
> On Jun 18, 5:54 pm, Wei <weitu+oa...@google.com> wrote:
> > I will help Alex debug offline.
> > On Jun 18, 5:24 pm, "Alex Henderson" <bitterco...@gmail.com> wrote:
> > > I'm having a similar problem with 401 responses with code that was working a
> > > week ago ... I can request a token, exchange it for an access token etc. but
> > > when making requests using the access token I now receive a 401 response..
> > > I've tried some of the tips below i.e. switching the schemes to https
> > > instead of http for the scope etc. But it doesn't seem to make a
> > > difference, what's wrong with the request I'm making to the protected
> > > resource?
> > > I'm sure it's something simple - I just can't spot it.
> > > Cheers,
> > > - Alex
> > > -----Original Message-----
> > > From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of
> > > ckstj...@gmail.com
> > > Sent: Tuesday, 3 June 2008 6:26 a.m.
> > > To: OAuth
> > > Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
> > > On May 26, 6:50 pm, Wei <weitu+oa...@google.com> wrote:
> > > > Ben and I resolved this offline.
> > > > On May 21, 12:35 am, blweiner <blwei...@gmail.com> wrote:
> > > > > I had no problem getting a request token and an access token, but when
> > > > > I went to requesthttp://www.google.com/m8/feeds/contacts/default/base > > > > > with the access token, I received a 401 response.
> > > > > Is there any reason why I'd have no problem getting the tokens, but
> > > > > would have a problem accessing the protected resources?
> > > I was experimenting with the Ruby OAuth implementation, and
> > > (after some twiddling with the source) managed to get data
> > > out of the contacts API.
> > > I ended up:
> > > - Switching the scope url to https rather than plain http
> > > (otherwise I got a 401 saying there was an unknown
> > > authorization header)
> > > - Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
> > > to use https rather then http (otherwise I got an authsub
> > > has wrong scope error, which seemed fair enough given that I'd
> > > asked for https in the scope)
> > > - Encode the scope URL (as mentioned above)
> > > Some of those may have been issues with the Ruby OAuth
> > > library (or my hacking of it), but I thought I'd offer it
> > > for the benefit of anyone else trying something similar.
> Very cool. I gave it a go but the responses to the Request URL come
> back with integers preceding and after the actual oauth_token and
> oauth_token_secret string. I have no idea if these are something on
> Google's side or mine - only happens on Google requests though.
> Once I can strip those however, it appears to be rolling full
> ahead ;).
> Paddy
> On Jun 27, 1:26 am, Wei <weitu+oa...@google.com> wrote:
> > Just want to let you know that we officially support OAuth for all
> > Google Data APIs.
> > OAuth for Google Data APIs
> > Thursday, June 26, 2008 at 4:36 PM
> > Posted by Wei Tu, Google Accounts Team
> > The Google Data APIs have always been built on open standards, and
> > today we're proud to announce that all of the Google Data APIs support
> > OAuth - an open standard for authentication.
> > You'll now be able to use standard OAuth libraries to write code that
> > authenticates users to any of the Google Data APIs, such as Google
> > Calendar Data API, Blogger Data API, Picasa Web Albums Data API, or
> > Google Contacts Data API. This should reduce the amount of duplicate
> > code that you need to write, and make it easier for you to write
> > applications and tools that work with a variety of services from
> > multiple providers.
> > See the documentation for the full details on how to use OAuth with
> > the Google Data APIs.
> > * OAuth also currently works for YouTube accounts that are linked to a
> > Google Account when using the YouTube Data API.
> > Wei
> > On Jun 18, 5:54 pm, Wei <weitu+oa...@google.com> wrote:
> > > I will help Alex debug offline.
> > > On Jun 18, 5:24 pm, "Alex Henderson" <bitterco...@gmail.com> wrote:
> > > > I'm having a similar problem with 401 responses with code that was working a
> > > > week ago ... I can request a token, exchange it for an access token etc. but
> > > > when making requests using the access token I now receive a 401 response..
> > > > I've tried some of the tips below i.e. switching the schemes to https
> > > > instead of http for the scope etc. But it doesn't seem to make a
> > > > difference, what's wrong with the request I'm making to the protected
> > > > resource?
> > > > I'm sure it's something simple - I just can't spot it.
> > > > Cheers,
> > > > - Alex
> > > > -----Original Message-----
> > > > From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of
> > > > ckstj...@gmail.com
> > > > Sent: Tuesday, 3 June 2008 6:26 a.m.
> > > > To: OAuth
> > > > Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
> > > > On May 26, 6:50 pm, Wei <weitu+oa...@google.com> wrote:
> > > > > Ben and I resolved this offline.
> > > > > On May 21, 12:35 am, blweiner <blwei...@gmail.com> wrote:
> > > > > > I had no problem getting a request token and an access token, but when
> > > > > > I went to requesthttp://www.google.com/m8/feeds/contacts/default/base > > > > > > with the access token, I received a 401 response.
> > > > > > Is there any reason why I'd have no problem getting the tokens, but
> > > > > > would have a problem accessing the protected resources?
> > > > I was experimenting with the Ruby OAuth implementation, and
> > > > (after some twiddling with the source) managed to get data
> > > > out of the contacts API.
> > > > I ended up:
> > > > - Switching the scope url to https rather than plain http
> > > > (otherwise I got a 401 saying there was an unknown
> > > > authorization header)
> > > > - Switch the data URL (m8/feeds/contacts/cstjohn%40gmail.com/full)
> > > > to use https rather then http (otherwise I got an authsub
> > > > has wrong scope error, which seemed fair enough given that I'd
> > > > asked for https in the scope)
> > > > Some of those may have been issues with the Ruby OAuth
> > > > library (or my hacking of it), but I thought I'd offer it
> > > > for the benefit of anyone else trying something similar.
FWIW, section 6.2.1 in the spec does allow any additional parameters
defined by the Service Provider for the authorization step.
That said, we definitely want to be as friendly to the oauth library
world as possible as it is our loss if we don't. To clarify, the "hd"
parameter is completely optional as it is just a parameter to optimize
the UI flow for certain third party developers that only cares about a
fragment of Google users (i.e. targeted to a specific domain that uses
Google Apps). I would say that this parameter resembles the language
pref parameter, which just makes more sense to be passed in during the
Authorization step than the request token step.
Also, I am curious why it is harder to implement libraries to have
dynamic Authorization URL than Request Token URL. From my reading, it
sounds like you accepted the fact that we would need dynamic request
token url so you'd like to keep all the dynamic parameters in that
step so that you can have a static one for the authorization step. Am
I understanding it correctly?
<James.H.Man...@team.telstra.com> wrote:
> Hi Wei,
> Google's OAuth implementation is not as friendly to "standard OAuth libraries" as it could be. It defines a proprietary 'hd' (hosted domain) query parameter in the authorization URL. I think it would be better if the 'hd' parameter was included when getting a request token instead.
> Accepting 'hd' in the authorization URL means this URL cannot be a pre-configured static input to an OAuth library. I assume it cannot be listed in an OAuth XRDS discovery document either (at a minimum it would have to be specified as a URI template, not a URL).
> OAuth Core 1.0 §4.2 "Service Providers" implies an SP may require additional request parameters -- but only "to obtain a Token". I read this to allow proprietary parameters in requests for an unauthorized request token, but not in an authorization URL. It is reasonable to require them in the request token URL as this is the starting point -- it should identify what access is wanted (eg read access to a calendar for a mycollege.edu user), which will always be service-specific.
> From that point on, however, an OAuth library should be able to drive the protocol without SP-specific knowledge.
> If Google moved the 'hd' parameter from the Authorization URL to the Request Token URL it could encode the 'hd' value into the request token so it is still passed to the Google Authorization endpoint -- it just doesn't require Google-specific logic within OAuth libraries to do so.
> ----------
> From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Wei
> Sent: Friday, 27 June 2008 10:26 AM
> To: OAuth
> Subject: [oauth] Re: OAuth support for Google Accounts and Contacts API
> Just want to let you know that we officially support OAuth for all
> Google Data APIs.
> why it is harder to implement libraries to have dynamic Authorization URL than Request Token URL
It is no harder with OAuth Core 1.0 with no extensions. It is harder once we start the eliminating the pre-configuration required for OAuth to work.
I want the Authorization URI and Access URI to be provided in the “WWW-Authentication: OAuth” header [other discovery options can give a vaguely similar result]. An OAuth library can then use these without needing to be specifically pre-configured to use this SP – as long as they don’t involve SP-specific parameters such as Google’s ‘hd’.
When the Authorization URI is provided dynamically in an SP response, the SP can insert the request token into this URI.
You still need a URI to start the process like the “Request Token URI”, but that name is not quite appropriate.
So a dynamic Authorization URI is not harder than a dynamic Request Token URI,
but it is harder than a dynamic “initial URI”.
I believe the Request Token URI will morph into an “initial URI” as we make progress eliminating the manual SP-specific configuration steps in OAuth.
Perhaps an easier way to explain it is with a concrete example that I think OAuth should support:
An app is developed that adds pretty frames to photos. It understands Atom feeds for representing collections of photos, as well as industry conventions for marking up thumbnails, captions and links to JPEGs. It understands OAuth. It has no SP-specific code. Optionally, it can be configured with credentials (a consumer key & secret, or consumer key & private RSA key).
Within the app:
It is given a URI by a user;
The app GETs the URI;
The 401 response includes WWW-Auth.: OAuth authz=http… access=http…;
The app redirects the user to the authz URI it just got;
The app detects when it has been authorized;
The app gets an access token using the access URI;
The app reties the original URI the user gave it, this time with an OAuth signature;
The response has the photos for the app to process.
Picasa already provides URLs for photos grouped by user, album, query or contacts.
Picasa already uses standard Atom feeds and what I assume is industry-standard markup for photos.
The main barrier to this generic app (that has no SP-specific code) is the OAuth pre-configuration requirements. It would be a shame if we eliminated those, but Google-specific *code* is still required to make use of the useful ‘hd’ feature.
The app might add buttons for popular photo hosts – much like OpenID Relying Parties add buttons for popular OpenID Providers. The OpenID buttons are cosmetic changes. They are a trivial shortcut to manually entering, say, “yahoo.com”. The OpenID library is unaffected. The photo frame app could add a [mycollege.edu] button as a trivial cosmetic change if the ‘hd’ parameter was part of the “initial URI”, but not if it needs to be added to the Authorization URI.
I hope this makes some sense.
James Manger
_____________________________________________
From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Wei
Sent: Saturday, 28 June 2008 5:05 AM
To: OAuth
Hi James,
Thanks for your feedback!
FWIW, section 6.2.1 in the spec does allow any additional parameters defined by the Service Provider for the authorization step.
That said, we definitely want to be as friendly to the oauth library world as possible as it is our loss if we don't. To clarify, the "hd"
parameter is completely optional as it is just a parameter to optimize the UI flow for certain third party developers that only cares about a fragment of Google users (i.e. targeted to a specific domain that uses Google Apps). I would say that this parameter resembles the language pref parameter, which just makes more sense to be passed in during the Authorization step than the request token step.
Also, I am curious why it is harder to implement libraries to have dynamic Authorization URL than Request Token URL. From my reading, it sounds like you accepted the fact that we would need dynamic request token url so you'd like to keep all the dynamic parameters in that step so that you can have a static one for the authorization step. Am I understanding it correctly?
Thanks again!
Wei
_____________________________________________
From: oauth@googlegroups.com<mailto:oauth@googlegroups.com> [mailto:oauth@googlegroups.com]<mailto:[mailto:oauth@googlegroups.com]> On Behalf Of Manger, James H
Sent: Friday, 27 June 2008 11:18 AM
Subject<mailto:oa...@googlegroups.comSubject>: [oauth] Google OAuth support: hd authz parameter
Hi Wei,
Google's OAuth implementation is not as friendly to "standard OAuth libraries" as it could be. It defines a proprietary 'hd' (hosted domain) query parameter in the authorization URL. I think it would be better if the 'hd' parameter was included when getting a request token instead.
Accepting 'hd' in the authorization URL means this URL cannot be a pre-configured static input to an OAuth library. I assume it cannot be listed in an OAuth XRDS discovery document either (at a minimum it would have to be specified as a URI template, not a URL).
OAuth Core 1.0 §4.2 "Service Providers" implies an SP may require additional request parameters -- but only "to obtain a Token". I read this to allow proprietary parameters in requests for an unauthorized request token, but not in an authorization URL. It is reasonable to require them in the request token URL as this is the starting point -- it should identify what access is wanted (eg read access to a calendar for a mycollege.edu user), which will always be service-specific.
From that point on, however, an OAuth library should be able to drive the protocol without SP-specific knowledge.
If Google moved the 'hd' parameter from the Authorization URL to the Request Token URL it could encode the 'hd' value into the request token so it is still passed to the Google Authorization endpoint -- it just doesn't require Google-specific logic within OAuth libraries to do so.
<James.H.Man...@team.telstra.com> wrote: > It is no harder with OAuth Core 1.0 with no extensions. It is harder once > we start the eliminating the pre-configuration required for OAuth to work. > I want the Authorization URI and Access URI to be provided in the > "WWW-Authentication: OAuth" header [other discovery options can give a > vaguely similar result]. An OAuth library can then use these without needing > to be specifically pre-configured to use this SP – as long as they don't > involve SP-specific parameters such as Google's 'hd'. > When the Authorization URI is provided dynamically in an SP response, the SP > can insert the request token into this URI.
What about the oauth_callback parameter?
In many respects the request token URL and the authorization URL are identical. There's very little reason to prefer one over the other. I happen to like adding parameters to the authorization URL, since it encourages stateless request token implementations.
oauth_callback is defined in the OAuth spec so an OAuth library will know how to use it. It is likely to be a fixed value for the life of a library instance (running app), or it will have a varying component that is internal to the library.
'hd' is specific to Google. An OAuth library will not know anything about it. An 'hd' value will need to be passed to the OAuth library. A different 'hd' value may be needed for each request.
I expect an app that can use OAuth to:
1. Initialize an OAuth library;
2. [Repeatedly] Send an HTTP request on behalf of a user.
An API for the 2nd step will have a URI as an input parameter.
Ideally that would be sufficient.
doStuff(URL destination)
To support 'hd' in the Authorization URI, however,
the API for the 2nd step will need the URI and 'hd' as input parameters.
doStuff(URL destination, String hd) // Google-specific code
If the API is not Google-specific the 'hd' input will need to be in a more complicated structure.
doStuff(URL destination, Map<String,String> authzParams)
That is only a little more onerous -- as long as the app is explicitly calling the OAuth code directly.
An alternative (and I suspect better) architecture is for an app to call the standard HTTP library for the language it is written in. OAuth would be implemented as a hook into the HTTP library. Java, for instance, has URLStreamHandlers, ContentHandlers, Authenticators, and CookieHandlers that plug-in "underneath" the URLConnection class. Most of the code in an app just uses the common URLConnection interface. Only initialization code needs to understand the details of any specialized authentication or other handling.
Passing 'hd' during initialization is ok.
Passing one URI for each request is expected.
Passing 'hd' separately from the URI for each request hinders the "nicest" API designs.
STATELESS REQUEST TOKEN
I am not sure what value a request token has if it doesn't encode any state?
-----Original Message-----
From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Brian Eaton
Sent: Tuesday, 1 July 2008 2:47 AM
To: oauth@googlegroups.com
Subject: [oauth] Re: Google OAuth support: hd authz parameter
On Sun, Jun 29, 2008 at 8:08 PM, Manger, James H
<James.H.Man...@team.telstra.com> wrote:
> It is no harder with OAuth Core 1.0 with no extensions. It is harder once
> we start the eliminating the pre-configuration required for OAuth to work.
> I want the Authorization URI and Access URI to be provided in the
> "WWW-Authentication: OAuth" header [other discovery options can give a
> vaguely similar result]. An OAuth library can then use these without needing
> to be specifically pre-configured to use this SP – as long as they don't
> involve SP-specific parameters such as Google's 'hd'.
> When the Authorization URI is provided dynamically in an SP response, the SP
> can insert the request token into this URI.
What about the oauth_callback parameter?
In many respects the request token URL and the authorization URL are
identical. There's very little reason to prefer one over the other.
I happen to like adding parameters to the authorization URL, since it
encourages stateless request token implementations.
<James.H.Man...@team.telstra.com> wrote: > I expect an app that can use OAuth to: > 1. Initialize an OAuth library; > 2. [Repeatedly] Send an HTTP request on behalf of a user.
At some point it will need to redirect the user to get their permission. Either a) you build the redirection into the library or b) you expose the authorization URL to clients of the library, since they are the ones who have the browser focus
In a reusable library, you're only going to see the second option.
Re: the oauth_callback. It is extremely common in web applications to encode a certain amount of state in your callback URL, e.g. the user's language, what page of your app they were on, etc... All of that info is dynamic. There will be a few people out there with completely static callback URLs, but they will be the exception, not the rule.
Re: stateless request tokens. You can implement a request token and token secret in two ways. a) Write every request token to a persistent data store. b) Encrypt the consumer identity (and whatever other information you need) and use that as the request token
The second option scales better. It is sometimes referred to as "stateless", because it requires no frequently changing server-side state to implement, just an encryption key.
I was never suggesting writing an 'hd' value to a persistent data store.
I was suggesting receiving an 'hd' value in a Request Token URL then making it part of the token that is returned (just like you probably make the consumer identity part of the token). The app then passes the token (with the embedded 'hd' value) to the Authorization URL.
-> GET /oauth/request?hd=abc.edu
<- oauth_token=abc.edu,consumer.net,63gShg3jShg
P.S. Please put a MAC on the token, not just encryption.
-----
Re: stateless request tokens. You can implement a request token and
token secret in two ways.
a) Write every request token to a persistent data store.
b) Encrypt the consumer identity (and whatever other information you
need) and use that as the request token
The second option scales better. It is sometimes referred to as
"stateless", because it requires no frequently changing server-side
state to implement, just an encryption key.
I agree that a reusable OAuth library will return to the client with the Authorization URI, and that oauth_callback will often contain dynamic state.
This still doesn’t make an SP-specific ‘hd’ parameter in the Authorization URI the best choice.
Code building a dynamic app-specific callback URI doesn’t seem like an obvious place to also handle SP-specific parameters.
The ‘hd’ value will need to be passed to the code that gets the Authorization URI back, which is not necessarily the code that started the transaction (though I guess they both need to be coupled to the user’s browser request – [thanks for highlighting that]).
Taking a high-level view, OAuth is still about a user asking an app to access a URI.
A user asking an app to “access a URI and to use an extra ‘hd’ parameter during the process” is more complex.
Encoding ‘hd’ into the initial URI so the app does not need to know about it at all is simpler.
James Manger
_____________________________________________
From: oauth@googlegroups.com<mailto:oauth@googlegroups.com> [mailto:oauth@googlegroups.com]<mailto:[mailto:oauth@googlegroups.com]> On Behalf Of Brian Eaton
Sent: Tuesday, 1 July 2008 11:37 AM
To:
oauth@googlegroups.com
Subject<mailto:oa...@googlegroups.comSubject>: [oauth] Re: Google OAuth support: hd authz parameter
On Mon, Jun 30, 2008 at 6:11 PM, Manger, James H <James.H.Man...@team.telstra.com<mailto:James.H.Man...@team.telstra.com>> wrote:
> I expect an app that can use OAuth to:
> 1. Initialize an OAuth library;
> 2. [Repeatedly] Send an HTTP request on behalf of a user.
At some point it will need to redirect the user to get their permission. Either
a) you build the redirection into the library or
b) you expose the authorization URL to clients of the library, since they are the ones who have the browser focus
In a reusable library, you're only going to see the second option.
Re: the oauth_callback. It is extremely common in web applications to encode a certain amount of state in your callback URL, e.g. the user's language, what page of your app they were on, etc... All of that info is dynamic. There will be a few people out there with completely static callback URLs, but they will be the exception, not the rule.
Re: stateless request tokens. You can implement a request token and token secret in two ways.
a) Write every request token to a persistent data store.
b) Encrypt the consumer identity (and whatever other information you
need) and use that as the request token
The second option scales better. It is sometimes referred to as "stateless", because it requires no frequently changing server-side state to implement, just an encryption key.
_____________________________________________
From: oauth@googlegroups.com<mailto:oauth@googlegroups.com> [mailto:oauth@googlegroups.com]<mailto:[mailto:oauth@googlegroups.com]> On Behalf Of Manger, James H
Sent: Tuesday, 1 July 2008 11:50 AM
To:
oauth@googlegroups.com
<mailto:oa...@googlegroups.comSubject>
Just on the stateless part:
I was never suggesting writing an 'hd' value to a persistent data store.
I was suggesting receiving an 'hd' value in a Request Token URL then making it part of the token that is returned (just like you probably make the consumer identity part of the token). The app then passes the token (with the embedded 'hd' value) to the Authorization URL.
-> GET /oauth/request?hd=abc.edu
<- oauth_token=abc.edu,consumer.net,63gShg3jShg
