I'm a little bit lost... Too many google documentation, I can't find my way.
We have an app on the google apps marketplace. This app use google's APIs to retrieve drive content, calendar information, ... for all users of our client domain.
Currently we are using 2-legged OAuth 1.0A.
According to the google documentation, OAuth 1.0 is deprecated.
But I cannot find any documentation for using 2-legged OAuth 2.0.
Did I miss something ?
How are we supposed to replace the existing ? 2-legged OAuth 2.0, or anything else ?
Do we have to do any modification on our google marketplace vendor profile ?
Thanks,
Jonathan
The 2-legged form of OAuth2 is described in "OAuth2 for server-to-server applications": https://developers.google.com/accounts/docs/OAuth2ServiceAccount ; that document explains how the 2-legged OAuth2 flows work, but not how an administrator grants the application the privileges it needs to access the data: This is done via the Admin console settings, where the administrator authorizes the app to impersonate users in the domain. The details are described in https://developers.google.com/drive/web/delegation#delegate_domain-wide_authority_to_your_service_account
I think that the correct process is described here :
https://developers.google.com/apps-marketplace/v1migratev2
Related
I want users to my website to use Google Accounts to authenticate / sign in to my website. The primary use case being users will edit and generate content and we want to log ownership in a secure way. We are not interested in obtaining users Google data, we just want a means to authenticate users.
After googling, I came across some documentation, which seems to explain how to do this OpenID Connect (OAuth 2.0 for Login). But the documentation immediately says "Note: If you want to provide a “sign-in with Google” button for your website or app, we recommend using Google+ Sign-In, ...", which if you follow the link ultimately takes you to Google+ Sign-In.
What's the difference between these two pages of documentation? Why does the first tell you to go to the second while not saying the first is deprecated? Are both/either suitable for my use case? All it says is "we recommend" I want to know WHY, WHY do they recommend it?
UPDATE: I also found yet another link which seems to be documenting another approach https://developers.google.com/accounts/docs/OAuth2WebServer I think this is just for "Authorization" i.e. authorizing your app to make google api calls to get user data, so cannot be used for authenticating/sign-in.
BTW I'm building my website with a Scala Spray BE REST API & NG JS FE.
A comparison of the two is available here.
Google+ Sign-In with profile scope
Has Google client libraries for authenticating with OAuth 2.0, which includes support for Google+ and other Google services (like getting social information on a user). Also this can make implementing easier and requires less boiler plate code
Has the Google+ Sign-In button to simplify sign-in Has no pre-built widgets
Supports over-the-air Android installs
OAuth login is primarily just for authentication at a lower level, that is by making raw HTTP requests, no API.
OpenID Connect protocols (OAuth 2.0 login)
Google+ Sign-In supports OIDC interoperability if you configure with the openid scope and get the user profile using getOpenIdConnect.
OAuth 2.0 login supports OIDC directly. Use it for signing in users to apps that do not need social features and run on platforms not supported by Google+ Sign-In.
I'm trying to figure out what I need to do in order to achieve seamless SSO sign up.
When an administrator of a domain installs my google app, all of the users on his/her domain, should be able to sign-in through SSO without seeing any confirmation prompts. I'm looking into documentation on how to set this up:
Instead of displaying a confirmation page, your application should
match the value of the openid.realm parameter in the OpenID request
against the value declared in the application's manifest.
Is there an example of this? Also, I think Google stopped using XML manifest files once they switched from OpendID to OAuth 2.0. If so, how does this whitelist process work with OAuth 2.0?
Should I be utilizing Google Admin SDK?
Since google is moving away from OpenId, white listing instructions are obsolete. Found a blog post about Domain-wide delegation with Oauth 2.0. Google recommends the following:
the recommended authorization mechanism is now to use OAuth 2.0 and
service accounts. Google Apps domain administrators can delegate domain-wide authority to the service account’s credentials for a set of APIs. This results in allowing the application, by using the service account’s credentials, to act on behalf of the Google Apps domain’s users.
instructions on how to set up domain wide delegation - https://developers.google.com/drive/web/delegation
you can find detailed step to achieve seamless SSO sign up at the following url
http://david-codes.blogspot.com/2014/07/how-to-provide-seamless-single-sign-on.html
I have a large customer base and would like to migrate them from using OAuth1 2LO to OAuth2 Domain-Wide Delegation and
1) Would like to know if it's possible.
2) If possible, can it be done without user intervention/impact.
For reference, I am looking at/following the OAuth1 migration doc (https://developers.google.com/accounts/docs/OAuth_ref#migration):
According to the delegation docs, we'd want to create a "service account", but the OAuth1 -> OAuth2 migration guide (https://developers.google.com/accounts/docs/OAuth_ref#migration)
Your application must have an OAuth 2.0 Client ID. You get this Client ID by registering the application as an installed app or a web app in the Google Cloud Console.
1) Does this also work for "service accounts"?
If the migration does work for service accounts, there appear to be manual steps on the part of the admin for setting up delegation (found here: https://developers.google.com/drive/delegation)
The service account that you created now needs to be granted access to the Google Apps domain’s user data that you want to access. The following tasks have to be performed by an administrator of the Google Apps domain:...
2) Does this mean that we will require our customers to complete these steps ?
Any help would be appreciated
There is no token migration involved for the delegation case (so, ignore the migrations docs: https://developers.google.com/accounts/docs/OAuth_ref#migration).
In order to migrate to OAuth2 in this case, you will have to implement Google's 2-legged OAuth2. For information on how to do so, check out Google's 2-legged OAuth2 and Google Drive SDK delegation docs.
Hope that helps!
The OAuth2 PHP client code is awesome. It gives great examples on how to use OAuth 2 with Google APIs. The problem is that I only want to use OAuth 2 for authentication NOT for authorization. I've looked around in the API for something that just authenticates but I can't find the right class.
How do I configure the Google PHP client to only authenticate via OAuth?
I considered just authenticating the client (i.e. `$client->authenticate($_GET['token'])) but that's not ideal because the user is still asked to authorize access to different resources. I don't want to see their email, picture, etc. I just want Google to verify that they are who they say they are.
Well, OAuth is an open standard for authorization and not for authentication!
Most providers however give you the chance to query a users profile, so you can authenticate the user. Without the access to his profile data, especially his user id, you can not achieve this.
See Google's documentation for obtaining the user's profile information for login.
If you only want to use authetication you have to use: OpenID / Federated Login.
See: https://developers.google.com/accounts/docs/OpenID
why do we need authsub when we have oauth?
You don't. OAuth is newer. It didn't exist when AuthSub was developed. Google still supports AuthSub, however.
Google uses AuthSub as well as OAuth. But OAuth is used by many web service providers like Amazon, Facebook, Twitter, etc.
You can find more about OAuth : http://hueniverse.com/oauth/
http://www.socialtechnologyreview.com/articles/oauth-pros-and-cons-oauth