I have a web app built on oAuth2 that has been in production for 5+ years. Users Authenticate and Authorize with Google and grant my application access to the Google Analytics data.
All of a sudden I am seeing a surge in failures when refreshing my users oAuth2 tokens. This is the call:
https://accounts.google.com/o/oauth2/token
Passing these parameters:
client_id=xxyyzz
client_secret=xxyyzz
grant_type=refresh_token
refresh_token=xxyyzz
This seems to be be on accounts that are less active (i.e. it could be 15+ days between instances where we make calls on their behalf). I have to reach out to them and have them "ReAuthorize" against Google to get things working.
1) Did something recently change with Google oAuth2 or the GA Core Reporting API?
2) If access tokens are not refreshed after some time period will my refresh token become invalid? i.e. should I make calls against all accounts even thought I don't need the data; just to keep the refresh token from going stale?
Thanks,
Mark.
Update on Scope
It was requested to provide the scopes in play here:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/analytics.readonly
11/17/2016 Update:
We did find an issue that resulted in some tokens being purged. We are working on to make sure it doesn't happen again. Unfortunately there is no way to restore the tokens that were deleted and your users will have to reauthorize again.
11/11/2016 update:
We are actively investigating the issue. You should ask your users to re-authorize the application.
(from Google Identity/Auth team) We would like to investigate this a bit more to make sure our system is working as intended. Other than the token revocation (with certain scopes) on password change, we haven't changed the token revocation policy.
Would you please ping me via my G+ profile?
Related
I'm working on a project that has the following requirement: Sessions should never last more than 90 days.
I'm also using Firestore, and by extension to authenticate users, Firebase Auth. I want to give access to Firestore to my android and ios clients, for 90 days maximum. After that duration the session should automatically expire.
I initially thought custom tokens were the solution, because I thought they were just a different term for ID tokens. But in reality they can be used to get a refresh token that never expires.
I therefore thought about managing the refresh tokens myself, by:
issuing my own refresh tokens
verifying their validity
creating a new custom token
exchange the custom token with an id token and refresh token on the back end
only return the ID token to the client
the client would give it to firestore.
I don't mind managing expiration and renewing the id token myself on the my back end.
Now my problem is that when I look at the official SDKs for firestore on Android and SDKs, none seem to allow for just attaching an id token to requests?
Is there a solution to my issue? Or maybe even a better approach?
Thanks!
I'm working to implement Google Actions, and I've came into this problem.
After successful authentication (Account Linking with OAuth) everything works fine, all of the intents (SYNC,QUERY ec...) are working.
During the test fase I've restarted the server that handles the authentication and the intents (which also holds user sessions our side) so the user session that Google has became invalid (in existent) at our side, so when a new intent is incoming with the access token (that we could say has been expired on my side) the intent fails for authentication error. And here comes the issue:
I've tried to respond with authExpired or even authFailure as described here: https://developers.google.com/actions/smarthome/develop/process-intents#error-responses
but it simply does not work. It seems like until the token does not expire on Google side, I'm not able to make it expire "intentionally". So to make it work we are forced to unlink the action or wait the expiration time than everything works as expected.
It this an intended behavior?
I hope my question was clear, if not I'm here to add more details.
Thanks,
It seems like until the token does not expire on Google side, I'm not able to make it expire "intentionally".
You are correct that this is the current behavior. Generally speaking, we expect developers to use short-lived access tokens where the expiration time is meaningful in requiring those tokens to be granted again.
Developers wishing to enable users to intentionally revoke access (outside of unlinking their account) should invalidate the refresh token provided to Google and continue to return an authFailure when those credentials are presented.
I'm making an application that among it's task will use the REST API in KeyVault. I already have functions written that will query the KeyVault for the secret without an issue.
I also have functions written to request an OAuth token from AAD, following the documentation on this link:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
What I'm not sure about is; Since the application is going to be installed on hundreds of computers when a token expires and the function to refresh the token is called chances are that more than one PC is going to make the POST. What is the best practice for a scenario like this? Should i just configure an exponential back off after a refresh token function is called?
The app installed on the machines will not have the ability to talk to each other.
The only way I can think to do this is to use a logic app as the broker but that would defeat the purpose of the KeyVault.
The document you provided is using the code grant flow to acquire the access token. This flow requires users to login to acquire the token. And did you mean all the PC you installed will use the same account to acquire the token?
If yes, you can design you own token cache. For example, you can using an SQL server to store the cache. Then the app will search the token/refresh token in the token cache before it sends the token request. And if the token is expired, you can refresh it. In this scenario, all PC will share the same access token since they are sign-in with same account.
If not, you need to refresh for the every PC when the access token is expired. Because the access token is different from each user.
So after some testing and verifying with MS it looks like the documentation on the link is outdated. When a token is generated it has a lifetime of 8 hours (this is configurable) so every time I make a request to /token a new token is handed out, since the time window is small I don't need to worry about token refreshes since PCs won't be on for over 8 hours.
The other part of this is that i built a function to test the validity of the existing token, before i query any azure service i test the token validity, if it fails a new token is requested. Since the token lifetime windows are short and each machine gets it's own token (i thought all machines were getting the same token, code error on my part) this is a non-issue anymore
Use-case: Emails to be sent from a web-application upon an event, as someuser#somedomain.com via MS Exchange or Outlook.com, using the RESTful APIs exposed by Outlook.com. Only HTTP access allowed (=> no SMTP/IMAP).
All documentation seems to mention that the app has to forward users to MSOnline, sign-in and then use the authorization code sent back by MS online.
But, this won't work for a background task (=> no sign-in possible!) where a pre-built token(with some predefined scope) is necessary so that Outlook.com can be accessed via APIs to send mail as someuser#somedomain.com.
Any hints/pointers to how it could be done? Basically, automated authentication without explicitly signing in as 'someuser#somedomain.com' on the MS Online login page.
I did not find M$ documentation regarding Outlook REST APIs to be of any great help and found it to be pretty difficult to navigate/understand. :(
Thanks!
At some point you will have to have the user sign in to grant access to your app. So you would need to have some sort of user-facing web front end where they can do this. Once they have signed in and you've obtained an access token/refresh token, your background app should be able to use those tokens silently, without user interaction, at least until the user either revokes access or the refresh token expires.
Currently Azure (which provides the login/token functionality) does expire the refresh tokens after some time (90 days), at which point the user must sign in again to grant your app continued access.
As far as I thought, Instagram does not invalidate access tokens based on their documents. But for a few users of the thousands using one of my applications built on their API, that does not seem to be the case.
I originally referred to the following SO question when initially building the application, and a few others - but I came to the conclusion (or so I thought) that Instagram does not invalidate tokens, which does not seem to be true: Instagram access token expire
Our application makes requests on behalf of a user at specific times of the day. It is an application that users may only need to ever log into once to utilize the service.
Here, for example is a user who signed up 4 days ago - his service was working great until this morning, when testing his access token we were receiving this response:
{"meta": {
"error_type": "OAuthAccessTokenException",
"code": 400,
"error_message": "The access_token provided is invalid."
}}
Why would this be happening on an access token that was valid 4 days ago? We asked the specific user this error is being returned for if he revoked access to our application or anything along those lines, and he did not.
I'm curious if perhaps he changed his IG password which invalidated his access tokens for applications (Although that doesn't seem likely as to what would cause this?)
Does anyone else have experience with Instagram applications randomly invalidating access tokens?
Also, note that 99% of users who have been using our application for a month or more have never had this issue. We've only encountered 3 to 5 other accounts this has happened with.
It's not really random. In fact an access token can be invalided in this 2 cases:
the user changed his password or where forced to do so (when IG thinks your account has been compromised).
they deleted the app the access token is linked to. (Or IG forces the app to be deleted if they suspect spam behavior)
But they do not expire from time.
From own experience the token can expire if:
the user removes the app
the Instagram account gets temporary locked which can happen if the Instagram user logs in from an unknown device/location (e.g. another country). The user is being asked to confirm identity by inserting an SMS code.
The second scenario is probably an Instagram bug. Why would the app token expire each time the account gets temporary locked? Would like to get an answer from Instagram as well.
NOTE: The token does not expire if user changes password.