I have successfully implemented Google Login in my web application, using OAuth 2.0 for Client-side Web Applications. For most needs, I just need to have the user log into my application once, and I pass the id_token back to my server to authenticate it, and give back a JWT token to the front end on success. The user doesn't have to log every time they visit the page by storing that JWT token in the browser.
Now I want to build some additional capabilities into my application that require me to act on behalf of the user, and so I have to incrementally ask for additional scopes. I think I have a handle on that aspect.
On the client side, I gain consent to use a Google API on behalf of a user, and then use the Bearer token I get back to make a request to that API, then I get back an object from Google.
Now I want to convey that object to my server (my back-end) to store some information in my database associated with the user that is logged into my system. How do I authenticate, on my server, that the object I got back from Google, by proxy through the browser, actually belongs to the user who is conveying it to my server.
What's to stop someone from using cURL with their valid JWT token to my server and conveying some arbitrarily constructed Google object of their own creation. I don't see anything in the Google response object that I can verify its authenticity on my server (like I can with the id_token I get from their successful login, as described here). Perhaps there is a 'sub' field (which I think is Google's notion of identity) on the object which at least lets me know it belongs to the Google User, if I can trust the object's authenticity in the first place.
Can anyone set me straight and give me a reasonably intuitive mental model to organize my thoughts around, and tell me if I'm way off base with my concerns here, or if I'm approaching this from an entirely wrong vantage point?
Related
My current application access one of the Google APIs using "3-legs" OAuth 2.0. User authorizes the app on Google consent screen, then the app requests API on behalf of the user and shows him some fancy data loaded from API. Everyday my application loads and transforms data from this API, so when the user comes next time, he sees the most relevant and actual data.
Everything works fine on the start, but as time goes, I faced two problems:
1. Query limits.
2. Token lifetime.
My question is dedicated to the second one, that I refer as "token lifetime". After some amount of time, the access token expires, and when user comes back to the app, our app obliged to send him to consent screen again. Moreover, all the time while access token has been in expired state, my app cannot load relevant data for user.
How can I solve this problem? How to continue lifetime of access/refresh tokens? Would Service account help? Would Service account work for Google Search Console API for every user, or should the user be a G Suite user inside my domain or what?
These questions are completely unclear from the official documentation here and from the Search Console API documentation.
If you have past experience with Google's APIs, please help me!
Thank you
When you use OAuth with user-consent, you do not need to prompt the user for consent repeatedly.
[a] If your usecase is entirely online and you want to be able to request a token each time the user visits your app, use the Google Sign In library or see this documentation for client-side apps.
[b] If your usecase is that you want to be able to obtain access tokens even when the user is not present, then you need to request an authorization code and store your refresh token. Your refresh tokens are longer-lived tokens and can be exchanged periodically for access tokens.
My IdentityServer application is configured to use Google login. I am using OIDC. This question is about external claims.
At login time, my application has access to all of the claims Google sends back from the auth request. I can access them in my custom implementation of UserServiceBase in the method AuthenticateExternalAsync (via the context). I can even add them to the AuthenticateResult object so when GetProfileDataAsync gets executed after the user has accepted the consent, I can access them via the ProfileDataRequestContext.Subject.Claims list. But this is the last point they will be in memory.
If I do not save these claims in a database, how can I access them once the login process is over? I want to keep my id_token simple so I do not put claims (other than sub) in the token. So I need to call the /userinfo end point to get the claims, but by this point they are no longer in memory.
What is the cleanest way of getting these claims back? To be clear, I want to get the claims from Google when the user calls /userinfo and translate them to the claims naming convention of my application. (I do not want to store them in the id_token at login time if possible... as per OIDC spec)
Note: This question is similar to mine, but that does not address how to do it using IdentityServer3.
Yes, you will need some persistence mechanism for the claims from the external provider. You should already have this, as the subject claim that you are issuing from IdentityServer should be unique to your token service (and not the unique id google gives you).
there is a service where one can authorize using their Google account.
I need to automate the workflow with that service, so my software has to log-in with a given Google account.
But as I've never done that before I don't know where to start. Most related answers suggest to display the authorization page to the user letting them to enter their login/password of their Google account, but that's not the case since my software must be fully automated, plus it is being ran in terminal mode so no browser neither any human to enter anything should be involved.
I wonder if such automation could be possible and where should I start.
The standard way to authenticate a user with google is through a three-legged oauth authentication flow (in a browser). You can do this in go using the oauth2 or with a more comprehensive package like goth
The general flow is:
redirect user to a landing page on google's site where they are prompted to grant you access.
google will make a callback to your site with a special code.
you make another request to exchange that code for an access token and a refresh token.
Use access token to use google apis, and use refresh token to get a new access token anytime it expires.
It is more detailed than this, and there is a lot to get right to keep it secure, but that is the general idea.
Now, like you've said, your app is a command line thing, so it is hard to do that flow. Unfortunately, you may need to do that once, just to get a refresh token. Once you have that, you could give it to your application: myapp -google-token=FOOBAR123, and your app can exchange the referesh token for a valid access token.
Maybe this will help: https://github.com/burnash/gspread/wiki/How-to-get-OAuth-access-token-in-console%3F
I'm writing a web application that reads my personal calendar data, crunches stats, and then spits them out for the world to see. I don't need an authorization flow. Is it possible to leverage the Google APIs without going through a user sign-in flow? In other words, I want my personal Google account permanently and securely signed in to my server without the risk of my token invalidating or having to re-auth.
Right now I'm signing myself in with an offline token, then uploading the authorization file onto my server, basically spoofing the server that I already auth'd. Is there not a cleaner way?
I've spent hours reading through the API docs and Auth docs, but haven't found and answer. If there is a page I've missed, please point me to it!
PS. I'm using the Calendars API through Python/Flask on Heroku, but that shouldn't matter.
An alternative approach is using a service account while sharing your calendar with that service account. See https://developers.google.com/accounts/docs/OAuth2ServiceAccount
So, you want to be remembered.
If you want to dispose of any kind of authenticacion but yet the user needs to be recognized you should be using a cookie.
On the server side that cookie should be used to select the offline token.
Of course, without that cookie the user needs to be authenticated in any way. I would make them reauth by Google so you get a new offline token.
Hope that it helps.
Background
I'm working on an app that will run on a device which does not contain a browser, but I want to get the users google tasks through the google api.
Because of the lack of browser, they can't authenticate on the device, so I have it set up in such a way that they visit a website and authenticate there, then the device makes http requests to the website to get the data it needs.
Problem
Once I got everything working this system works out OK, the problem is it only works for a day or so before the user has to visit the website again to refresh their access token.
It would be great if the user could be authenticated for very long periods of time, or even forever (not sure if that's possible or secure). Can I get some suggestions on what people think is the best way to accomplish this kind of long term athentication?
Refresh tokens?
I've heard there is a way to store the user's refresh token in a database and somehow use that to refresh their access token. If this sounds like a good way, can anyone point me in the direction of an example to get this to work?
I've been using the google api client library for ruby
Thanks a lot!
You're on the right track with the refresh tokens. I can't help too much with the Ruby API, and honestly I just did this calling the REST api directly, but this doc should help you understand the actual calls you need to make.
https://developers.google.com/accounts/docs/OAuth2WebServer#offline
Note that for a lot of their examples you need to remove the newlines for them to work.
Basically like you said, you need to send the user to https://accounts.google.com/o/oauth2/auth with the access-type=offline parameter for them to give consent. This comes back with an authorization code, which you send to /o/oauth2/token. This comes back with an access token and a refresh token. You can use the access token immediately, and you store the refresh token, which never expires. When the access token expires you send the refresh token to /o/oauth2/token (note that the grant_type changes to refresh_token) to get a new access token.