Reputation: 22959
Disclaimer: https://console.cloud.google.com/support/community leads here. Google's documentation is horrific so giving this a whirl on the off chance that I don't get downvoted to the depths of dev/null
Out of impending necessity I am migrating a private application that monitors our Gmail accts to OAuth 2, and as part of this process it was necessary to create an OAuth consent screen. Since this application will only be used internally it makes the most sense to choose "Internal" for Application Type - which is described as follows:
Only users with a Google Account in your organization can grant access to the scopes requested by this app.
The users on this Project consist of two "owners" — myself using my personal Gmail acct, and another employee who is part of the company G Suite account.
My question is who qualifies as a "user in my organization"? Is this based on the project owners? Does my non-G-Suite account (which is an owner of the project) qualify? Does the inclusion of one member in a G Suite account automatically associated the other employee accounts? Is the anywhere to actually see these users or manage them directly?
I'd actually like to add another couple accounts to the mix but still keep the application private, but I'm confused about how Google determines which gmail accounts will be able to authorize the app.
UPDATE: To clarify, when I visit the consent page while logged in as a member of our G Suite on the same domain as the project owner, everything is fine. However, we have other members managed in the same G Suite account who are under a different domain and for these I get the message:
Error 403: org_internal This client is restricted to users within its organization.
Furthermore, I am not even able to grant access using my own email which is the creator and owner of the application. I'd like to know how I can add myself and the other G Suite members to be able to grant access to the application without making it public. It was suggested below that I add them (or their domain) to Google Cloud IAM but I'm unclear about how to get this working. My own email does already exist in IAM with role of "owner" and apparently that doesn't satisfy the requirement.
Upvotes: 11
Views: 13788
Reputation: 1325
In order for internal apps to be used for OAuth, the project must belong to the organization associated with the same GSuite customer as all the users.
non-GSuite accounts cannot be used by internal apps. There's more information about this here: https://support.google.com/cloud/answer/6158849#public-and-internal.
Upvotes: 6
Reputation: 1927
For GSuite Users:
Cloud IAM only deals with authorisation you would need to handle authentication elsewhere. By default GSuite integrates with CloudIAM as a default authentication provider.
For Non-GSuite Users:
You can use cloud identity free edition but users will have to manage separate set of credentials.
Single Sign On without GSuite
If you want Single Sign On Option you can also use Google Cloud Directory Sync to sync with your on-premise Active Directory or LDAP server for authentication. So users can keep their login details.
That's how authentication works on GCP. As for authorisation you have CloudIAM where you can manage access through Predefined Roles, Primitive Roles and Custom Roles.
Cloud IAM and Authorisation
Typically you assign access using google groups and resource hierarchy to make it easier for you to manage user access. But bear in mind that if you grant an access to something through a ascenstor folder in resource hierarchy then you can't deny access downstream. So you need to plan access hierarchy accordingly.
To answer your question who qualifies as a "user in my organization"?, everyone can login but by default they cannot access any projects, it's resources or apis unless they are given access to either individually or through a group.
Hope this clarifies things for you a little.
Upvotes: 1
Reputation: 81454
Who is a member of my organization?
Anyone that you have added to Google Cloud IAM for a project, folder or at the organization level. This can include Google Accounts (Gmail email addresses), G Suite and Google Identity. The last two use a domain name (example.com) and anyone with an identity in that domain ([email protected]).
Google's goal is to tighten up security for Google Cloud Platform. In the past anyone with a Google Accounts email address could use your projects OAuth to request access. The level of access is controlled by OAuth Scopes. Today, granting that access results in a Consent Screen with an unverified application warning. To get beyond (remove) that warning often requires a security audit of your application with a cost estimated at $75,000 USD.
How do I manage members?
Through Google Cloud IAM. You can add and remove members; assign and remove IAM roles attached to member IDs. Through G Suite or Google Identity by adding or removing member accounts. Don't forget that members can be part of a Google Group and part of a Domain each of which are also an identity in Google Cloud Platform.
Upvotes: 5