13

We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.

The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)

(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)

I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...

So, what would be the best approach to get a valid authentication without any interaction from the end user ?

Kara
  • 5,650
  • 15
  • 48
  • 55
FMaz008
  • 10,389
  • 16
  • 61
  • 90
  • 2
    To the casual reader. Before you start getting involved with this. Consider the alternate and less painful implementation of hardcoding your gmail username and password into the application and porting Chrome to PHP to emulate a user login. Now rewriting a NSAPI-compliant plugin architecture and virtual machine wont be fun, but at least it's better than OAuth2, which if you didn't read the author recommends not using http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ – William Entriken Oct 01 '13 at 14:58
  • https://web.archive.org/web/20170219104604/https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ – helvete Feb 09 '21 at 11:05

3 Answers3

17

What you describe is not how 3-legged OAuth was designed to be used.

3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.

What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.

Here's some further info on using 2-legged OAuth in Google Apps: http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html

And this is a good description of 3- vs 2- legged OAuth: http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/

Chris Sears
  • 5,533
  • 4
  • 28
  • 33
  • 1
    Both links are oauth1, and is not what it's called in OAuth2. In OAuth2 it is termed "Client Credentials": http://tools.ietf.org/html/rfc6749#section-1.3.4 – Andriy Drozdyuk Jan 04 '13 at 01:58
4

You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.

Here is a complete example implementation of setting up a service account, logging and and then using it.

Updated 2018-12-12: https://gist.github.com/fulldecent/6728257

William Entriken
  • 30,701
  • 17
  • 128
  • 168
  • Yes, SO reviewers. This is the third time I have posted this link in an answer. And yes, it is a valid answer. Other questions are http://stackoverflow.com/questions/9932090/google-analytics-api-v3-authorization-to-allow-access-to-my-data/19121069#19121069 and http://stackoverflow.com/questions/13111396/access-google-calendar-events-from-with-service-account-error-access-den – William Entriken Oct 01 '13 at 16:17
  • The link uses a deprecated function `$client->getAuth()` and doesn't work anymore – 99 Problems - Syntax ain't one Dec 07 '18 at 14:40
  • Thanks for the heads up. Have updated the auth workflow in the example. But did not test the rest of the file since original. – William Entriken Dec 10 '18 at 16:19
  • Nice one, can't remove the vote until the answer is updated – 99 Problems - Syntax ain't one Dec 14 '18 at 09:58
1

Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.

The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.

Mark S.
  • 3,659
  • 3
  • 20
  • 20
  • 1
    That sound like what I need, but Isn't the goal of OAuth is to redirect to process the authentication ? How can I "hardcode" the credential in order to avoid the enduser to notice that an authentication has been done ? – FMaz008 Sep 10 '11 at 16:48
  • You do the authentication prior to anyone else using the system. Then you store the token for use by everyone. Look at it like all users are sharing the same token instead of each having their own token. – Mark S. Sep 10 '11 at 23:28
  • Hum, ok, but that still doesn't help me. I've tried to implement the protocol, and now all users are redirected to a page where it's written: *** Website is requesting permission to: Manage your documents View and manage your documents in Google Docs Upload new documents (More info). *** I don't want my user to see that ... – FMaz008 Sep 13 '11 at 14:16
  • I mean: how can I authenticate "prior" to the user action ? – FMaz008 Sep 13 '11 at 14:35
  • I don't think I'm explaining it well. First you authenticate with OAuth and store the access tokens that are returned. Then whenever anyone uses the application, they use the access tokens that were returned when you authenticated. Since the other users are using existing, valid access tokens, then they don't need to be redirected to the authorization page. In other words, don't give your users the option of the redirection, just have them access the resource with the existing access token. – Mark S. Sep 13 '11 at 15:03
  • 3
    But token will expire someday. Your solution seems to mean that I'll have to do the "authorisation process with the redirection" by myself each X days/hours and then store the token somewhere. It's pretty painful. The authentication process must be fully automated in a way or another. – FMaz008 Sep 13 '11 at 15:22
  • I'm reading about 2 legged OAuth, and it seem really painful to implement: http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth – FMaz008 Sep 13 '11 at 15:24
  • The access token expires and the application uses the refresh token to get a new access token. Nothing involves the end user. – Mark S. Sep 13 '11 at 16:33
  • Do you have a concrete code example that demonstrate how I can obtain that token without any interaction with the end user ? I get your idea, but I can't any working example ... – FMaz008 Sep 15 '11 at 13:43
  • What I'm suggesting is that you go in as a user and do the authorization. Your application gets the token and stores it. Then you deploy the application to everyone else. Anyone else who comes into the application after you will just reuse the token that was obtained when you authenticated. – Mark S. Sep 15 '11 at 14:33
  • Hum ok... So I'll have to wait for a question about my other question, and then come back to this one. – FMaz008 Sep 15 '11 at 14:42
  • I don't feel like it's the best solution, but it works like a charm for now. So here's you green checkmark :) Thanks for the help ! – FMaz008 Sep 23 '11 at 12:57
  • @FMaz008 What works like a charm? Perhaps you could explain your solution as a valid answer to your own question...? – Andriy Drozdyuk Jan 04 '13 at 01:59