Most importantly it gets you SSO on basic plans for any SaaS. Big companies using Okta or something have to pay for all those Enterprise plans just for that.
Yep, saves a lot of annoyance having to keep track of a bunch of logins across SaaSs especially when you need to revoke access when someone leaves, so instead of having to go to all the various services individually to deactivate the accounts, you can just deactivate their Google account or revoke its access to those services.
Ahh, that is a nice and unexpected bonus. Does “Sign in with Google” allow provisioning of new accounts with appropriate permissions for a service/SaaS by an admin? (I’ve only used OneLogin/Okta)
I'm not sure what level of permissions is available with "sign in with google". In my experience, that is handleded within the SaaS. Here's what's happened (at least in the companies I've worked in, which tend to be a bit smaller).
1. New employee hired
2. They get a gsuite account. This gives them access to google drive, gmail, gcal, etc. (This is the provisioning I think you are referring to.)
3. They can now login to asana, zapier, <other saas tool> with their gsuite account, using "login with google"
4. Their permissions within these saas tools are managed by the admins in those tools (not from gsuite).
5. When an employee departs, you disable their gsuite account. Then they can't log in to any of the SaaS tools, since their google account is disabled.
If you want a user to have centralized RBAC or ABAC, you need to use a real IdP, not gsuite in the way I outline above.
If you are using SAML for gsuite, you can use SCIM, I believe, to provision, but that's a different flow than I have outlined above. https://support.google.com/a/topic/6400789 has more on that.
