The difference between Sign in with Google and Identity Management
One of the most surprisingly complex and overlooked concepts young IT teams are missing is the difference between centrally federated identity management and signing in with your corporate Google account. They are completely different conceptually, even though they seem very similar.
Signing in with Google
When signing in with Google to a SaaS service (using the OAuth 2.0 protocol), you are using Google as an authentication provider, meaning it can approve that the person who is currently connecting is indeed who he claims to be. However, after the authentication flow has completed, the user’s entity is entirely controlled by the SaaS that the user is trying to log into.
For example, if you, as an IT admin of the company, would like to automatically create or configure that user, it would be impossible without you knowing the password and actually signing in on behalf of that person, who works for your company and has a Google account. Deleting the user would also be impossible — you would only be able to delete the Google account and remove the ability of your former employee to log in to the SaaS service. The user entity would still be there in the system — and if that user has any other additional approved authentication methods (such as a password) — he would still be able to log in.
Federated Identity Management
The concept of federated identity management means that the actual user store of your organization’s employees is at the identity management provider (a.k.a Okta, Azure Active Directory). Google is a provide identity management as a service (IDMaaS), but can also provide authentication capabilities only (a.k.a Single Sign-on, or SSO). IDMaaS services also provides Single-Sign-on, usually via the SAML protocol (as opposed to OAuth).
What happens when you “Sign in with Google”?
Behind the scenes, whether you use Google as an authentication provider or as an identity management provider, when logging in with Google, it will redirect you to Google for the authentication. However, right after the authentication is complete, two very different things will happen, depending on how you use Google:
- If you use Google as an authentication provider, the SaaS service (e.g. Salesforce) will create a new user entity and manage it on its own. It will allow you to set a password and administer your user settings on your own. Your organization will not be able to administer your Salesforce user in any way, and will not be able to log into your account, change your user permissions, or delete it.
- If you use Google as an identity management solution, the SaaS service (e.g. Salesforce) will create a custom 1:1 extension entity which represents the extra metadata it needs to store on the federated user — but will use the identity management as the “user database” to interact with the user’s configuration. For example, if the SaaS would want to know the full name, department, or the groups in which the user is currently part of (for internal authorization, e.g. which Salesforce information is the user allowed to access or is he an admin) it would query the identity management directly for that information.
Why is it sub-optimal to go with Google as the “option”?
TL;DR — because it practically means you’re not going to manage your employee SaaS users.
Google is a great company, but Google Workspace as a product is more focused towards productivity, and not security and usability as an Identity Management provider. It does support SAML, and can function as an identity manager, but most existing integrations today with SaaS services are simple SSO integrations which use Google only as an authentication provider.
As of now, the two leading identity management providers in the market today is Okta and Azure Active Directory. Like Google, they all provide identity management and SSO capabilities, but unlike Google they are both highly focused on providing the best identity management solution.
Another downside of using Google as an identity management provider today is that the existing integration method of most SaaS solutions to Google is only as an authentication provider, which means that if the SaaS developers did not do a good job in offering general SAML support or Google SAML support as an identity management solution, it may potentially create a mess. In other words, the fact that Google is an authentication provider first and a federated identity solution second means you will have a hard time configuring them right across all services, if even possible.
When dealing with dozens of SaaS services (at least), the safe bet is just to go with something like Okta from day one.
