I've just realized that if I log out from facebook.com, the access token in my app is no longer valid (fbSessionInvalidated gets called).
I don't understand why logging out from the Facebook website would invalidate the access token in my app. Is this normal behaviour, and if so why is it happening?
it's normal, you need to ask a offline token.
But be carefull Since 2nd of may.
This is in place http://developers.facebook.com/roadmap/offline-access-removal/
I just enabled "Remove offline_access permission" in my app's advanced settings and this problem is fixed (I also get 60 days access tokens now).
Related
I had a couple of followup questions in reference to the answer:
Does the user access token obtained using OAuth flow expire in a given time period by default? It does mention here that they never expire but wanted to confirm once.
Authorization codes required to get user access token expires in 10minutes after issuance. In such a scenario user will have to be redirected again?
If the user either uninstalls the application or revokes the token and say decides to reinstall the application later.
In this scenario is the user access token now different from what it was before the app reinstallation?
Correct, access tokens don't expire unless you have enabled token rotation.
Yes, in that case the user would have to be redirected again.
Yes, once a user uninstalls the app and the token is revoked, that token will never be useable again. When the same user re-installs the app a new access token is provided.
i have a very weird problem. I'm using the Google authentication API since moree than one month now and all working perfect. But now out of the sudden, my users can't get refresh token anymore. My app is on testing state, so i thought the refreesh token my testing user was having is expired after 7 days, but then i tried to get another refresh token by doing thee authorization from the beginning to receive a code that i use to get a refresh tokn. But no chance i'm only receiving this response back: Status code 400 { "error": "invalid_grant", "error_description": "Bad Request" }
Thank you very much for your help!
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.
To stop your refresh tokens from expiring set it to production.
Why cant you refresh after seven days
What i am writing here is my opinion only from experience. There is no documented proof of any of this from googles side.
After seven days your refresh token will expire, but the question is how is google expiring these refresh tokens. From what i can see they are not using the normal method of expiring the refresh token. They are in fact revoking the users granted access on the google account. So the all of the refresh tokens granted will stop working at once.
So why are you having issues with the client library. Normally the way the client libraries were originally designed. if the refresh token expired it would prompt the user to authorize the app again. This does not happen with the seven day revoke method. IMO because the error message is different, and the libraries have not been updated to take this into account, and prompt for access again. The only way to fix it is to delete the old stored refresh token and request a new one.
So your not able to receive new refresh tokens because your code is stuck with the old one. Make sure to hard delete any old refresh tokens you have stored. They wont work and the library doesnt understand how to delete them on its own.
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
Starting from the point where an user has given permissions to the app, and the access token is stored in session. Following Google's web server app example, I'm just checking whether an access token exist.
However, the token might expire, or the user might remove it manually on his account page. How do I check that the token is still valid, before executing a request?
Or maybe that approach is wrong, and the correct design includes that I should handle the error after executing the action, and if it's an authorization error then show the user a way to authorize it once again?
The latter is the recommended approach. By assuming failure and dealing with it routinely, your app is much more robust. The only downside is that an access attempt takes a bit longer because of the need to fetch a new Access Token and retry. If that's a problem (it shouldn't be normally), then you can always note the expiration time of the new Access Token and set up a background process to renew it with say 5 minutes to spare.
I've been building an app (ios and web app) on Parse over the last few months and have only just discovered how their session tokens work. This is what I have learnt so far:
Each user has their own session token
The token is used to replace the user credentials (for authentication) when making requests to the server
The token never changes (even when password is reset) and never expires
The token is stored locally on client side when logged in
User can be logged in using the Parse.User.become(sessiontoken, options) method, with only the session token
This seems very insecure to me, or am I missing something? It seems that if anyone manages to get this token they have eternal access to the users account, even if username and/or password are changed?
Thanks,
Mario
Looks like they have just updated their systems to use revocable user sessions. Nice one Parse!
http://blog.parse.com/2015/03/25/announcing-new-enhanced-sessions
I have also double checked the session token returned from REST API & Android Client. It is the same. Even after I changed the password.
This is definitely a potential security issues. Anyone who's mobile device is stolen, the hacker could get the session token if the session is not encrypted and the security of user data is in jeopardy forever.
As the hacker could use the session token from any client forever. You will never know when the hacker will do the evil.
I am seriously concerned about the issue. Hope somebody will address it.
PS: Hi Mario, I have logged an issue on the Facebook Developer Platform.
https://developers.facebook.com/bugs/309490399239393/
Hope somebody will track it and resolve it eventually.