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