A session token is given to the user when he starts running a facebook application, as long as this token is not stolen, other people cannot impersonate him. To increase security, a new token is also generated again when it has expired or has been cleared.
So what is the problem here? Why do people want infinite session token in facebook?
How is it useful to both developers and end-users of facebook applications?
It's now called "offline_access". You're right in that most applications don't need this permission; however, occasionally an app may want to do some processing on behalf of the user while the user isn't present. For example, there are some blogging apps like posterous.com that allow you to email your blog posts - and they may want to publish without asking each time. For those, it's appropriate to ask for the extended perm.
Here's more information about how to request the permission:
https://developers.facebook.com/docs/guides/policy/examples_and_explanations/Extended_Permissions/
Why do people want infinite session
token in facebook?
So that when they exit their browser and restart it, they don't have to type in the username and password again. The authentication is still there so they can just simply start facebooking.
Related
My current application access one of the Google APIs using "3-legs" OAuth 2.0. User authorizes the app on Google consent screen, then the app requests API on behalf of the user and shows him some fancy data loaded from API. Everyday my application loads and transforms data from this API, so when the user comes next time, he sees the most relevant and actual data.
Everything works fine on the start, but as time goes, I faced two problems:
1. Query limits.
2. Token lifetime.
My question is dedicated to the second one, that I refer as "token lifetime". After some amount of time, the access token expires, and when user comes back to the app, our app obliged to send him to consent screen again. Moreover, all the time while access token has been in expired state, my app cannot load relevant data for user.
How can I solve this problem? How to continue lifetime of access/refresh tokens? Would Service account help? Would Service account work for Google Search Console API for every user, or should the user be a G Suite user inside my domain or what?
These questions are completely unclear from the official documentation here and from the Search Console API documentation.
If you have past experience with Google's APIs, please help me!
Thank you
When you use OAuth with user-consent, you do not need to prompt the user for consent repeatedly.
[a] If your usecase is entirely online and you want to be able to request a token each time the user visits your app, use the Google Sign In library or see this documentation for client-side apps.
[b] If your usecase is that you want to be able to obtain access tokens even when the user is not present, then you need to request an authorization code and store your refresh token. Your refresh tokens are longer-lived tokens and can be exchanged periodically for access tokens.
In the documents of Google One-Tap sign in, it says:
Returning users are signed in automatically, even when they switch devices or platforms, or after their session expires.
Question 1:
But it doesn't say anywhere how it does this? Is the user refresh token saved in the browser's cache? How can it then auto log in a user cross devices?
Question 2: The reason I ask is because I have a setup where I initialize the Google API client for JavaScript ("GAPI"). The GAPI library also automatically logs in a user whenever the client is "initialised" through gapi.client.init().
Now the problem is that after I have added the Google One-Tap code (Or should I say "YOLO code"? : ) my user gets logged in through One-Tap and also through GAPI. I can prevent this by not initializing the GAPI client, but I don't think that's wise, because I thought this whole library is built to manage my refresh tokens etc. Is my understanding correct that One-Tap does exactly the same and in case I only want to Authenticate users I do not need the GAPI client anymore?
Really, which library does a better job at managing my refresh tokens? And how do they differ? I'm clueless...
The way I implemented my login is the following:
Try to login in the user first using gapi.auth2. Maybe the user was previously signed into the site.
If can't login user automatically, then use googleyolo to try to find existing user accounts.
If no existing accounts, then present a signin button for user to signin.
I can give you some code snippet if you need.
To answer your questions.
#1, the credential is stored within the browser/device. If the user has never signed into google in a device, then yolo won't be able to sign in the user.
#2. googleyolo will also login the user, the difference is that it will give the account selector even if there's only one user to select (it will automatically login the user if there's only one). gapi simply sign in the user without showing anything.
there is a service where one can authorize using their Google account.
I need to automate the workflow with that service, so my software has to log-in with a given Google account.
But as I've never done that before I don't know where to start. Most related answers suggest to display the authorization page to the user letting them to enter their login/password of their Google account, but that's not the case since my software must be fully automated, plus it is being ran in terminal mode so no browser neither any human to enter anything should be involved.
I wonder if such automation could be possible and where should I start.
The standard way to authenticate a user with google is through a three-legged oauth authentication flow (in a browser). You can do this in go using the oauth2 or with a more comprehensive package like goth
The general flow is:
redirect user to a landing page on google's site where they are prompted to grant you access.
google will make a callback to your site with a special code.
you make another request to exchange that code for an access token and a refresh token.
Use access token to use google apis, and use refresh token to get a new access token anytime it expires.
It is more detailed than this, and there is a lot to get right to keep it secure, but that is the general idea.
Now, like you've said, your app is a command line thing, so it is hard to do that flow. Unfortunately, you may need to do that once, just to get a refresh token. Once you have that, you could give it to your application: myapp -google-token=FOOBAR123, and your app can exchange the referesh token for a valid access token.
Maybe this will help: https://github.com/burnash/gspread/wiki/How-to-get-OAuth-access-token-in-console%3F
We are building a finance app and integration Yodlee in it and we have come to situation where we need user's loging.
Now we have two scenarion,
Ask user to login & use token for API call. But as userSessionToken expires after every 30 minutes, we need to open yodlee login screen.
We can register yodlee user when any user sign-up on our site and use his credential from back-end to get yodlee userSessionToken
Scenario 2 has data protecting issue. Is there any way where we can get new token with a single user login.
Please suggest me if there is any alternative way.
You should use second approach, as you don't want user to register twice.
Once user registers to your site you should internally call register3 API to register that user with Yodlee. There is no data protecting issue, unless you don't have required security standards in place.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.