The difference between Sign in with Google and Identity Management

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.

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:

  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”?

TL;DR — because it practically means you’re not going to manage your employee SaaS users.



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