1

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...

Andrew
  • 1,406
  • 1
  • 15
  • 23

2 Answers2

2

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.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • Thank you for the detailed response John! I completed GCP's security course over the weekend. I'm seeing some inconsistencies in your response with what I've learned and read elsewhere (not surprised): 1) Although G Suite is separate, it apparently uses components of Cloud Identity under the hood and [admins are able to activate Cloud Identity in G Suite for free (paid has MDM), allowing G Suite groups with defined IAM permissions to be allocated to those users](https://support.google.com/a/answer/7384506?hl=en) – Andrew Mar 02 '20 at 02:52
  • 2) "The correct method for user credentials is OAuth 2.0 Access and Identity tokens" => My understanding was that all OAuth "ID tokens" are "signed JWT's"? [GCP ID tokens appear to be](https://developers.google.com/identity/sign-in/web/backend-auth#verify-the-integrity-of-the-id-token). 3) Considering the ID token is a JWT and [Google provide their public keys to verify ID tokens](https://developers.google.com/identity/sign-in/web/backend-auth), I'm assuming incorporation with Endpoints IAP will be achievable (otherwise custom code to verify). – Andrew Mar 02 '20 at 02:52
  • 4) "I have a feeling that you are expecting Firebase/Endpoints to do this for you" => I am expecting to pass the users Google ID to each Google api to leverage their associated IAM permissions, or use a [service account for each micro-service](https://cloud.google.com/iam/docs/service-accounts). 5) "I am not sure what you mean by "User Credentials". You should never have access to a user's credentials (username/password)." => I mean the users Identity Token/Google ID. – Andrew Mar 02 '20 at 02:53
  • 6) "The browser will have access to the OAuth tokens used for authorization & identity which is not secure" => I will not be using the app secret in the client, or authenticating the users ID token client side. My main concern now is whether or not Endpoints IAP can validate the ID token, so that the microservices can relay that token to Google API's, meaning leveraging the uses IAM & no auth code required in the microservices themselves. The worst case scenario is authenticating the ID Token in an auth lib in the microservices, & using service accounts to interact with the google api's. – Andrew Mar 02 '20 at 02:55
  • This question is one of the reasons that Stack Overflow recommends asking one well-defined question. Go over each point that I made and review the low-level details. Then create one question for each point you are asking about. For example, a Google OAuth Identity Token is a Signed JWT. However, the Identity Token is signed by Google and you cannot create one yourself. You must ask Google for the Identity Token. Another example, authorization in the client is NOT secure. If your app requests GCP related scopes your app might require an expensive audit to be approved. – John Hanley Mar 02 '20 at 03:12
2

As per my experience,

G-Suite as Identity provide + Cloud IAP will work to authn and authz to do user level access checks on the frontend. refer this

However for backend application to application communication, I will recommend service accounts in GCP, refer this. You can also use Cloud IAP to do the same, refer this. However the choice depends on your use case and your companies security guidelines and policies.

dagra
  • 589
  • 4
  • 20