Multiple questions re using Google Endpoints Identity-Aware Proxy to authenticate G Suite users for a B2B app hosted on GCP

Question

I'm currently investigating the most appropriate authentication/authorization approach for a greenfield project, to be entirely hosted on Google Cloud Platform. I'm writing this summary to do a sanity check of my preferred approach & seek feedback on whether there are any considerations or inaccuracies I'm unaware of. I would appreciate input from anyone with relevant experience in implementing the associated strategies.

The main queries/concerns I have are:

How to manage or negate scopes in the OIDC process? It should not be up to the user to authorize appropriate access; this should be set by the org IT admins that created the user
Can G Suite IT admins apply params to users (custom &/or not) which automatically allocate predefined "Google Identity/IAM" policy groups/roles?
Will the G Suite users signed JWT's/Google ID be directly compatible with Endpoints + IAP (not requiring any processing/re-encoding)?
Will this approach accomodate external users via a federated identity approach, in future, without major refactors to the existing process (e.g. Firebase auth)?

Requirements:

Angular SPA will be the single GUI for the application, hosted on the same domain registered for the organisation on GCP/G Suite
SPA will use GCP's api gateway (Endpoints) to make requests to GKE micro-services (likely all within the one VPC) & other G Suite services (Drive, etc)
Org IT G Suite admin's can create users & assign various (predefined) IAM policy groups/scopes via the G Suite UI, to give users least privilege access to org resources (G Suite services & GCP hosted custom api's/apps)
Users are ONLY able to "sign in with Google" to the SPA, using their orgs G Suite account
If the User is already signed into their org google account, they should not need to sign in again to the SPA
While logged into the SPA, the users credentials should be sent with each request, which micro-services will use for authorization of custom business logic, as well as passing those credentials to G Suite services like Google Drive (leverage api scopes authorization as additional layer of security if custom business logic fails)
In the distant future, there is potential to allow customers/users, external to the org, to utilize various federated identity providers (Facebook, Twitter, etc) to access a SPA & resources hosted by the org (this is not a current requirement, but it is a long term strategic goal)

The two approaches I've determined best fit for purpose are:

1) Endpoints

Google Sign-In with IT Apps to obtain the users org Google ID &, as we are using OpenAPI, the GCP Endpoints with an Identity-Aware Proxy (IAP), to manage authentication of the JWT token.

Pros:

Establishes a clear demarcation between internal users of the UI portal, & potential future external users
No custom code for IT admins to manage users
No custom code to sync Firebase & G Suite users, roles, permissions, etc, or access the mirrored G Suite user for credentials

OR, 2) Firebase

Firebase authentication, & write code to generate users in G Suite with the Firebase Admin SDK, restricting access to resources based on the org domain.

Pros/Cons are the opposite to Endpoints above, plus no need for 2 separate auth approaches if external users are ever required.

I'm leaning towards the Endpoints approach...

John Hanley John Hanley · Accepted Answer · 2020-02-29T18:32:47

How to manage or negate scopes in the OIDC process? It should not be up to the user to authorize appropriate access; this should be set by the org IT admins that created the user

Permissions for IAM members (users, groups, service accounts, etc) are managed in Google Cloud IAM. Scopes are used with OAuth to limit permissions already assigned by IAM. Best practices mean assigning the required permissions (and no more) and not combing IAM with scopes.

Can G Suite IT admins apply params to users (custom &/or not) which automatically allocate predefined "Google Identity/IAM" policy groups/roles?

G Suite and Google Cloud are separate services. Google Cloud supports G Suite as an Identity provider (IDP). Permissions are controlled in Google Cloud IAM and not in G Suite. You can combine G Suite with Google Groups to put IAM members into groups for easier IAM management.

Will the G Suite users signed JWT's/Google ID be directly compatible with Endpoints + IAP (not requiring any processing/re-encoding)?

