Google Marketplace - Installing application and access tokens

Question

Trying to test installation process for my marketplace application. Google documentation says that I can test installation process by using Test Install Flow button in the console. When I click on that button, I see the authorization dialog and I click accept. The dialog is closed and app is installed on the domain I am testing.

Question: Should I be getting and storing a refresh_token at some point in this installation process?

There is an Install URL that I can specify in Drive SDK but I can't find documentation about when Google posts to this install URL and what gets posted.

Answer 1

The short answer to your question around the refresh_token is - No. You won't get a refresh token upon install. You have to instead ask for a fresh access_token using a Service Account key you've got.

So basically, the way a Google Apps Marketplace (GAM) app is supposed to work is to get itself a Service Account and build with that for all authorization. There are no refresh_token with Service Accounts, just fresh new access_token. For an app that is installed by consumers you should use standard web server flow. This is one area of complexity that wants to be both a consumer and enterprise app.

When an admin installs your app, he/she is in essence authorizing your app's Service Account key to his/her domain.

Once an app is installed, that Service Account has full delegated access

Regarding the Install URL for a Drive app. You can ignore that for a GAM app.

Hope this helps. We'll release some end to end sample at some point soon .

Answer 2

Here is a project which shows you how to do just that:

Checkout the section called: Cached Credentials

http://www.codeproject.com/Articles/488185/Working-with-Google-Drive-in-WPF

Excerpt from the above URL:

Provided the user allows access, the authorization server will return the authorization code. It can be sent back either by the Google server calling a web service endpoint opened by your application or in the title of the page sent back to the browser. Because of the challenges of spooling up a web server, opening a connection through any possible firewall(s), etc... it is much easier for installed applications to simply scrape the authorization code from the title of the resulting web page. That is the technique used in the sample project. If successful, the title will be set to Success code=xxxxxxxxx where the xxxx's are replaced by a unique authorization code.

The authorization code only gets you invited to the party. You can't do anything with that code as far as API access. The Authorization Code must be exchanged for a short-lived access code and a long-term refresh code. In the Google.Apis.Authentication.OAuth2 library is a class called NativeApplicationClient. This is the wrapper for the authorization server and it has a method called 'ProcessUserAuthorization'. This method takes the authorization code we retrieved after the user authorized the application's access and turns it into the access token and the refresh token. The access token is what we actually need for the task at hand and it is maintained in the NativeApplicationClient. It gets passed with all subsequent API calls. The nice thing about the NativeApplicationClient is that it knows how to verify the access token and how old the token is. If the token has expired, the client will use the refresh token to get a new access token. That takes the burden off of us to manage token lifetimes.