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

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

What happens when you “Sign in with Google”?

  1. 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.
  2. 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”?

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store