I'm using Google Sign-In. A user comes to my site and logs in with gapi.auth2.getAuthInstance().signIn(), or they are already logged in and when the page loads (or reloads) we fetch the status. At this point I have an identity token good for an hour that I can validate on the server.
When a user leaves the browser sitting (say, overnight), this token expires. gapi.auth2.getAuthInstance().isSignedIn.get() returns true, but the token does not validate.
How can I log in a user and keep them logged in while their session is active (ie, browser hasn't been closed)? Or refresh the token? Anything more graceful than reloading the page...
Edit: The refresh token is not a correct answer; I don't want offline access (and don't want to ask for the permission). Google obviously thinks the user is still signed into my application; the user can reload the page and get a new token without providing credentials again. Surely there is some mechanism more graceful than a hidden iframe to get an updated token?
If the token is expired, you can call gapi.auth2.getAuthInstance().currentUser.get().reloadAuthResponse(). It returns a Promise.
I've raised an issue with Google over this because it's simply ridiculous they haven't documented this properly.
My comment here advises how I've accomplished refresh using the above.
FWIW, we've managed to (mostly) make it work via a listener approach. It appears that 'userChanged' callback is invoked ~5 minutes before the access token expires. That's enough for us to extract and update the access token without refreshing the page.
What does not quite work though is when computer comes back from sleep. This can be solved relatively easy by reloading the page on wake up.
You can accomplish this with listeners.
var auth2 = gapi.auth2.getAuthInstance();
// Listen for changes to current user.
// (called shortly before expiration)
auth2.currentUser.listen(function(user){
// use new user in your OpenID Connect flow
});
This will allow you to keep current credentials, as long as the browser remains active.
If the computer is put to sleep additional work must done to get current credentials.
if (auth2.isSignedIn.get() == true) {
auth2.signIn();
}
You can use Refresh Token to get offline access. As per the official reference
Access tokens have limited lifetimes. If your application needs access to a Google API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
Basically you will get the refresh token the first time you ask for authentication. You need to save that token securely for future use. The access token (you mentioned as identity token) expires after an hour. After that you have to use the refresh token each time you want to get a new usable access token.
Depending on the client library you are using the syntax will differ. following is a sample for php client library.
// get access token from refresh token if access token expire
if($client->getAuth()->isAccessTokenExpired()) {
$client->refreshToken($securelyPreservedRefreshToken);
$newToken = $client->getAccessToken();
}
check this for details steps.
Related
We are using calendar API of google and it's working fine and we have achieved almost each requirement.
But we stuck at below point,
How to generate new "Refresh Token" once it's revoked or expired?
Also I need more information on when "Refresh Token" expire and how would I know the life of this refresh token, so I can automatically create new before it expired?
Any answers is highly appreciated.
You may want to check this related SO post, refresh token doesn't expires unless the user revokes it. Until it does, your app must catch this issue then ask the user for permission in order to avoid encountering such problem. Here is the link for the documentation of Google:
Save refresh tokens in secure long-term storage and continue to use
them as long as they remain valid. Limits apply to the number of
refresh tokens that are issued per client-user combination, and per
user across all clients, and these limits are different. If your
application requests enough refresh tokens to go over one of the
limits, older refresh tokens stop working.
If you'll continue reading until Token expiration:
You must write your code to anticipate the possibility that a granted refresh token might no longer work. A refresh token might stop working for one of these reasons:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
Hope this clarifies your concern.
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
In Webserver Grant Flow
After I obtain the Authorization Code from the authorization authority (after the user has authorized my access) how long is that code usually valid form?
The reason i am asking is, can my webserver store that code and use it in later sessions to retrieve a new access token without the need for the user to re-authenticate again? Should that be the flow?
FYI my goal is make requests from Adobe Analytics and Google Analytics on behalf of my customer. So i would want to ask my customer for authorization once until he revokes my access.
Speaking strictly of Google Oauth. There are three types of codes or tokens you should be aware of.
Authorization code
Access token
Refresh token
Authorization code is return when the user clicks accept to your application accessing their data. This code is used to exchange for an access token and a refresh token. This code can only be used once and is extremely short lived 10 minutes I believe.
Access tokens are used to access private user data. They are valid for approximately one hour.
Refresh tokens are used to gain a new access token when the access token has expired. For the most part refresh tokens do not expire however if it has not been used for six months it will no longer be valid and of course the user can always remove your access.
Answer: No storing the authentication code would be pointless. You will need to store the refresh token. make sure you are requesting offline access of your users.
I cant help you with adobe analytics however I suspect it is similar this is standard Oauth protocol we are talking about.
I'm doing oauth in echo sign and have come across following steps.
App makes a get request to echosign along with the return url.
ex: https://secure.echosign.com/public/oauth?redirect_uri=https://example.com/oauthDemo&
response_type=code&client_id=d4HQNPFIXFD255H&scope=user_login:self+agreement_send:account
Echosign, asks the user to login to echosign and on success it appends code to the return url and sends back.
Taking the code from the return url, another post call is made to get the access token using which , api calls can be further made.
POST call to /oauth/token
On this success, token-access has been generated successfully.
The things here is, how can i bypass the step where user will not have to login to echosign. Is there other easier way to get the access-token, seems like, code needs to be generated each time to get a new access-token.
I'm working on meteor, angularjs. Also i couldnt find any working examples on js, is there any ?
Please correct any of my steps.
I couldn't find a way to bypass the user to login but this needs to be done only once.
At this step you get the access token, refresh token and expiry time in seconds.
Check if your access token has expired and if so then use your refresh token to get a new access token. You can use the refresh token indefinitely until the EchoSign user manually revokes your application's token.
User your access token to make API calls.
PS: I don't know any working examples in JS.
I have to admit the process of renewing an expired token at the server-side, because the FB user has logged out, confuses me. The solution to handle expired tokens, as presented on this page, would only seem to work if the user was viewing a server page that could prompt said user to re-authorise the app (JS location.href redirection to a FB dialog URL).
What if a server side app has saved the access token because of some processing that will take some time first? If after some hours/days the server wants to post something to the user's wall, using the either the short or a long term token, but the user has logged out of Facebook - what then? Sure, the request will fail because of the logged out status of the user, but this seems to me to also mean the server will have no valid way of posting to the user's wall until they log back in to Facebook (and the app happens to try to post again at the right time).
Am I right here or missing something obvious? Seems a crazy scenario to prevent a server-based application from posting to a pre-authorised user's wall just because said user has logged out (which i'm sure many, many users do on a regular basis). Why does logging out == deauthorising the access token? And, if the user logged back in, does the existing access token become valid again, or is a whole new token required (assume we have obtained a 60 day token)?
Why does logging out == deauthorising the access token?
It doesn’t. A long-term access token doesn’t get invalid just because the user logs out of Facebook!
So get a long-term one, valid for sixty days – and you’re good to go to post or do whatever a few days after requiring the token. If the 60 days are over and the user hasn’t interacted with your app since, then you have to have the user come back to your app to get a new token.