I'm writing an packaged app using javascript for google chrome web store and I need to identify the users e-mail. using Identity I've retrieved OAuth 2.0 token (by chrome.identity.getAuthToken() command). What next?
I've found this documentation but i'm afraid it can be used only for hosted chrome apps.
The above documentation can be used also in cases where the application only has a client-side presence. You can extract the email_address from the id_token (https://developers.google.com/accounts/docs/OAuth2Login#obtainuserinfo); that would be most efficient. Or you can use the access_token to retrieve the same data from the user_info endpoint, which requires another AJAX request (https://developers.google.com/accounts/docs/OAuth2Login#obtaininguserprofileinformation).
If you manage to configure the G+ Sign-In widget for your extension you'll find out that it simplifies these tasks considerably. Note that G+ Sign-In has been recently updated and works for all Google account users (including Google Apps users) whether or not they have signed-up for the Google+ service. See https://developers.google.com/+/ for more information.
Related
I'm using the Google People API to get user account info (only for the user who authorized via gmail sign in using the Gmail API) from a Node JS client. I want to make sure that the people.get method I use won't be affected by the shutdown of Google+ and it's APIs.
This is an excerpt from the email that Google sent on 12/20/18 notifying developers of the shutdown:
"Note: If you see calls to people.get, these can be the result of using the Google+ Sign-In feature in your application, which is now fully deprecated and is being shut down. Developers should migrate from the Google+ Sign-In feature to the more comprehensive Google Sign-in authentication system."
As stated above, I am using the People API to call people.get but it's unclear to me whether or not this will be affected by the Google+ deprecation.
If you're using the people.get API documented at https://developers.google.com/people/api/rest/v1/people/get, then you're fine. This API is not impacted by the Google+ API shutdown.
If you're using the people.get API documented at https://developers.google.com/+/web/api/rest/latest/people/get, then you will need to migrate to a different API.
I have to develop a RESTful API for a mobile application and I have some concerns about the flow of the communication between those parts. I'm new to the API development for mobile devices and OAuth.
The project in common should work this way:
users are allowed to login using only their Google accounts
the mobile application uses the website API and all the information is stored on the backend
I found a similar question here OAuth on REST API for mobile app and I prefer the first solution from it, but I have some questions about the security of this solution.
1) Should I use OAuth2 for the API? I'm not sure it's a good idea just to send the user's Google ID to the API to get user's data.
2) How can I check on the server that the Google ID is correct and actual? Or it's not important at all?
I'm thinking about this scenario, but I'm not sure it's the best solution:
1) The user logs in on the mobile application for the first time using his Google Account.
2) The mobile application receives Google ID and some additional information.
3) The mobile application sends the Google ID to the server.
4) The server uses OAuth2. It creates an account for the user (saving the Google ID in the database) and returns an access token to the mobile application.
5) The mobile application stores the access token locally and uses it for requests to the server. Once the access token expires, the user has to login in the mobile application again using his Google account.
I have some concerns about using just Google ID for generating a token. I mean, anybody can just use somebody's Google ID to create a token. Bad idea :(
Also should I use JWT better as a token?
Thanks for your help!
You should send the user's id_token to the API instead
There are a couple of different ways in which you can validate the integrity of the ID token on the server side:
a) "Manually" - constantly download Google's public keys, verify signature and then each and every field, including the iss one; the main advantage (albeit a small one in my opinion) I see here is that you can minimize the number of requests sent to Google.
b) "Automatically" - do a GET on Google's endpoint to verify this token
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token={0}
c) Using a Google API Client Library.
As for the workflow, it's mostly correct, except for the last step, where you can instead refresh an access token without prompting the user for permission. Btw, Google's id_token is actually a JWT.
I am writing a project that lets users implement login integration for multiple web services (e.g. Google, Facebook etc.) to his/her website. I see Facebook allows us to manually build a login flow. Using this I can code everything myself and also let users use the script just by configuring it a bit (like setting app_secret and app_id). I am looking for a similar thing in Google. I don't wanna use the SDK because if I do that for multiple OAuth providers, then I think I'll mess things a lot. I also want to keep the client (JavaScript) side code at a minimum. So, can I build a manual login flow for Google, as I can for Facebook?
This information is given on the following page: https://developers.google.com/identity/protocols/OAuth2UserAgent (select the OAUTH 2.0 ENDPOINTS tabs)
Some excerpts:
The OAuth endpoint is https://accounts.google.com/o/oauth2/v2/auth
Token is returned like this: https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
You can validate the token by using the tokeninfo endpoint: https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=<access_token>
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.
In our company we run a number of different websites which are being tracked with Google Analytics (GA). Up to this point we have been using the Login protocol and GData to access GA data to display the data nicely on our custom web application dash boarded which we use for tracking traffic on our sites.
Nowadays Google has Google API Console which lets you track your API usage. We want to take advantage of this service to view howmuch APIs we consume. However from what we can understand it requires us to use OAuth for authentication instead of the username and password we currently use to access the data. We don't like OAuth because it redirects the user to Google for authentication when currently the user has no need to know about where the data is coming from and what credentials are needed.
Is there anyway that we could make Google API Console monitor our usage without having to switch from GData and the Login protocol?
You can switch to the OAuth 2 protocol and use a refresh token for offline access. Once you get the refresh token, you can save it to a file or database and use that to access the data without an authorization redirect.
See the docs here: https://developers.google.com/accounts/docs/OAuth2InstalledApp#refresh
Also see where there is discussion of using the refresh token: How can we access specific Google Analytics account data using API?