I have read all the information and guidance and watched the videos on
Developers Google Drive (sorry, I do not have enough "reputation points" to include all the links that would be relevant here).
as well as Google Privacy Policies.
In the list of Google Drive auth scopes, which ones are covered by the permissions request to users for the app to "view basic account information"?
https://developers.google.com/drive/scopes
I can only find examples, rather than a complete list.
I am also trying to understand how this relates to the Privacy Policy, ie. whether this "basic account information" is "Personal Information" or "Google Account" information.
http://www.google.com/intl/en-GB/policies/privacy/key-terms/#toc-terms-personal-info
Personal information
This is information which you provide to us which personally
identifies you, such as your name, email address or billing
information, or other data which can be reasonably linked to such
information by Google.
Google Account
You may access some of our services by signing up for a Google Account
and providing us with some personal information (typically, your name,
email address and a password). This account information will be used
to authenticate you when you access Google services and protect your
account from unauthorised access by others. You can edit or terminate
your account at any time through your Google Account settings.
I have read elsewhere that the "basic account information" is not actually "viewed", ie. visible to, the app developer but is instead transmitted in encrypted form for use by the app.
(I am not an app developer - this just seems to be the only place where there are Google staff watching and answering these sorts of questions).
User's profile and email is available if you grant access for the following scopes:
profile: https://www.googleapis.com/auth/userinfo.profile
email: https://www.googleapis.com/auth/userinfo.email
Profile stands for a Google Account and contains user's ID, name, photo, URL, country, language, timezone, and birthdate.
Related
I'm writing an Apps Script Add-on for Google Sheets. There are duplicate fields on the OAuth consent screen and the Google Workspace Marketplace SDK Store Listing screen. These are "Terms of Service" and "Privacy Policy" URLs.
Do they need to be filled out in both places? It appears that they are optional on the OAuth consent screen since they do not have an asterisk next to them. Is that true?
If they do need to be entered in both places, do they need to match? On the Store Listing, I used URLs pointing to a shared (with everyone) Google Doc. But on the OAuth screen, it appears they are requiring the documents to be on my website, since they are under the App domain section.
I've seen a working tutorial from a few years ago where a shared Google doc was used for the store listing. But has that policy changed and now do they have to be on my website?
If you are planning to make the OAuth Consent Screen for External users you should add the Terms and Conditions as well the Privacy Policy fields, otherwise it's very unlikely that it will be approved in the verification process, if it will be for Internal users you might try to keep these fields empty as in this case the OAuth Consent Screen will not be verified.
Regarding if these fields should match the fields on the Marketplace listing, it will be weird if they doesn't match. AFAIK Google doesn't review exhaustively the Marketplace listings but if users complain the might review it. They might contact you giving some recommendations, disable the Marketplace listing, etc.
If you want to use a Google Editor files for your TOS and Policy files, you might embed them in a Google Site with a custom URL.
Resources
Use a custom domain for your site
I found the following information about the "Privacy Policy" URLs:
Make sure that your app's Privacy Policy meets the following requirements:
The Privacy Policy must be visible to users, hosted within the domain of your website, and linked from the OAuth consent screen on the Google API Console.
The Privacy Policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices disclosed in your published Privacy Policy.
Based on the first requirement, I will say they need to be the same URL under the Google Workspace Marketplace SDK Store Listing and the OAuth consent screen in the project.
However, there is no such restriction for the Terms of Service inside Google Documentation.
Reference:
OAuth API verification FAQs.
Getting prepared for verification
As a Reseller, is it possible for me to leverage Service Account to call Reseller API and Directory API to create new domains and manage user accounts under them without requiring user interaction/login/consent?
The End-to-End tutorial for Reseller API (https://developers.google.com/admin-sdk/reseller/v1/codelab/end-to-end) suggests it is possible. I could create a service account under my Reseller domain. Using this service account, I can impersonate a super user admin under my Reseller domain and can achieve the above.
On the other hand, when I read through the article on Authorizing Requests (https://developers.google.com/admin-sdk/reseller/v1/how-tos/authorizing), it mentioned that "All requests to the Google Apps Reseller API must be authorized by an authenticated user", which seems to suggests that some form of consent is required. Further, it doesn't mention that service account is supported.
I tried to search for similar topics in the forum and I am seeing somewhat conflicting responses. The answers range from "yes, this works" to "service account not supported with Reseller API" or "API access must be manually enabled in each resold domain".
Thanks!
Google have multiple products like Youtube, Gmail, Google Drive and many more. When we login into one product like gmail then while hitting another product like youtube we will enter into this account without login. Then My question is how google uses cookies for different domain like youtube, gmail and any other. If anyone knows about this please let me know thanks in advance
This is not google specific thing. You have to study more about single-sign-on and claims based authentication to understand how this is achieved.
The common protocols used in these scenarios are OAuth and OpenId Connect.
Basically 3 parties involved here. The User, The Application, The IP(Identity Provider).
In this example Gmail, youtube and google drive, all are applications. They all use google(accounts.google.com) as identity provider. When user try to access an Application(gmail,youtube) he is redirected to the identity provider(accounts.google.com) and get authenticated. The identity provider issue a cookie(from accounts.google.com domain) to the user. The application receive Token from Identity provider saying user is authenticated and after validation of the token, application also issue another cookie(from gmail.com or youtube.com) to the user.
As long as user has the cookie issued from identity provider, he don't want to sign in again when he logs into an application that use the same identity provider.
We are a italian municipality, we have to start a google site to let the people to signal city issues.
Unauthenticated users can post or view issues,
Google domain's authenticated users, can edit some information.
For some categories, external companies are engaged for solution, these aren't google domain's users, but we need to let them edit the information as the authenticated users ...
Is there a way to authenticate an external user to Google domain?
Or a way to recognise the user working on a google site?
Thanks,
Marco
You can invite users who do not have a google account to be a site editor. This is done with the standard site share settings. An email will be sent to the users email you added with a link with an access token. The user will have to click that link to open the page in edit mode.
If a user shares this link it is effectively sharing his editing rights to your site.
I would like to use Google Forms as a means for the users of my system to enter their login credentials to various system tools.
The reason this is important is because as their admin, I will need to manage various aspects of their tools.
Users are (rightly so) anxious of entering passwords in clear text boxes. What is the best method for retrieving such information in a safe and user-friendly manner?
You should NEVER collect user credentials for 3rd party services, e.g. collecting username/password to Google accounts. Not even if this is a Google Apps account belonging to your organisation (note that google gives admins the ability to reset password but not to view it). Also, a lot of users are now using two-step verification, so collecting user credentials will not work.
If you need to access Google services in the name of the user, than you should look into OAuth.