Based on this link
"Authenticating as the Account Owner
Many applications simply want to perform actions on behalf of the account owner. You can do this using the standard OAuth flow, except that you won't need to request an access token. Instead, visit your account details page, and grab the Access Token. This is a special access token which does not expire, and will authenticate you as the application owner."
For the life of me, I cannot seem to find the account page which holds access_token, is there anything I need to do first before seeing it?
It's not that obvious, but go to this page: http://disqus.com/api/applications/
Then click on your application title, which will bring you to the details page. The owner access token is at the bottom of that first page after you click.
Related
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
Is it possible for me to create an application that can send our requests to access to users' Google Calendar so that I can see the events in there and be able to add, edit, and delete events?
I do not want the users to log into my website to enable this access. Rather, I want to be able to send this request, perhaps via email.
Alternatively, perhaps they could log in the web app and authorize access themselves somehow.
One option would be to e-mail the user a link to the OAuth 2.0 consent screen. The users would still need to open the link in a browser, sign in to their Google account (if not already signed in), and click the "Authorize" button to grant your application access to their Google calendar events.
First, you will need to register your application as a Web App in Google's Developer Console (just like for any other application) and obtain a client_id. Be sure to fill in the name of your application and a link to your website in the "OAuth consent screen" section, because these values will be shown to your users when they click the authorization link.
Then, follow these steps:
Send the user an authorization link in an HTML e-mail message. The link should be constructed according to the guidelines in "Redirecting to Google's OAuth 2.0 server", and pay attention to the following aspects:
Ensure that the redirect_uri parameter in the authorization link points to your application.
Since you already know the e-mail address of the user, consider including the login_hint=<email address> parameter to bypass the account selection screen.
Important: provide a value in the state parameter so that you can link this authorization request with the user.
The link should be placed in an <a> tag somewhere in the body of the e-mail: Allow access to my Google calendar
When the user clicks on this link, their browser will open and show the standard Google consent screen:
Once the user has made a choice, their browser will be redirected to the redirect_uri which you have provided.
Make sure that the redirect_uri will work even if the user isn't signed in to your application. Capture the state and authorization_code values which Google appends to the redirect_uri, and then return a confirmation page (e.g. "Thank you for giving us access to your Google calendar" would be a good idea).
Using the state and authorization_code values, follow the rest of the standard OAuth 2.0 flow and retrieve a refresh_token which will allow you to access the user's Google calendar from your application.
Keep in mind that the calendar owner (the user who is clicking the link in the e-mail and granting your application consent to access the calendar) may not even be a user of your application. This is why it is important to provide as much information as possible on the consent screen and in the confirmation page.
Since your confirmation page will be loaded even if the user does not grant your application consent, you could take the opportunity to give the user a full description of why you are asking for access to their calendar and provide a link that will take them back to the consent screen. This should increase your success rate.
Every request your application sends to the Google Calendar API must
include an authorization token. The token also identifies your
application to Google.
Your application must use OAuth 2.0 to authorize requests. No other
authorization protocols are supported. If your application uses
Google+ Sign-In, some aspects of authorization are handled for you.
The details of the authorization process, or "flow," for OAuth 2.0
vary somewhat depending on what kind of application you're writing.
For more details on the workflow to gain access click here. Once your app has access, it will be able to view and edit a user's calendar events, depending on the approved permissions.
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.
I have an Web application that uses Google Drive. In order to make it easier for user to integrate his account (in this web application will be easier for client this way), I would like to have two links for authentication:
A link with the current user email that sends the user to the authorization page.
A link that automatically logout the current user from Google (if any) and send the user to authorization page (in this case the login page).
In order to accomplish that I need:
- the current Google user email
- logout current Google user
I really think this is not possible, but is it possible to me do this actions before have my application authorized by user?
You will only be able to pull a user's email address after they have authorized you to do so, so that isn't possible.
You can use OpenID to retrieve a user's email address or redirect them to the Google login page if they aren't logged in. They have to authorize your application, though, so you won't be able to direct them to different places until after they've signed in. There are details on the login flow at https://developers.google.com/accounts/docs/OpenID#Interaction.