"2 legged" OAuth 2.0?

[Jeffrey McKay]

Does OAuth 2.0 have an equivalent to what is described in OAuth 1.0 as "2 legged" authentication?  The idea is for a Google Apps domain administrator to obtain authorization to access the data of one of his users, without needing to know the user's password.  Is that what a "service account" (server to server authentication) is for?

 

[Breno de Medeiros]

In short, yes.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "oauth2-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/oauth2-dev/-/pedpwTforeAJ.
> To post to this group, send email to oauth...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth2-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/oauth2-dev?hl=en.



--
--Breno

[Jeffrey McKay]

OK, I have created a OAuth 2.0 service account.  I get a ClientID and a private key.  Let's say the product name is "Bob's Test Project".  Now, as I understand it, the person who is administrator for the Google Apps domain that I want my application to access has to grant access.   I have set up a Google Apps account that I use for testing.  I go to the Dashboard, Advanced Tools, Manage API Client Access. There it asks me to put in the "Client Name" and a list of scopes that the application needs.  So what do I put in for Client Name?  The form is insisting on something like www.example.com.  If I put in "Bob's Test Project" I get an error message.  My application is being run from a desktop, it is not a web application (and in any event, the service account creation did not ask for a web address).

On Thursday, May 17, 2012 3:34:57 PM UTC-7, breno wrote:

On Thu, May 17, 2012 at 3:32 PM, Jeffrey McKay <jmcka...@gmail.com> wrote:
> Does OAuth 2.0 have an equivalent to what is described in OAuth 1.0 as "2
> legged" authentication?  The idea is for a Google Apps domain administrator
> to obtain authorization to access the data of one of his users, without
> needing to know the user's password.  Is that what a "service account"
> (server to server authentication) is for?

In short, yes.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "oauth2-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/oauth2-dev/-/pedpwTforeAJ.
> To post to this group, send email to oauth...@googlegroups.com.
> To unsubscribe from this group, send email to

> oauth2-dev+unsubscribe@googlegroups.com.

[David Primmer]

Hi Jeff, the protocols are similar, but the access control schemes are
not. Sound like you want an apps-domain-wide delegation system.

If you want to have all the users in an Apps domain delegate data
access to the application, then you need to use the OAuth1 Two-Legged
OAuth protocol. By contrast, OAuth2 Service accounts are used when you
want an app to access data at Google as itself, not impersonating a
set of users.

In the "Manage API Client Access" you'd put the ClientID in the field
for "Client Name" it's in the client creation screen in the api
console https://code.google.com/apis/console/ and looks something like
<number>.apps.googleusercontent.com. This is also the same string as
the "consumer_key" value in OAuth1.

You should make a new client (not a service acct) in the api console
https://code.google.com/apis/console/ for your project and choose the
"web application" client type. Doesn't matter what you choose for a
redirect URI as this is not used in 2LO. It will show something like
this when you've done that:

Client ID:
<number>.apps.googleusercontent.com
Email address:
<number>@developer.gserviceaccount.com
Client secret:
XXXXXXXXXXXXXXX

After you've created the client id, and granted access in the Apps
Dashboard, then you'd do something like this sample to form the 2LO
request to access the data for a user:

http://code.google.com/p/gdata-java-client/source/browse/trunk/java/sample/oauth/TwoLeggedOAuthExample.java
https://developers.google.com/gdata/docs/auth/oauth#2LeggedOAuth

If you don't know the user ahead of time, and don't really need a
domain-wide delegation decision to be made, then you should use
regular OAuth2 Web Server flow, where you prompt each user for
approval.

What I've shown you is how to use the API console to create an OAuth
client that can be used with OAuth1 or OAuth2 wire protocol. Hope this
helps.

davep

>> > oauth2-dev+...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/oauth2-dev?hl=en.
>>
>>
>>
>> --
>> --Breno
>

> --
> You received this message because you are subscribed to the Google Groups
> "oauth2-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/oauth2-dev/-/jl2gT-_m0bIJ.

>
> To post to this group, send email to oauth...@googlegroups.com.
> To unsubscribe from this group, send email to

> oauth2-dev+...@googlegroups.com.

[Jeffrey McKay]

