The main use case is using IPython as CLI to my own Google accounts. What I am really after is minmizing the fussing around between starting the IPython shell and actually issuing usefull calls against the API.
The docs for authenticating with Google APIs focus on setting up application which other user will use to access their data.
This leads to a lengthy Oauth dance involving a browser in order to allow other users to authenticate without compromising their credential.
However, I do not mind sharing my private credentials with myself. I am not planning on sharing the code. If I did share the code I would use something like dotenv to separate the credentials from the code.
Twitter provides developers a second set of credentials
that allows developers to access their own accounts for testing.
Thus it is possible to access ones own account programmatically
by just providing to sets of credentials: the developer credentials that allow the calls to the API and the other credentials that grant access to the developers own data. For example:
from twitter import *
t = Twitter(
auth=OAuth(token, token_key, con_secret, con_secret_key))
# Get your "home" timeline
t.statuses.home_timeline()
# Update your status
t.statuses.update(
status="Tweeting from Python")
Where con_secret* are the developer credentials and
and token* are the account access credentials.
How can I do something equally simple with Google APIs?
Where can I get credentials to access my own account?
How would I use them in Google API?
As an example what would be the simplest procedure for retrieving the contents from one of my own Youtube playlists?
I have com to think that a Python headless browser library could be give me what I need. I have asked a related question on SE Software Recommendations
https://softwarerecs.stackexchange.com/questions/35744/python-headless-browser-library-for-oauth2-authentication-from-ipython-console
I would like to download a set of credentials
Google offers this ability through it's client_secrets.json file. There are different ways to download this, depending on the type of account you want to use (Web application, installed application, Service account). The different techniques can be found here .
Store the credentials locally and keep using them without requiring
new credentials every call
This also isn't a problem, the client secret is valid until you renew it - AFAIK there is no automatic expiry unless you specify otherwise.
Once you have downloaded your client_secrets.json, store the file in a non-public directory (normally inside your project directory/config).
Similar to the downloading of the file, there are different techniques (flow classes) to use the JSON file depending on what type of account you are using. As an example, the below would be used for installed and web applications;
from oauth2client.client import OAuth2WebServerFlow
...
flow = OAuth2WebServerFlow(client_id='your_client_id',
client_secret='your_client_secret',
scope='scope URL here',
redirect_uri='http://example.com/auth_return')
Other flow class examples can be found here
Hope this helps - If you need further information, the official documentation (which be warned, can be incredibly inaccurate and confusing) can be found here https://developers.google.com/api-client-library/python/guide/aaa_oauth
Related
I need to have access to Calendar information from a company's G Suite accounts, to synchronize data with the company system through a API.
When I need to provide access to my own data, there is a fairly simple way to do it. Using Oauth2, through a login window the user allows the API to access the requested data.
But in the G Suite documentation, the path indicated when involving the administrator and company data, involves the administrator accessing admin.google.com, go to the security-related session, and manually register my API, listing the scopes that he wants to grant me access.
To make a parallel, in Microsoft Graph there is a way to request consent from the domain administrator, where only a user consent / admin consent screen is displayed using Oauth2.
I wonder if there is a way to get this type of access in G Suite without requiring the end user to take such complicated steps to make my API work properly.
UPDATE:
This question was originally posted in 2019, does anyone aware if something was changes since then?
You should use the Marketplace SDK for this. This allows you to publish an application to the Google Workspace Marketplace where company admins can choose to install it for their domain.
There are a couple things to keep in mind:
There's an expectation that your application will have some sort of user facing presence (e.g. add-on, link to web app, etc).
Google will review your app before publishing. Since you're not using Gmail or Drive scopes (for these, Google requires a 3rd party security review), this process should not be too difficult. But plan for it to take some time, and follow the best practices so it's done right the first time.
You also mentioned synchronizing calendars. If that means mainly reading, no problem, but if you're writing (a lot at once), be mindful of calendar use limits. These are per user and for all activity by that user (not just your app).
I'm faced with a difficult scenario regarding OAuth 2 authentication and Google's Calendar API.
I am attempting to write a PHP script which processes my personal calendar data after being triggered by a POST call from an external source. However, I am having trouble granting the script access to my account. Since the script runs entirely in the background, there is never an opportunity for me to enter the authorization code which is required for PHP command line tools making Google API requests.
I have looked into Service Accounts, which grant access to personal data without individual approval, but unfortunately this is only available to G Suite users, which I am not.
I have also attempted to run my script manually, enter the code to authenticate, then run it from my external source. This doesn't work either, because the authorization codes are apparently only good for the same mode of access where it was entered, and the response to the external source still shows as asking for the code.
Lastly, please note that responding with the authorization code from the external source is not an option. Which I can activate the trigger, I cannot change how it works or the data it passes.
TL;DR: How do I grant a PHP script (which runs only in the background) access to my personal Google Calendar data?
Thanks in advance!
Articulating this question actually helped me better formulate my Google searches, and I found the answer!
I'll leave this question/answer here so somebody can hopefully benefit from it -
Turns out that the Service Account is the way to go, but instead of trying to access your account's data via the service account, you need to share the calendars in question with the generated service account email address. Essentially, this makes the service account a "co-owner" of the calendar. Then, you simply make the request to the service account's own information.
Hope this helps!
I have an application that needs to upload file to Google Drive via the ordinary Google Drive API. It needs to upload, but it never needs to download anything, list directories, read metadata or anything like that. It basically uses Google Drive as a drop box to store results of some computations.
Because of the principle of least authority, I would like to give this application the authorization to create new files, but not read or modify anything. Is this possible? I cannot see anything like this in this list, so I suspect the answer is no, but would like more informed comments.
By principle of least authority "user/process should have necessities/privileges". A file created by an app is owned(create/modify/delete) by app and no access to rest of resources.
If this definition fits in your scope then use
https://www.googleapis.com/auth/drive.file
"Per-file access to files created or opened by the app"
As stated in Choose Auth Scopes
Auth scopes express the permissions you request users to authorize for your app. While many Drive apps can function with just the required set of scopes, you may need to consider using other available scopes.
As far as I know, you can choose from the list of scopes available for the Drive API, combine them or mix and match if necessary. And, you can also add other scopes if your app requires access to any other Google APIs as given in Google APIs scopes.
To learn more about scopes, you can watch the video of Google engineers discussing related tips and tricks within the given documentation. I hope that helps.
I took a look in some docs at developers.google and some questions here in stackoverflow and I really would like to found an objective answer about use the Google OAuth Server to authenticate an application and grant access to download docs into a Google Drive account with NO BROWSER interaction.
As far as I could look, docs like "Using OAuth 2.0 for Server to Server Applications", "Using OAuth 2.0 for Devices", answers here, I couldn't found an article saying "Is possible to authorize an application to get files from a common Google Drive account in Devices with no browser...".
Anyone have tried and had success in this jorney?
The Devices flow is meant for applications that run on devices where no browser is present (fancy example could be a wristwatch that shows new G+ notifications) and requires the user to do manual steps on a device that has a browser. Also this is for getting access to data on the user's account.
UPDATE:
As you say you have an embedded application running without a browser available and want to access data on behalf of a user, this is definitely the way to go. This however still needs the user to login (once) on another device with a browser. After you got an access token using this flow, you can then access the Google Drive API either manually or by using some library.
So you want to access data on Google Drive that belongs to a special account and only your application can access it without a browser involved?
A Service Account (the Server-to-Server flow) would be exactly what you need. These however are only for usage on a web server, as otherwise your private keyfile would have to be deployed to a client, where it could easily be extracted.
One thing you could do is use your own web server that fetches data from your Google account using a Service Account and have a client application that only connects to your own web server. This has of course also its downsides, especially when it comes to locking down your web server so no third party clients could access it.
It can be done, but a browser does need to be used. I've successfully gotten OAuth 2.0 working on an IBM i (AS/400, iSeries, System i, whatever the name is today) which doesn't have a browser. I've so far implemented the Calendar and Google Cloud Print APIs.
During the OAuth 2.0 negotiation you will be returned a URL and a code. You need to display the URL for the user to go to, then the code to enter to grant authority for that specific API/scope. I have an example in our documentation here:
http://docs.bvstools.com/home/greentools-for-google-apps/docs/g4g-base-commands/g4gregsvc
But, the issue now is that the drive API is not yet available to devices. But, Google has said that soon it should be.
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.