Does Google Cloud Platform provide application-level authorization features?

Question

I am working on GCP projects that use OAuth2.0 Client IDs set up using GCP APIs & Services > Credentials > OAuth 2.0 Client IDs.

Anyone with an email address that belongs to these project's parent organization can log-in via our OAuth2.0 OpenID Connect login pages.

Is it possible to restrict which individuals can login? It would be very convenient, for example, to define a Google Group (let's call it "Group 1") and then add specific users to that group. We could then have a specific project (call it "Project 1") require that users be in "Group 1" in order to login to "Project 1". If a user doesn't belong to any groups or belongs to "Group 2", instead, they would not be able to log-in to "Project 1".

Answer 1

1. If the users do not have IAM roles/permissions, they can authenticate to your application and be able to do nothing with Google Cloud. Are you confusing authentication with authorization? You can control access to Google Cloud on a per-user basis. Turn Google Cloud Platform on or off for users

2. Yes, Google Cloud supports groups. You can add identities to a group for group role management. Managing groups in the Cloud Console

3. Users do not log in to groups. They can be members of groups and assume those permissions.

[Update after question modification]

Google Cloud does not provide application-level authorization. You must implement access control within your application or framework.

Answer 2

From the OIDC or OAuth perspective.

Is it possible to restrict which individuals can login?

OAuth 2.0 is about delegation to limit what an app can do on behalf of a user; Although OIDC, which is built on OAuth 2.0 has authentication as part of the flow, it is only to the flow it is ONLY for the user to delegate permissions (Scope in OAuth 2.0) to an app.

You certainly could have separate scopes (for Project 1 and Project 2) that would grant scopes for the delegated access to the two different applications.

Also, generally you should grant only positive scopes for access and all others are refused. (i.e. " user doesn't belong...") would be if you do not have scope "Project 1", you can not access the resource.