Authorizing command line tool to consume Google APIs (through OAuth2.0 or anything else)

Question

I think I understand how OAuth 2.0 works in the context of a mobile app or website - neither is my case.

I have a C++ command line applicat

Answer 1

To answer your question about the "Installed application" flow:

The authorization code is only valid once. After you have exchanged it - and got a refresh token and an access token - it won't be usable anymore. Just dump it. It's one-time use only and you don't need it anymore. What you need to do is simply keep/save/persist the refresh token in some local file for reuse.

The refresh token is the important token. It gives you access to the API for an unlimited period of time because you can use it to programmatically get new access tokens (which are valid 1h). Check the refresh token doc about that operation.

The Google APIs Client libraries usually handle refreshing the tokens automatically and transparently for you but since we don't have a C++ client lib you need to do this yourself. One technique we use is that we catch 403 errors when doing requests to the API (which indicates an invalid access token), in that case we do the refresh to get a new access token, then automatically re-try the operation that failed initially.

My advice:

The flow that will give you the best user experience is to use the server-side web application flow. It is possible to use it on installed and/or command line application, though it is more work. Here is how:

1. Start a local web server on the user's machine listening to a free port (for instance: http://127.0.0.1:7777)
2. Spawn a web browser window (or embed it in your app) redirecting the user to the Google OAuth 2.0 grant page and set the redirect URI to http://127.0.0.1:7777
3. When the user grants the application access, it is redirected to your server listening at http://127.0.0.1:7777.
4. On your local web server you get the auth code that's in a URL query parameter. You can now exchange the auth code for access and refresh tokens which you persist
5. Kill/close the local web server you started in step 1
6. Kill/close the browser instance you spawned in step 2

That's it, you now have the refresh and the access tokens (from step 4) and you are back in your app after killing the browser.

Why All this mess?

Client Login has been deprecated. It's going away and doesn't work with newer APIs. Google doesn't want users to give you their password, as you might be tempted to store it and you could get hacked :)) Also, it gives you access to too much information, since you could buy stuff with their Google Checkout account or change their password to steal their accounts. Currently, the only way to go on a security standpoint is to use these 3-legged auth systems like OAuth2 and discourage the use of passwords so that users get out of the habit of providing their username and password to 3rd parties. Of course, OAuth2 is a lot harder to use for desktop/command-line applications...

The OOB Alternative

If you do not want or can't start a web server to listen for the code then you can use the oob OAuth flow. It works by simply specifying oob as the redirect URI. In this case, instead of being redirected to a given URL, the user will be shown a page that says "Here is your auth code. Copy paste it into your app.". On your app you can simply have your user paste the auth code in a text field and voila. This is a worse user experience but can be more robust in some cases and work in more environment, especially low-tech environments.

Beware as not all OAuth 2 providers support that but at least Google and Facebook do.