We would like to have our application deployed to Google market place app. As of now, our app uses email and profile scopes. For now, we only use the contats API of Google. In the future we would like to extend this to use calendar and drive apis. But for the first marketplace launch we would like to just use email and profile scopes.
Will build features incrementally with next releases of the app and extend the scopes.
1) Is this sufficient to meet the requirements of Google's review for a marketplace app ?
2) Also, please update which path should be taken for incremental change of scopes.
You can use Gem like "https://github.com/zquestz/omniauth-google-oauth2" for OAuth authentication and API usage with google.
You can use "email" and "profile" scopes as of now. Later you can modify the scopes, "email" and "profile" scopes are default scopes if you add some other scopes to the provider it will get overwritten so for eg. if you want to use contacts api along with "email" and "profile" scopes add all three scopes.
provider :google_oauth2, ENV["GOOGLE_CLIENT_ID"], ENV["GOOGLE_CLIENT_SECRET"],
{
:name => "google",
:scope => "email, profile, https://www.googleapis.com/auth/contacts,
}
Related
We build a ad-network for bloggers (instagram, youtube etc). We want to use google api for 2 use cases:
Register user with oauth which requires
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
both non-sensitive scopes (but still requires app verification)
If user wants to add his youtube account into our system, we need youtube data v3 and youtube analytics. Which must be sensitive.
Please advise, how to better set it all up: create 2 different apps (one for sign up, another for youtube) or make one app and request scopes depending on scenario?
I've added all scopes available to my Gmail API project via the Google Developer Console. It's registered as an Internal application type, so none of the scopes are sensitive.
I've saved and re-saved these settings, regenerated OAuth client IDs and updated them to be used in my flow.
However, when I get to the Google OAuth consent screen, the scopes are listed as:
This will allow [App Name] to:
View your email messages and settings
None of the other scopes I have selected are listed.
Here are some screenshots which might help:
OAuth consent screen:
OAuth settings (public/internal) - Google API Console
Scopes - Google API Console
Worked this one out eventually.
The OAuth settings screen I have in my question only provides for scope permissions to be requested. In order to actually access a specific scope, you must add it in the consent settings screen, and pass it to the API as part of the OAuth flow.
The solution was to add the requisite scopes to my code as well.
How can I programmatically retrieve information about an OAuth client given its appId (xxxx.apps.googleusercontent.com). I am interested in retrieving Google API scopes the app is requesting (e.g.: https://www.googleapis.com/auth/userinfo.email) along with marketplace ratings and user coun t (if applicable).
Screenshot
I believe you can only access those stats if you own the app/add-on. Assuming that you're working on a GSute add-on, if you deploy the app via GSuite Marketplace you'll have to explicitly specify the scopes your app requires and you can check those scopes from your Google Console. I believe that there is also a dashboard available to the app developer (probable from Google Console) with analytic data related to performance.
We have an existing web app which uses Google's OAuth 2.0 APIs for Admin Directory, Drive, etc for administrative tasks like backup and audit.
Currently we let our customers install backup and audit independently as 'modules' and each have separate client_ids and separate OAuth scopes (i.e. Admin directory for one, Drive for another).
We want to bring our app to the Google Apps Marketplace, and take advantage of Google Sign In (OpenID Connect), use service accounts with domain-wide delegation of authority, but still let our customers only authorize scopes they want to use.
Can we add new scopes to Google Apps Marketplace apps when a user wants to enable a certain feature?
The best practise guidelines (1) indicate that we should request all scopes we might want up front via the Marketplace SDK scopes section but we want to only request the scopes our customers are going to actually use.
(1) https://developers.google.com/apps-marketplace/practices#1_complete_the_listing_review_request_form
You can add new scopes. Your customer will still have to grant access though for the new scope/s from the ADMIN console.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.