Using Google OAuth2 and OpenId Connect in a mixed environment (GCP apps and on-premise)

0
votes

Migrating on-premise services and applications to Google Cloud Platform and during an extended transition will be in a blended GCP, on-Prem, third party service provided platform. Looking to standardize on GCP OAuth2 provider with the OpenIdentity provider as single source of authentication and verification.

I have poured over the documentation provided by Google Identity Platform and I see Authorization As a Service which appears to be based on Firebase and is close to what I need/want but not exactly.

The Open Identity provider has an SDK and can be integrated with Web, Server, and mobile device applications. Good!

What I am looking to confirm is that I can also use the OAuth2 SDK to authenticate a user with a token, and then use that token with the OpenIdentity APIs to control user access and features. I know this is entirely possible for the GCP native applications.

Presently it looks like using SAML to integrate with another OAuth2 platform within the Identity Product and then enabling the OpenIdentity provider will meet "most" of my needs. What would be missing would be standardizing on the Google Identity Platform before we migrate all our products and services onto GCP.

The burning question, can I use the OAuth2 implementation with services and apps not hosted on GCP?

The documentation seems to suggest to me yes and no simultaneously.

Any help appreciated at his point.

1
google-cloud-platformgoogle-apisingle-sign-ongoogle-oauthgoogle-identity
To get an answer you need to be very specific on the services you are using. Your question is like "I am going to Safeway, can I use all the food in my recipes?". As a general rule, OAuth tokens are vendor/service specific. Start with learning what OAuth actually is, how it is implemented and how authentication and authorization is performed. Then review each service that requires these features and review how they can be integrated. Google IAM is both elegant and complex and is based upon OAuth. However, to use Google OAuth in other services will require direct support in that service. – John Hanley
@JohnHanley - well that kind of bites (frustration not objection!). developers.google.com/identity/protocols/… I need to remotely access Google Oauth2 provider and open identity from both GCP and non-GCP servers and apps. But the Oauth2 provider documentation is contradictory. The above example suggests it is very doable. But I'm not finding any tutorial or examples. More sense or more noise here? – John Dugaw
@JohnHanley - just posted a partial answer to my cognitive issues. Now that I understand that key difference, most everything makes perfect sense now. It's not helping me solve my business case (yet) but I have 90% of a solution working right out of the box with about 2 hours worth of work. Thank you for the very politely worded RTFM. :D Best regards – John Dugaw

1 Answers

1
votes

See Hanley's response above. I had read the documentation available for several identity related products for Google Cloud Platform.

My question made sense to me but it does not translate to those who actually understand the the Identity Platform itself, and even say just one (1) of the integration implementation methods. Reading through the developer docs I caught upon a really important piece of perspective that answered nearly all of my questions.

In case it is helpful: - Google Sign-in uses @gmail.com (or others) google identities which applications or organizations can leverage - One can configure, create, import domain user identities using the Google Admin console - These are both considered domain entities and one can configure single sign-on (OAuth, SAML, 509x, JWT, OICD) for these by using providers, or writing custom providers - Either permits organizations and projects to utilize IAM and other Security-Identity features within GCP out of the box with minimal overhead

This covers about 90% of my initial use case and once I understood that domain user identities are either Google, or your own private domain identities created through the Admin Console through Group and User management, the remaining 10% was easy enough to solve.

I'm going to stop commenting here as this was key in understanding why things did not make sense, and why Mr. Hanley (thank you for your patience) was unable to answer my question at the beginning.

Hoping this helps someone else.