I wonder if there is any chance to dynamically switch between Google accounts after user signs in to a couple of them on one site. The flow would be like:
log in to account A
save token received from gapi for account A
log in to account B
save token received from gapi for account B
...
do some operation with API (e.g. youtube) as account A using
previously saved token
do some operation with API (e.g. youtube) as account B using previously saved token
...
I've described the problem of the setToken method in my other post setToken doesn't switch YouTube channel in Google API (gapi). However I want to handle all of it only on the client-side like this. Is there any chance to do that?
Related
Is there a way to automatically authenticate the google javascript api client, without user interaction?
Something like this:
User loads webpage -> webpage automatically signs in into a predefined user account -> api calls get executed
Basically i want to prevent the popup where you have to select an account and sign in to it. As the account which will be signed in is always the same.
EDIT:
pinoyyid answer looks promising and is what im looking for. But this only works if the user has signed in with an account at least once, if im not mistaken.
Now i dont want to use an account supplied by the user, but a predefined account which i am the owner of and sign this account in.
Im not entirely sure if this is even possible, as i have to provide the password/some authentication code to google and somehow do this in a secure way.
Use Case: The website will create a Youtube Broadcast via the Youtube Data/Livestream API for the specified account.
Yes you can do that. Referring to https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
there are three pieces of information that will get you where you want to be:-
The OAuth URL can include a login_hint which is the email of your intended user
The OAuth URL can also include prompt=none which will do its work silently
This all needs to run in an iframe because this is based on origins and redirects.
==EDIT==
If the requirement is for a browser client to connect to a Google Account other than that of the browser user, then this is not possible. It's kinda obvious really that to do so would require a credential in the browser which by definition is not a secure environment.
The approach I would take would be to use a service such as Lambda or Google Cloud Functions (or whatever marketing name they have this week) to create a proxy for the corresponding Google API using a credential stored server-side.
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.
I'm trining to create live stream on youtube using google API. Now it working only when I use oauth authorisation. When I use API key authorisation I get authorisation error (login required)
When I use oauth authorisation - it require to enter confirmation code each time I create new translation. Is it possible to use "liveStreams->insert" method of API with authorisation that does not require entering of confirmation code?
From what you are writing it appears to me that you haven't understood the concept of OAuth and when to use OAuth vs an API key.
Try to think about it this way: You, as a person, have a Google account. This Google account is not the same as your YouTube account (or, as it is more commonly refered to, your YouTube channel). But your Google account is associated with your YouTube channel (of which you can have multiple). Because you are logged in to your Google account and your channel and Google account are linked, the YouTube website knows who you are and gives you access to your channel.
Now you head over to the Google Cloud Console. Here you create a project, which is very similar to a YouTube account in the sense that it, too, is an independent account which in this case represents your app, but is linked to your Google account so the Cloud Console website knows to give you access to the project as long as you are logged-in to your Google account.
HOWEVER, your YouTube account is not linked to your Cloud Console project. When you make an API request with an API key, the API does not see you as in "your Google account", but rather your apps's Cloud Console Project. That's why with an API key, you can only access publicly available data (everything you could "see" when you browse YouTube while not being logged-in).
So, in order for an application to read private channel information or modify channel information, the API needs verification that whoever makes that request is actually allowed to do that. This is where OAuth comes into play.
When you say you have to provide the confirmation code for each request, I think you don't save the access token and refresh token. I highly recommend you read Using OAuth 2.0 to Access Google APIs and Obtaining authorization credentials over on Google Developers to help get you started.
I'm developing an application that utilizes Google sign-in and the Gmail API. My test users, once logged in, keep receiving an email like the attached file.
Other applications with similar functionality (basic email access) do not seem to trigger these emails. Any ideas? It makes my app seem less trustworthy.
One possibility is that you are obtaining tokens with offline=true indicating a requirement to use the refresh token to renew expired access tokens. If you only require short-term access, perhaps you should remove the offline parameter in the construction of your auth request link.
In this scenario once the access token expires, then the scope will no longer be usable or renewable and so your end-users should not receive the alert emails.
We are using the refresh token to get Google Calendar free/busy events. When our application connects with Google account of a user for the first time, we obtain a "Refresh Token" and store that in our database and use that for fetching free/busy events from Google. Things were working fine but now the problem is that whenever a user changes its Gmail password then we're unable to call the Google Api using the stored refresh token. The reason we've have found is that Google revokes the Api access for all applications associated to that account on password change/reset. In our application, calendar is still connected to Google (because we do not make call to reconnect with google again). How can we check/identify if the stored Refresh token is still valid or not? Is there any suggested workaround for this problem?