The tokens are used for a server side process. We are requesting various scopes including offline_access. The process runs successfully and renews the access token for most users.
However, for a handful of users we have an issue where once the initial access token expires, the refresh token immediately fails with the following exception:
{"error":{"code":"InvalidMsaTicket","message":"ErrorCode: 'PP_E_RPS_REASON_TIMEWINDOW_EXPIRED'. Message: ''","innerError":{"requestId":"some-guid-here","date":"2020-03-24T14:40:17"}}}
From Microsoft documentation, access tokens should be valid for 1 hour and refresh tokens valid for 14 days.
We've had users re-authenticate with the same results.
Related
I have integrated a Git-Lab OAuth app in my web-app. Users authenticate this OAuth app and give access to their Git-Lab repositories through the Access Token. Once a user connects his repositories with my web-app , my web app saves the refresh token and access token in the DB and a cron job runs every 2 hours to refresh the tokens so that It never loses the connection to the connected repositories. (GitLab access token expires after 2 hours).
Here is the Git-Lab API URL which my cron job hits to refresh the tokens.
https://gitlab.com/oauth/token?client_id={}&client_secret={}&refresh_token={}&grant_type=refresh_token&redirect_uri={}
Now this cron job to refresh the tokens was running perfectly since more than a week, and suddenly it failed to refresh the tokens and hence I have lost the connection to user repositories. The error message received from GitLab API is as follows
The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
This job was running fine since a week, so all provided parameters to the Git-Lab API URL seems fine to me. e.g. client_id, client_secret, refresh_token ,redirect_uri etc.
What can be the possible reason of these token expiration. I have lost the connection to user repositories and the only choice I am left with is to go back to user and ask them to reconnect their repositories by re authenticating the OAuth App.
Can it be the reason that my cron job was running too often (12 times a day ) and refreshing the tokens at a high frequency Or may be if the Access token was still valid and a try to refresh that token caused this issue. ?
No, I can hit the API to refresh token as many times as I want, I could hit it 100 times in few seconds and got my tokens refreshed 100 times.
I also used the access to token to pull a repository , then updated the tokens and again used the previous access token (expired) to pull the repository, this time it failed to pull the repository for obvious reason (token has expired) , and then I updated my tokens again. I can successfully update my tokens all the time.
That means using an expired token to pull the repository is not the reason for tokens expiration
I need to know the real cause which has expired my tokens.
I need to emphasize on that my Refresh Token has expired and I can no longer refresh my tokens.
I have read through the GitLab API docs and haven't found any clue of the reason why my token got expired.
It seems like you tried to use a token that has been refreshed. That is, between the time you pulled the token value and used it, the refresh occurred, which immediately invalidated the token you were trying to use.
my web app saves the refresh token and access token in the DB and a cron job runs every 2 hours
Don't do this. In general, you should not be periodically refreshing these tokens because you will invalidate the active token, nor is there any real reason you should need to do so.
Just refresh the token at the moment when you actually need to use them if the token is expired. Even though the access token may expire, the refresh token can still be used after the access token itself expires -- that's what the refresh token is for, after all.
Please check that your service waits enough time for a response from GitLab(may be reasonable to increase timeout) and doesn't have retry logic - the refresh token could be used only once.
Depending on the resource owner (Gitlab, etc.), there are various reasons why a refresh_token could have become invalidated.
A few to note:
Your integration was reauthorized, invalidating any existing access_tokens and refresh_tokens
If a new access_token is generated, both the previous access_token and refresh_token will become invalid.
If the integration was deauthorized by an end user or token revoked programmatically (not sure if Gitlab offers this)
You might also find some of the tips in this OAuth Troubleshooting Guide helpful.
We have Google OAuth2 Web client at Google API Console
With the help of Oauth Web Client, we get Refresh token for each Users ( By using web Authentication & Concert Screen )
We store received Refresh Token to database and, System user this user specific Refresh token to create Google Calendar Event automatically on behalf of logged in user ( We have around 1000 Users)
Problem : Since couple of days Refresh Token has been expired automatically and getting following error.
{
"error": "invalid_grant",
"error_description": "Token has been expired or revoked."
}
When user do re-registration System receive new Refresh token and everything again start working, however after some time ( no sure but in less then day or two ) again they start getting Token has been expired or revoked error.
Is there any Limit has been expose on Refresh Token ?
Is there any Limit to get Refresh Token by using Same API Client? ( We have individual 1000 Gsuit or Gmail user who have registered for Refresh Token individually using by using their person Gmail or Gsuit Account)
Is there any API change to get long live Refresh token ?
Regards,
DP
Your Questions
Is there any Limit has been expose on Refresh Token ?
You can authorize a user and get a refresh token, then authorize the same user again and get a second refresh token. The user now has two outstanding refresh tokens and both work. You can do this up to fifty times and have fifty outstanding refresh tokens for this user. Once you do it again the first one will expire.
You can have fifty out standing refresh tokens for a user so if you are re authorizing them make sure that you are replacing the one stored in your database with the newest refresh token.
Is there any Limit to get Refresh Token by using Same API Client? ( We have individual 1000 Gsuit or Gmail user who have registered for Refresh Token individually using by using their person Gmail or Gsuit Account)
Your client can authorize as many users as you like. There is no limit to the number of users you system can have.
Is there any API change to get long live Refresh token ?
Not that i am aware of
The error message
There are a couple of things that could be happening here.
The first being that the user has the power to revoike your access though the their google account. It looks to me like this may be what is happening.
The second issue is the fact that its October and Google daylight savings time is kicking in. Several years ago there was an issue with daylight savings time expiring tokens.
Third issue is that if your refresh token has not been used in the last six months it will be expired by google.
The fact of the matter is that refresh tokens are not perfect due to the above reasons. Your system should be designed to handle this if the refresh token fails then simply set it up to ask the user for access again.
{ "error": "invalid_grant", "error_description": "Token has been expired or revoked." }
My skill requires Account Linking which will authenticate customers with an AWS cognito user pool through OAuth 2.0 Protocol.
I can specify in the user pool the TTL of the refresh token, which I decided to have it valid for 60 days.
From what I understand, alexa sends you the access token along with each request that your skill receives so you can identify customers using the skill. If their access token expires alexa would handle this by refreshing their token before forwarding the request with the access token to you. So you can have a valid access token.
Now, what happens when the refresh token expires? and does it expire after 60 days even if the customer is using the skill on daily basis? I guess what I'm asking is:
When the access token expires and alexa refreshes it. Does the refresh token also get refreshed?
If yes, how do we keep the customer signed in and their account linked when the refresh token expires after 60 days?
I think you can find the answers in the documentation.
Verify that the token is valid
If the accessToken exists, verify that it identifies a user in your resource server. The token could become invalid for multiple reasons, for example:
The user deleted or canceled their account with your service. For example, an Alexa user might have set up account linking with Ride Hailer, then later canceled their Ride Hailer account. At this point, the token stored by the Alexa service would identify a non-existent user.
The token has expired, and the Alexa service was unable to obtain a new token. This can occur with an authorization code grant if your authorization server does not provide refresh tokens. This can also occur if you use an implicit grant, which does not support refresh tokens.
If the token is valid, handle the request normally. You can use the token to access data from your resource server as needed. In the Ride Hailer example, the skill would retrieve profile and payment information for the user from the Ride Hailer service, order a car, and return a confirmation to the user. See Return a Response for details.
I tried to add YouTube Video from the third party and After one day, I got the success in doing so. But While uploading a video the access token is required and in order to get that access token the user must be logged in. And the expiration time for that access token is 3600 seconds( 1 hr).
Now, There are some of my questions regarding this.
Is there anyway, by which I can refresh access token.
If some one has G Suite account, then Is there any special values for expiration time, or it remains the same?
As per the documentation, I can have maximum 50 tokens, So is there any alternative for it, So that I can get valid token after 50 requests.
To answer your question for number 1, you can check the documentation here.
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that
object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the
user to Google's OAuth 2.0 server. In that case, Google's
authorization server returns a refresh token when you exchange an
authorization code for an access token. Then, if the access token
expires (or at any other time), you can use a refresh token to obtain
a new access token.
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
About the G Suite account, it was stated 24 Hours in the documentation. Note:
In this SO post answer, the function of Access Token and Refresh Token was discussed.
I am not sure if there are ways to alter the limits because of security reasons.
To clearly differentiate these two tokens and avoid getting mixed up,
here are their functions given in The OAuth 2.0 Authorization
Framework:
Access Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted
by the resource server.
Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server
and are used to obtain a new access token when the current access
token becomes invalid or expires, or to obtain additional access
tokens with identical or narrower scope.
I'm developing an Android app that uses Outlook Calendar REST API. I'm trying to keep in synch and updated the calendars of multiple users (meeting rooms).
My questions are:
1) After how long does the initial authorization code expires?
2) And for the refresh token instead?
The access token expires after 60 mins. I can't get if for the refresh token expires after 6 hours, 14 days or 90 days.
3) Is the latter configurable? Can I make it not expire?
`
UPDATE: (from https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx)
"The lifetime of the refresh token is not provided and varies based on policy settings and the time when the authorization code grant is revoked by Azure AD. The application should expect and handle cases when the request for a new access token fails. In that case, it should return to the code that requests a new access token."
And also: (from http://blogs.msdn.com/b/exchangedev/archive/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-exchange-online-in-office-365.aspx)
"Refresh tokens do not have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action. The client application needs to expect and handle errors returned by the token issuance endpoint correctly. When you receive a response with a refresh token error, discard the current refresh token and request a new authorization code or access token. In particular, when using a refresh token in the Authorization Code Grant flow, if you receive a response with the interaction_required or invalid_grant error codes, discard the refresh token and request a new authorization code."
So how can I guarantee that my App will always have all the users logged in?
It will be in airplane mode during the night and it should automatically recover from crashes as well.
Can I solve without authenticating the users programmatically storing the credentials?
Thanks
Answers:
few minutes. The exact value is an implementation detail and can change at any moment. You should do whatever you can to redeem the code as soon as you get it.
see http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
as of today the lifetime limits cannot be changed. We are working on features that will grant you more control, but we have no ETA to share at the moment
The only way of guaranteeing that a user is signed in is to successfully redeem a refresh token, or to go through an authentication flow. Use of cached credentials is restricted to very few cases, and will likely be disallowed in upcoming versions of the service.
If a refresh token expires, you should plan to perform an interactive authentication. Note that the refresh token might also be invalidated by a consent revocation, which will mandate interactivity in all cases.
What you can do is to obtain the refresh_token and the access_token. Access what you need via the access_token, if that fails then assume it has expired and use the refresh_token to update the access_token. If a user changes their password (or maybe there are other cases) then you start the user over from square one.
To get the refresh_token I think you need to add offline_access to your scope. Something like this:
USER_OAUTH2_AUTHORIZE_URL
+ "?client_id=" + config.getClientId()
+ "&redirect_uri=" + getOutlookLoginRedirect(request)
+ "&response_type=code"
+ "&scope=https%3A%2F%2Foutlook.office.com%2Fmail.send%20" +
"https%3A%2F%2Foutlook.office.com%2Fmail.readwrite%20" +
"offline_access%20openid%20email%20profile"