I have get Facebook permanent access token. And check it in access token debugger. Here i can see that it shows "Expires :Never " and "Data Access Expires : 156*632** (in about 3 months)" . Here expire(never) is OK, but what does it mean by Data Access Expires (in about 3 months). Does it means data access fro 3 months or anything else. If yes then what's the meaning of Expires (Never).
Related
After doing some research in using JWT with Access Token and Refresh Token for authentication. I understand this in this way.
After login, return to user Access Token and Refresh Token (using same technique JWT for both).
Saving Refresh Token in Database (one User can have multiple Refresh Tokens for multiple devices).
Whenever user sends a request with invalid Access Token, check Refresh Token and call another api to get new Access Token (doing this in client side). After that, call api to get data again with new Access Token.
If Refresh Token is invalid, deleting its record in database and user must to login again to get new Refresh Token.
Does I understand Access and Refresh Token technique correctly? Please give me some advices. Thank in advance.
Of the 4 steps you listed, some look more or less correct while others do not. I will begin this answer by giving the premise for why refresh tokens were created and what is their main purpose.
Using the JWT pattern with only access tokens, there is a potential usability problem when the JWT token expires. Consider as an example a banking website. When a user logs in, he receives a JWT token with a certain expiry (typically stored under the exp key in the claims section of the token). If the token is given say a 5 minute expiry, then from a usability point of view, it means that the website would have to force the user to manually login every 5 minutes. Obviously, this is not the best user experience, because it means that a user who happens to be in the middle of some business process when the token expires might lose all that work. This is where refresh tokens step in to alleviate this problem.
Using the JWT pattern with refresh tokens means that the user receives both an access and a refresh token. A typical workflow here might be:
After login, return to user Access Token and Refresh Token (using same technique JWT for both). The receiver notes when the access token is set to expire (say 15 minutes).
As the expiry of the access token approaches (e.g. 10 minutes), the UI will send the refresh token to the backend to obtain a new access token (and refresh token). This could be done explicitly, e.g. on a website which displays a popup asking if the user wants to continue. Or it could be done in stealth mode, with a REST call being made under the hood to get the new access token.
For the edge case where the refresh token cannot be used to obtain a new access token, then the very next user action which requires authentication would fail. In this case, the user would have to redirected to the login page. But, as this case should generally be rare, it does not disqualify the refresh token pattern.
I would also point out that storing the access/refresh tokens in the database largely defeats the purpose of the JWT pattern. One major reason for using JWT is that it pushes the user session state out of the application and onto the user. By storing tokens in your database, you are totally making your user sessions very stateful, which has all sorts of potential drawbacks. Consider using the suggested workflow above to avoid doing this.
The way I see it, your refresh token needs to be stored and associated with the device and the user.
Example:
User Logs In in Device A
Call Login endpoint
Validate user is valid
If valid, generate a refresh token associated with the userid & device
id
store required data to your table or storage engine (user_sessions..etc)
user_id | device_id | refresh_token | expires_at
Return the payload with access_token, refresh_token , access_token_expires_at, refresh_token_expires_at
Front-end, store the payload
when consuming a resource, check the following
If refresh_token_expires_at > now then logs them out , show your session is timeout (or you can have a never expired refresh_token.. ex. refresh_token_expires_at can be 0)
if access_token_expires_at > now then call refresh token endpoint along with your payload.
on the refresh endpoint, validate the call and check the refresh token against the data stored.
if refresh token is valid for this user+device, generate a new access_token
return the access_token and its expires_at
If the refresh token is INvalid , return invalid
front end will log the user out.
** in any case, if a refresh token was compromised, it will be only for that particular device/user. A user can then deactivate or remove the device from their list. This action will invalidate the refresh_token on their next refresh call.
I have access token that should be valid for 10 hours, but it expires after 30 minutes. I use it to call Keycloak rest api and it works for half an hour, but after that I get 401 - Unauthorized. I decoded it on jwt.io and exp claim is 10 hours after I aquired it. I checked system time and everything seems fine. What could be the problem?
Since you have not shared your config, I am assuming you are setting "Access Token Lifespan" as 10 hours (same is reflected in your jwt as you mentioned).
To avoid the login again and again, you need to set SSO session time as 10 hours. (See 2 and 3 highlighted in below image.)
Now coming to access token, if you are using a browser to test your api, you can set it to any value less than your SSO session value. As the session cookie will be automatically handled by the keycloak.
However, if you are using PostMan or other client to test your API and want to use same token for 10 hours, then set you access token also to 10 hours.
For more details, refer: https://www.keycloak.org/docs/latest/server_admin/#_timeouts
Although I don't know the procedure, I know that it's possible to use the same token to:
list all the ad accounts under your user
Get ads performance information for each campaign
Plus the token is not a short-live token (doesn't need to be refreshed every 24 hours)
I tried generating a long-live token using curl, as described in this Facebook developers support page in the following manner in bash:
curl https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id=$client_id&client_secret=$client_secret&fb_exchange_token=$fb_exchange_token
but got the response:
"error":{"message":"Missing client_id parameter.","type":"OAuthException","code":101
If the long-live token I am trying to generate is the correct approach: What am I doing wrong?
If not, how do I retrieve that token?
I can see the client_id parameter in your url. And you also have & character in your url. If you do not wrap the url with quote " or ' then it will break the command at & character. Which means, your command has executed as below, hence missing client_id:
curl https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token
Correct approach should be:
curl "https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id=$client_id&client_secret=$client_secret&fb_exchange_token=$fb_exchange_token"
The same token can be used for ad accounts and ads performance if it a long-live token, or a lifetime token.
lifetime token can be achieved by making another request with the 60 day token.
Execute the following curl to get the long lasting (2 months) access token:
curl "https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id=$client_id&client_secret=$client_secret&fb_exchange_token=$fb_exchange_token"
Where:
client_id - App ID
client_secret - App secret
fb_exchange_token - The temporary token.
Note: Make sure that you are using a temporary token that was created within the last 12 hours
Lifetime token
Paste the Long lasting access token in FB Graph API Explorer with the address
/me/accounts
Use one of the tokens shown there.
After reading the document of Quick Book Online API,i have some questions
1.In order to authorize in quickbook online,i implement ConnectToQuickButton.When i click this button,i get access token & access token secret & save in database.i also get 180 days expire limit.if i don't hide ConnectToQuickButton and press again the button after 50 days,i get new access token & access token secret.Is my 180 days limit initialize newly?
2.Is the above scenerio works after 150 days i.e on 151th day? ConnectToQuickButton button works on 151th day or i have to use Reconnect API?
3.On 181th day,Reconnect will not work,does ConnectToQuickButton work? or i have go through the quickbook flow i.e Signup,Create an app?
4.I access quickbook online data by Creating instance of DataServices.If access token and access token has expired what exception(ServiceException, SecurityException etc) i catch to see that tokens have expired.
Please let me know...
sabbir
Please refer - https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app
Re 1
Yes, you get a new set of tokens and those are valid for next 180 days.
Re 2
You should call Reconnect(this is mentioned in docs too). But C2QB will work as well.
from docs - Wait 151 days (this is now within 30 days of token expiration), call the Reconnect API to get a new token.
Re 3. On 181th day,Reconnect will not work,does ConnectToQuickButton work? or i have go through the quickbook flow i.e Signup,Create an app?
C2QB works in all scenarios. If you generate new accesstoken and accessSecret then old tokens get invalidated. New tokens will work fine.
Re 4. I access quickbook online data by Creating instance of DataServices.If access token and access token has expired what exception(ServiceException, SecurityException etc) i catch to see that tokens have expired.
You'll get 401 Authentication error.
Reconnect API ref
https://developer.intuit.com/docs/0025_quickbooksapi/0053_auth_auth/oauth_management_api#Reconnect
Thanks
If you exchange a short-term access token to extend it to 60 days using
https://graph.facebook.com/oauth/access_token?client_id=(APP_ID)&client_secret=(APP_SECRET)&grant_type=fb_exchange_token&fb_exchange_token=(AccessToken1ST)
When the access token returned from this (AccessToken2) is about to expire, can you use the original short-term access token (AccessToken1ST) to exchange for a new access token (AccessToken3)?
I would test it out, but it's just returning the same access token over and over, since access token 2 has not expired yet.
I know I could probably do this with access token 2, but I'm reading access token 1 from a certain file, since I am not logging in with a user, I just want to read public facebook data and would rather not have to manually update access token 1 ( since I don't have write access to it) and would rather just use access token 1 to generate access token 3 if it is possible.
You cannot exchange an expired token - but only a short-term access token BEFORE it expires.
Your languages indicates that you can exchange expired tokens, which defeats the whole purpose of expiring them!