Google Accounts (G Suite) do not provide private keys to its member accounts. Therefore you cannot use Signed JWTs. Signed JWT is an older authorization mechanism and is used with service accounts. The correct method for user credentials is OAuth 2.0 Access and Identity tokens. For administrators, service accounts with Domain Wide Delegation can be used.

Will this approach accomodate external users via a federated identity approach, in future, without major refactors to the existing process (e.g. Firebase auth)?

This is a difficult question to answer. Google Cloud does support external identity providers but I have found this to be problematic at best. You can also use identity synchronization but this is also not well implemented. If you are going the Google Cloud route use G Suite as your identity provider and Google Cloud IAM for authorization.

An important point that I think your question lacks is understanding how authorization works in Google Cloud and Google APIs. These services primarily use OAuth 2 Access Tokens and Identity Tokens. This varies by service and with the type of access required. This means that your application will need to understand the services that it is accessing and how to provide authorization. I have a feeling that you are expecting Firebase/Endpoints to do this for you.

Another item is that Firebase is part of Google Cloud and is only a subset of Google Cloud. Firebase is a great product/service but if you are planning to use Google Cloud features outside of Firebase, then stay with G Suite and Cloud IAM for identity and authorization.

Angular SPA will be the single GUI for the application, hosted on the same domain registered for the organisation on GCP/G Suite

I am assuming by domain you mean DNS Zone (website DNS names). This will make CORS and cookie management easier but is not a requirement.

SPA will use GCP's api gateway (Endpoints) to make requests to GKE micro-services (likely all within the one VPC) & other G Suite services (Drive, etc)

OK - I don't see any problems using Endpoints. However, a good answer requires details on how everything is actually implemented. Another item is that you are mentioning Endpoints and G Suite services. These are very different items. Endpoints protect your HTTP endpoints not other Google services where it would just get in the way.

Org IT G Suite admin's can create users & assign various (predefined) IAM policy groups/scopes via the G Suite UI, to give users least privilege access to org resources (G Suite services & GCP hosted custom api's/apps)

Google Cloud IAM and G Suite authorization are separate authorization systems. In order for G Suite members to manage Google Cloud IAM, they will need roles assigned in Google Cloud IAM via either their member ID or group membership. There is no shared authorization permissions.

Users are ONLY able to "sign in with Google" to the SPA, using their orgs G Suite account

Unless you configure SSO, Google Account members are the only ones that can authenticate. Authorization is managed by Google Cloud IAM.

If the User is already signed into their org google account, they should not need to sign in again to the SPA

That is up to your application code to provide the correct Authorization header in requests.

While logged into the SPA, the users credentials should be sent with each request, which micro-services will use for authorization of custom business logic, as well as passing those credentials to G Suite services like Google Drive (leverage api scopes authorization as additional layer of security if custom business logic fails)

I am not sure what you mean by "User Credentials". You should never have access to a user's credentials (username/password). Instead, your application should be managing OAuth Access and Identity Tokens and sending them to the backend for authorization.

In the distant future, there is potential to allow customers/users, external to the org, to utilize various federated identity providers (Facebook, Twitter, etc) to access a SPA & resources hosted by the org (this is not a current requirement, but it is a long term strategic goal)

I covered this previously in my answer. However, let me suggest clearly thinking about what needs to be authorized. Authorization to your app is different that authorization to your app that also authorizes Google Cloud services. For example, you could use Twitter for authentication and a single service account for Google Cloud authorization. It just depends on what you need to accomplish and how you want to manage authorization.

[UPDATE]

One term that you use in your question is SPA. In the traditional use case, all processing is being done by your application in the browser. This is a security nightmare. The browser will have access to the OAuth tokens used for authorization and identity which is not secure. This also limits your application's ability to generate Refresh Tokens which means the user will need to reauthenticate once the existing tokens expire (every 3,600 seconds). For the scope of this question, I recommend rethinking your app into a more traditional client/server design. Authentication is handled by your servers and not directly by (inside) the client application. In the sections where I mention service accounts, I am assuming that backend systems are in place so that the client only have an encrypted session cookie.