Thanks, that is very helpful.  I am already using OAuth 2.0 successfully, in the case where my application allows Google to authenticate an individual user.  Just so I'm clear on this, if I want to allow a domain administrator to run my application, and access all users accounts without individual passwords, then my only option is 2 legged OAuth version 1.0?  I had seen that, but all documentation for version 1.0 now comes with a forbidding disclaimer about how it is now depreciated and will go away.  So it doesn't seem like a good idea to invest much time in that.  But I have at least 3 years, is that correct?  How will you replace that capability using OAuth 2.0?

[David Primmer]

Hi Jeffery,

Glad you got it working. I can't comment specifically on our upgrade
path but you can safely code you application to use the OAuth1 signing
mechanism today. I beleive there is an attempt in IEEE to make this a
standard signature method of OAuth2. One thing that may reassure you
is that the Google Apps Marketplace is built on this same technology
https://www.google.com/enterprise/marketplace/

davep

> --
> You received this message because you are subscribed to the Google Groups
> "oauth2-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/oauth2-dev/-/j0X6tQ4CqB0J.

[LT]

Hi Jeffrey,

Is Oauth1 mechanism still (as of today) the only way to go if we want to "all the users in an Apps domain delegate data
access to the application" with the ability to impersonate a user? It wasn't clear to me as I saw this which was posted later:

http://stackoverflow.com/questions/12431115/2lo-oauth-support

If it is still the case that we must stick with Oauth 1 for now (to be able to use apps domain based permission and impersonation) then how can those using google document list api (which has been deprecated) move onto using google drive sdk which seems to require using Oauth 2?

Regards,
LT

[Thomas Gerber]

Hello,

I think you can impersonate a user with OAuth2 service accounts:
http://javadoc.google-api-java-client.googlecode.com/hg/1.11.0-beta/com/google/api/client/googleapis/auth/oauth2/GoogleCredential.html

Extract:
===

You can also use the service account flow to impersonate a user in a domain that you own. This is very similar to the service account flow above, but you additionally call GoogleCredential.Builder.setServiceAccountUser(String). Sample usage:

  public static GoogleCredential createCredentialForServiceAccountImpersonateUser(
      HttpTransport transport,
      JsonFactory jsonFactory,
      String serviceAccountId,
      Iterable<String> serviceAccountScopes,
      File p12File,
      String serviceAccountUser) throws GeneralSecurityException, IOException {
    return new GoogleCredential.Builder().setTransport(transport)
        .setJsonFactory(jsonFactory)
        .setServiceAccountId(serviceAccountId)
        .setServiceAccountScopes(serviceAccountScopes)
        .setServiceAccountPrivateKeyFromP12File(p12File)
        .setServiceAccountUser(serviceAccountUser)
        .build();
  }
=== 

I manage to user this to scan the documents of all users of an App Domain with the Drive SDK.

[LT]

Thomas,

Thank you very much for the information. We weren't sure what the current state of things were with respect to domain 2LO/impersonation support was with OAuth 2.0. It is good to know that we can go to OAuth 2.0 (and use those APIs that require it) and continue to use domain 2LO/impersonation.

Regards,
LT

[Jeffrey McKay]

Can you provide any information about how service account impersonation works at the http level?  My application uses

direct http calls, not Java or any API, so I need specific information about how to formulate the GET/POST calls.

On Friday, September 21, 2012 11:39:10 AM UTC-7, Thomas Gerber wrote:

[Jinhui Du]

Hi Jeffrey

The service account impersonation use case is documented at https://developers.google.com/accounts/docs/OAuth2ServiceAccount "Additional Claims" section.

The java client service account implementation can be found here http://code.google.com/p/google-api-java-client/source/browse/google-api-client/src/main/java/com/google/api/client/googleapis/auth/oauth2/GoogleCredential.java

Since it involves lots of signature and protocol stuff. It's recommended to use the client libraries instead of writing your own to save the development/debugging time.

--
 
 

[Jerry Wang]

Hi Jeff,

I have the same question as yours.  We are currently using 2LO (Oauth 1) in our project, however, I am looking forward to employ the  OAuth 2.0 impersonation.  It seems that 2LO OAuth 2.0 can work on some APIs, but I need to make sure that it can work on all Google APIs.   kind of confused on different information in different time :(