My goal is to implement an SSO Service Provider in my web application, but I'm having trouble understanding SSO with Google as Identity Provider vs. other IdPs.
I've created two POCs, one which uses SAML and another one which uses OpenID Connect. Both seem to be working well.
What I've noticed is that with the Identity Providers I've tested (OneLogin, Okta), for both SSO methods (OIDC, SAML), I need to create an application and assign authorized users for that application on my IdP. When a user tries to login, they will only succeed if they are one of the authorized users. This essentially means that I don't have to manage invites and authorized users inside my application, as it is delegated to the application defined on the Identity Provider.
However, with Google as IdP provider, there is no 'assigned users' section for the SAML application and with OpenID Connect, I'm not even required to create an application in which users can be managed (just OAuth 2.0 credentials). This basically means that with Google as Identity Provider I need to internally manage authorized users, as google authorizes any user which is logged in with google and consents to share their personal data.
I'd be thankful if someone can demystify this behaviour. It sounds weird that I would have to change the authorization flow of Federated Identities depending on who my IdP is!
Well, the thing that OIDC provides is user authentication. The Google implementation provides just that and nothing else, while some other IdP's also give provide other functionality. I'd say that the Google behavior is more typical for an open cloud provider (Facebook, although they have their own OAuth2-based protocol, behave similarily), while the others are more typically used internally in enterprises.
Google does however provide a claim called hd (for hosted domain) that could be used to block users belonging to other domains (if that's what you want - in an enterprise setting I would assume it is).