[danbruc]

If they are storing the password and pushing it to the connected service on the user's behalf, then they have to be able to decrypt it somehow [...]

But not necessarily all of them all the time. The decryption key could be derived from the master password of each user and only kept around while the user is logged in.

[brazzledazzle]

That wouldn't work, at least for a lot of customers, because they authenticate a user based on a chain of trust back to the customer's on-prem Active Directory instance. An agent running on the customer's infrastructure leverages Kerberos/NTLM to authenticate the user then passes a token back to the identity provider. As a result there are authentication flows where the provider never sees the password.

Many providers do have an agent that runs on the AD servers that MitM captures the passwords when the user rotates them but that's a lot more involved to get setup. They could either force use of that AD agent or remove the functionality entirely and force users to manage a password with the service but it would either make on-boarding slow/impossible or really reduce the convenience factor for users. It's something every identity provider would need to do (or be forced to do) because the ones that didn't would steal away all of their customers.

[sbarre]

That depends on how the service works I suppose. Does a user have to enter a master password when they log into OneLogin, or does an SSO service authenticate them to OneLogin, which then logs them into Twitter/Facebook/etc?

If the latter, then OneLogin has to possess the ability to decrypt the passwords without user input (edit: although I suppose the SSO token coming from the client could be the key? I don't know if that's possible or how that would work - the key would still need to be cached for some period of time post-auth either way I would think)..