I am using passport-facebook to obtain an access token. According to here
https://developers.facebook.com/docs/marketing-apis#access-token
under "Get Access Token", I should be getting a 60 day long-lived token. This is the case if the scope is only ads_read. However, when I add additional scopes of manage_pages and read_insights, there is no expiration when I check via the Graph API.
This seems to be a bit contradictory to me. My theory is based on the getting an API key with ads_read permission manually from the below tool.
https://developers.facebook.com/apps//marketing-api/tools/
Using this tool and debugging it via the Graph API, I see one difference in that it the manually generated access token has the "Page" row under it, indicating that it is a page access token (to my own pages). Since it is a PAT, it will never expire, as expected.
My passport-facebook generated access token has the ads_read, manage_pages, read_insights permission as well and the expiration says "Never Expires". However, it does not have the Page row on it. Does that mean I can still use it forever to query the ads insights API?
This is my attempt at obtaining a non-expiring Marketing API access token.
Yes, if the expiration row says Never expires, you can continue to use the token for querying ads insights.
On a side note, is you generate system user access tokens, they also never expire. You can read more about it here - https://developers.facebook.com/docs/marketing-api/businessmanager/systemuser/v2.8
Related
I'm building a website that integrates Instagram Basic API to show my media posts. So far, I managed to authorize via
https://api.instagram.com/oauth/authorize?client_id=X&redirect_uri=X&scope=user_profile,user_media&response_type=code,
fetch a short-lived access token via https://api.instagram.com/oauth/access_token?client_id=X&client_secret=X&grant_type=X&redirect_uri=X&code=AUTH_CODE_RECEIEVED,
fetch a long-lived access token (as per the response I receive) via https://graph.instagram.com/access_token?grant_type=ig_exchange_token&client_secret=X&access_token=SHORT_TOKEN_RECEIEVED,
and lastly, show my media posts via https://graph.instagram.com/me/media?fields=id,caption,media_type,media_url&access_token=LONG_TOKEN_RECEIEVED.
However, the problem I am currently facing is that the obtained long-lived access token - which is meant to be valid for 60 days? - is expiring per hour or so. Meaning, on client-side, when I'm requesting the server to fetch media posts, using the token, the response returns with expired token exception.
I tried to use FB Access Token Debug Tool to check the token validity, and it shows that the token does indeed expire in about an hour. Why is this happening? I checked the response I'm getting from the long-lived token API, and it's a success with the token, grant_type, and expires_in fields.
Below is the screenshot of the debugger result.
.
What I'm trying to accomplish is rather straight-forward. Generate a long-lived access token that "should" be valid for 60-days use on server side. Then, I'll have to automate the token-refresh process afterwards. Any suggestions to the above issue?
Thanks in advance.
Regards,
Moh. Bokhari
The difficult part is getting a short-lived access token first; I found this useful page which explains step-by-step with screenshots on how to get a short-lived access token.
The link to the website
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
i am building a prototype to prove deriving user playlist etc. from Spotify.
As this is user information, i've to use Spotify's authorization code workflow (refer https://developer.spotify.com/web-api/authorization-guide/#authorization_code_flow)
In this workflow, an application requests user to grant scoped privileges so relevant information can be pulled out.
In the series of calls that follow:
call to /authorize
calls back a redirect_uri sent in request and sends in a code
e.g.
redirect_uri=../abc receives ../abc/callback?code=xyz
as is exemplified in docs.
xyz is then sent over to /api/token to get access_token and refresh_token
Is there any way one can avoid to repeatedly invoke /authorize after once the grant has been given by user?
In-effect, can i not treat the code (from /authorize) like an oauth token and preserve it (say in database) to get a new access_token every time i need one? (as a direct comparison check facebook's oauth token that can be saved and reused to authenticate every next time)
How can i remember a user has already granted me access to his/her Spotify profile and data?
Please indicate if i am missing something obvious from documentation. please point me right if this has been specified elsewhere.
many thanks!
For this use case you can use the Authorization Code flow. What you should persist is the refresh_token it returns, which can be used to obtain access tokens. You can also optionally persist the access token, that you can use during one hour, so you don't need to obtain a new access token every time.
There is a FAQ in the Authorization Guide that talks about a similar scenario, where a user would want to manage her playlists without having to go through the login process every time:
You basically need an access token and a refresh token issued for your user account. For obtaining a pair of access token / refresh token you need to follow the Authorization Code Flow (if you need a certain scope to be approved) or Client Credentials (if you just need to sign your request, like when fetching a certain playlist). Once you obtain them, you can use your access token and refresh it when it expires without having to show any login form.
there seems to be some conflicting advice on how to get an access token from a refresh token:
This SO answer says passportjs doesn't get involved with refreshing the access token and it should be done via cron job:
Refresh token in Passport.js
This SO answer says "No need for any cron jobs...when the user requests data from the API using an access token that has expired, this should trigger your framework to fail, renew, then retry."
OAuth 2.0 - When should an access token be renewed with refresh token?
What's the simplest way to ensure we're always giving Google a valid access token? Right now, we're just storing the refresh token in the database and never using it, which forces users through the "allow / deny permissions" flow every time their access token expires.
There are a few approaches. One is to just detect when the access token fails (with 401 I believe) and then refresh it and re-use it. However, most of the APIs that yield access tokens also tell you their expiry time, so you can just remember that and, when you’re about to use, if it’s less than say 10 min before expiry time, refresh then. If all else fails you could use the tokeninfo endpoint when you get a new access token, to find out its lifetime.
We have a standalone Java application (see "Installed application") which runs periodically and uses Google API (updates some information from customer databases/ldap/...).
To access Google APIs we store username and password in configuration file, which is a security risk and customer does not like that. So we would like to use OAuth2 long-living access token instead.
What`s default expiration time for Google OAuth2 access tokens ?
As we will have only access token in application, app itself cannot refresh it when access token expires.
Personally I think that OAuth2 implementation in this case will not bring any major benefit but let`s focus on main question - default expiration times.
You shouldn't design your application based on specific lifetimes of access tokens. Just assume they are (very) short lived.
However, after a successful completion of the OAuth2 installed application flow, you will get back a refresh token. This refresh token never expires, and you can use it to exchange it for an access token as needed. Save the refresh tokens, and use them to get access tokens on-demand (which should then immediately be used to get access to user data).
EDIT: My comments above notwithstanding, there are two easy ways to get the access token expiration time:
It is a parameter in the response (expires_in)when you exchange your refresh token (using /o/oauth2/token endpoint). More details.
There is also an API that returns the remaining lifetime of the access_token:
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token={accessToken}
This will return a json array that will contain an expires_in parameter, which is the number of seconds left in the lifetime of the token.
The default expiry_date for google oauth2 access token is 1 hour. The expiry_date is in the Unix epoch time in milliseconds. If you want to read this in human readable format then you can simply check it here..Unix timestamp to human readable time