We provide the time validity to apptoken in "exp" claim.
Now once the token gets expired the Iframe shows message "Content is not avaible".
My question is how to programmatically detect if the token has expired?, so that i can generate a new apptoken.
When listening to errors, as in: https://github.com/Microsoft/PowerBI-JavaScript/wiki/Handling-Events#full-list-of-events-and-their-response-values
you can subscribe to report.on('error', ...) and access the message propery in the error object to detect token expiration.
Once detected, you can use the JS SDK to apply a new token without having to reload the embedded report
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Update-Embed-Token
of course, by using 'exp' in your JWT token, you can always set a timer to refresh the token
Related
I created "test-App" application in API Manager WSO2 with the grant types of "refresh-token" "SAML2", "PASSWORD" "Client Credentials" and "JWT"
I also Created a "test"
To use the webservices behind API manager, First, I should call https://localhost:9443/oauth2/token) to get a access-token
Unfortunately, if I call the link again, instead of receiving the same access-token, the system will generate a new access-token and the previous access-token would be expired. ( I think this link is more like refresh token rather than get the access token).
So, How can I Separate getting available access-token and Refresh-token link in WSO2 API Manager ?
In the latest versions of API Manager you have JWT tokens. When you request a new token it always generates a new token. But it doesn’t revoke the previous access token.
In the earlier versions of APIM, opaque tokens were supported and it has a different behavior. When you request a token, if it is not expired you get the same token.
Please read more about refresh grant here https://apim.docs.wso2.com/en/latest/design/api-security/oauth2/grant-types/refresh-token-grant/
If you have not done any other configuration changes, invoking https://localhost:9443/oauth2/token URL will always generate a new JWT token without expiring the earlier one. However, the token validity can be changed in the Dev Portal while generating the access token.
After googling we came to know that invalid_grant which means refresh token is invalid.
Link to google oauth doc
We don't have any of these issues mentioned by google. Is this error related to something else rather than a refresh token.
More Info
We have access to read, write spreadsheet and send gmail
We fetch an access token for each request
Any help would be appreciated.
We're already in production and verified by google
Without seeing the full error message that being
Invalid_grant {Message here}
It is hard to help but from my experience is most often caused by one of the following.
Refresh token expire, app not in production.
There are serval reasons why a refresh token can expire the most common one currently is as follows.
A Google Cloud Platform project with an OAuth consent screen configured for an
external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
The fix is to go to google developer console on the consent screen and set your application to production, then your refresh token will stop expiring.
invalid_grant: Invalid JWT
{ “error”: “invalid_grant”, “error_description”: “Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values and use a clock with skew to account for clock differences between systems.” }
Your server’s clock is not in sync with NTP. (Solution: check the server time if its incorrect fix it. )
invalid_grant: Code was already redeemed
Means that you are taking an authentication code that has already been used and trying to get another access token / refresh token for it. Authentication code can only be used once and they do expire so they need to be used quickly.
Invalid_grant: bad request
Normally means that the client id and secrete you are using to refresh the access token. Was not the one that was use to create the refresh token you are using.
Always store most recent refresh token.
Remember to always store the most recent refresh token. You can only have 50 out standing refresh tokens for a single user and the oldest one will expire. Depending upon the language you are using a new refresh token may be returned to you upon a refresh of the access token. Also if you request consent of the user more then once you will get a different refresh token.
User revoked access
If the user revoked your access in their google account, your refresh token will no longer work.
user changed password with gmail scope.
If your refresh token was created with a gmail scope and the user changed their password. your refresh token will be expired.
Links
Oauth2 Rfc docs for invalid_grant error rfc6749
invalid_grant
The provided authorization grant (e.g., authorization
code, resource owner credentials) or refresh token is
invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
Execute compute engine
api(GET https://compute.googleapis.com/compute/v1/projects/{project}/zones/{zone}/instances/{resourceId}) with oauth 2.0 client id.
I created an OAuth2.0 client ID and got access_token and refresh_token based on the steps on this site.
Obtaining OAuth 2.0 access tokens
Refreshing an access token (offline access)
I can execute api with access_token which was refreshed.
after 3days, run this step again,
https://developers.google.com/identity/protocols/oauth2/web-server#offline
response was
json
{ "error": "invalid_grant", "error_description": "Token has been expired or revoked." }
why expired refresh_token?
refresh_token
A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Again, this field is only present in this response if you set the access_type parameter to offline in the initial request to Google's authorization server.
There are a lot of things which can cause a refresh token to expire.
you are using a gmail scope and the user changed their password.
it has not been used in six months.
the user has revoked your access in their google account.
If the user runs your app you get a refresh token, if they run it again you get a different refresh token, you can do this up to 50 times and get new refresh tokens and they will all work after number 50 the first one will expire. Make sure you are always saving the most resent refresh token.
your app is currently in testing and has not been set to published and has not been though the verification process.
Documentation link for expiration
We are integrating on our application the Office 365 functionality throught MSGraph rest api and we are currently getting trouble with the validation of Refresh Tokens, this is the response error code from the server on a invalid petition:
"error":"invalid_grant","error_description":"AADSTS70002: Error
validating credentials. AADSTS70008: The refresh token has expired
due to inactivity.??The token was issued on
2016-04-27T11:44:49.4826901Z and was inactive for 14.00:00:00.
This is annoying because we need the users to aquire their credentials again logging in on Microsoft servers.
Is there any option to avoid Refresh token being invalidated due to inactivity? Or to make longer this expiration?
Refresh tokens have a finite lifetime. If a new token (and refresh token) isn't requested before that time they will expire. Once this happens the user must re-authenticate.
If you need to have perpetual access to the account, you will need to manually refresh the token periodically. You may want to look at this article. It covers the basics of how v2 Endpoint works (and the various token lifetimes).
In most of my implementations I use a queue to handling refreshing tokens. I queue each token to be refreshed at 10 days. If it fails I resubmit to the queue. If it is still failing at day 12 I email the user to inform them there was an issue and they will need to re-authenticate.
UPDATE
Refresh token lifetime was recently changed to until-revoked. You can read about the change here
This is general OAuth (not AAD-specific): obtaining an access token is a 2-step process. The first step is to obtain an auth code which requires the user to authenticate. The second step is to redeem an access token and a refresh token from the auth code. This second step is purely programmatic, i.e. the user need not be present. The app can keep repeating the second step, i.e. redeeming a new access token and a new refresh token from the latest refresh token without the user even know about it.
Your app should schedule frequent 'refreshes' of the refresh token. You can do this at any time while the app is running.
If the user doesn't use the app for an extended period of time, like about 2 weeks (I believe), the refresh token would naturally expire. If you want to avoid that, you'll have to schedule a dedicated job to refresh the token.
Zlatko
Is there any way to use the graph api to find out when a page access token, or application token will expire?
Update: There is a new API endpoint to access information about an access token. You can find info here: Debugging Access Tokens and Handling Errors
https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN
input_token: the Access Token to debug
access_token: your App Access Token or a valid User Access Token from a developer of the app.
--
You should try to make sure that you store each token's expiration time along with the access token when you get it. For a page access token, that means storing the expiration time of the user access token. If you would like to manually discover expiration times for tokens you have today, you should use Facebook's Access Token Debugger tool. However, you should not be relying on expiration times alone -- in practice, many tokens will expire much earlier than their expiration time.
Application access tokens will never expire, unless the application secret key is reset.
Page access tokens last up to 60 days (5184000 seconds), but more importantly, they last as long as the user access token that was used to acquire them. So they will be invalidated as soon as the user that you got them from:
logs out of FB.
changes password.
deauthorizes your application.
Basically, when you lose the user's token, you will lose the page's token. Instead, you should retrieve page access tokens once per user access token. If you throw out a user access token, throw out the page token. You should not be trying to store page access tokens for any significant period of time. Instead you should get them as needed and forget them when a user's session dies.
To get a new page access token:
https://graph.facebook.com/PAGEID?fields=access_token&access_token=USER_ACCESS_TOKEN
Access Token Debugger
https://developers.facebook.com/tools/debug/access_token
Does not use the Graph API... but a very useful tool for manual debugging.
There is now an API version of the debugger tool.
See https://developers.facebook.com/docs/authentication/access-token-debug/
I would like to repeat this question for the current version of the API since I've come to a situation when Facebook doc clearly does not describe what is happening:
no expiry dates when requesting a new long-lived token with fb_exchange_token
no expiry dates when requesting debug_token information (expires_at = 0)
it does reply with an expiration date when redirecting the user to the auth page for the first time, but that does not help as I cannot extract the long-lived expiration date nor it will reply with this information for the second time
The debug tool here: https://developers.facebook.com/tools/debug/accesstoken says "Expires: Never".
Try this, it worked with me. Get the token with your app and paste it in the graph explorer as the token to be used for queries. Click on the info a see the expiration date.
example image
I hope it works for you too.
https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
From the page above:
Access tokens on the web often have a lifetime of about two hours, but
will automatically be refreshed when required. If you want to use
access tokens for longer-lived web apps, especially server side, you
need to generate a long-lived token. A long-lived token generally
lasts about 60 days.