I have to admit the process of renewing an expired token at the server-side, because the FB user has logged out, confuses me. The solution to handle expired tokens, as presented on this page, would only seem to work if the user was viewing a server page that could prompt said user to re-authorise the app (JS location.href redirection to a FB dialog URL).
What if a server side app has saved the access token because of some processing that will take some time first? If after some hours/days the server wants to post something to the user's wall, using the either the short or a long term token, but the user has logged out of Facebook - what then? Sure, the request will fail because of the logged out status of the user, but this seems to me to also mean the server will have no valid way of posting to the user's wall until they log back in to Facebook (and the app happens to try to post again at the right time).
Am I right here or missing something obvious? Seems a crazy scenario to prevent a server-based application from posting to a pre-authorised user's wall just because said user has logged out (which i'm sure many, many users do on a regular basis). Why does logging out == deauthorising the access token? And, if the user logged back in, does the existing access token become valid again, or is a whole new token required (assume we have obtained a 60 day token)?
Why does logging out == deauthorising the access token?
It doesn’t. A long-term access token doesn’t get invalid just because the user logs out of Facebook!
So get a long-term one, valid for sixty days – and you’re good to go to post or do whatever a few days after requiring the token. If the 60 days are over and the user hasn’t interacted with your app since, then you have to have the user come back to your app to get a new token.
Related
I used the token generated by my authentication server to sign my users in using signInWithCustomToken(token). Now what I cannot figure out is if they sign out, how will I sign them back in ?
I don't think saving the generated token in the database is a good idea because then I am going to have to give it public access so the user can access it.
Any ideas ?
If the user signs out. You have to go through the same mechanism you used initially to generate the custom token. Do not save the custom token. Besides it is only valid for a short period of time.
One example is if you are using our own username/password auth system. You ask the user for the username/password, verify it in your own server and then issue the custom token back to the client, client calls signInWithCustomToken and user is signed in. If the user signs out, you have to repeat the process.
We are using calendar API of google and it's working fine and we have achieved almost each requirement.
But we stuck at below point,
How to generate new "Refresh Token" once it's revoked or expired?
Also I need more information on when "Refresh Token" expire and how would I know the life of this refresh token, so I can automatically create new before it expired?
Any answers is highly appreciated.
You may want to check this related SO post, refresh token doesn't expires unless the user revokes it. Until it does, your app must catch this issue then ask the user for permission in order to avoid encountering such problem. Here is the link for the documentation of Google:
Save refresh tokens in secure long-term storage and continue to use
them as long as they remain valid. Limits apply to the number of
refresh tokens that are issued per client-user combination, and per
user across all clients, and these limits are different. If your
application requests enough refresh tokens to go over one of the
limits, older refresh tokens stop working.
If you'll continue reading until Token expiration:
You must write your code to anticipate the possibility that a granted refresh token might no longer work. A refresh token might stop working for one of these reasons:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
Hope this clarifies your concern.
I'm using Google Sign-In. A user comes to my site and logs in with gapi.auth2.getAuthInstance().signIn(), or they are already logged in and when the page loads (or reloads) we fetch the status. At this point I have an identity token good for an hour that I can validate on the server.
When a user leaves the browser sitting (say, overnight), this token expires. gapi.auth2.getAuthInstance().isSignedIn.get() returns true, but the token does not validate.
How can I log in a user and keep them logged in while their session is active (ie, browser hasn't been closed)? Or refresh the token? Anything more graceful than reloading the page...
Edit: The refresh token is not a correct answer; I don't want offline access (and don't want to ask for the permission). Google obviously thinks the user is still signed into my application; the user can reload the page and get a new token without providing credentials again. Surely there is some mechanism more graceful than a hidden iframe to get an updated token?
If the token is expired, you can call gapi.auth2.getAuthInstance().currentUser.get().reloadAuthResponse(). It returns a Promise.
I've raised an issue with Google over this because it's simply ridiculous they haven't documented this properly.
My comment here advises how I've accomplished refresh using the above.
FWIW, we've managed to (mostly) make it work via a listener approach. It appears that 'userChanged' callback is invoked ~5 minutes before the access token expires. That's enough for us to extract and update the access token without refreshing the page.
What does not quite work though is when computer comes back from sleep. This can be solved relatively easy by reloading the page on wake up.
You can accomplish this with listeners.
var auth2 = gapi.auth2.getAuthInstance();
// Listen for changes to current user.
// (called shortly before expiration)
auth2.currentUser.listen(function(user){
// use new user in your OpenID Connect flow
});
This will allow you to keep current credentials, as long as the browser remains active.
If the computer is put to sleep additional work must done to get current credentials.
if (auth2.isSignedIn.get() == true) {
auth2.signIn();
}
You can use Refresh Token to get offline access. As per the official reference
Access tokens have limited lifetimes. If your application needs access to a Google API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
Basically you will get the refresh token the first time you ask for authentication. You need to save that token securely for future use. The access token (you mentioned as identity token) expires after an hour. After that you have to use the refresh token each time you want to get a new usable access token.
Depending on the client library you are using the syntax will differ. following is a sample for php client library.
// get access token from refresh token if access token expire
if($client->getAuth()->isAccessTokenExpired()) {
$client->refreshToken($securelyPreservedRefreshToken);
$newToken = $client->getAccessToken();
}
check this for details steps.
I am configuring Azure ACS with "Google" configured as IdP in my application. My requirement is that I do not want the IdP login page to be displayed every time I try to log into my application. I have set my ACS token lifetime to the maximum period so that my token is valid for a day.
First time when I log into my application and I select "Stay Signed In" in Google login page, I am able to log into my application. I now close the browser, reopened the application, I am successfully rediercted to the application home page without any credential request. (as ACS internally uses the session token created intenally which will be used in next requests)
But if I do not select "Stay Signed In" in IdP login page, and proceed the same steps, I am asked for credentials. Any idea why is this happening? Is there a way I can manipulate the session token and validate the ACS token which was earlier issued to me ?
When you select "stay signed in" at Google, it writes a persistent cookie, meaning that you'll stay logged in even if you close your browser. By default, your application's cookie is scoped to the session (assuming you're using WIF). When you close and reopen your browser, the original token and cookie are gone. Your browser redirects to ACS, which redirects to Google, which redirects you back again because of the persistent Google cookie. Running your session using Fiddler or HttpWatch should show that, even when you choose "stay signed in", you're still being sent back to ACS and Google and getting a new token.
It sounds like what you want is your RP to "remember" the user so they don't have to log in again within the token lifetime. To do this, your federated cookie (the one with the token in it) needs to be set as persistent, rather than session. If you're using WIF, this can be done using CookieHandler configuration on the FederationAuthenticationModule (see PersistentSessionLifetime).
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/