Kinda-sorta, in the same way a password manager is. It allows one strong password/2fa vs many likely weaker passwords.

In reality OneLogin is typically using a federated login protocol like SAML or OIDC to grant access to third-party services. This means it can also be used to immediately revoke access, without having to reach out to and reconfigure various services.

For SAML at least if the identity provider is compromised, meaning I can now issue tokens using it's certificate, each service will need to be provided with a new certificate. That requires 'reach out' to each service,

Yup - we had to reconfigure each service that uses SAML today.

Also don't forget having to audit each service's API keys/tokens/local users etc to make sure someone hasn't gotten access via a compromised certificate and then created a sneaky API key for them to use in the future.

Basically we had to assume every app had been compromised and rotate every internal key/certificate the was in each one, as well as reconfigure them with a new SAML certificate.

In cases where OneLogin provisioned third-party accounts for sites that didn't support SAML, they (at least used to) sync your OneLogin password to these third parties. It did not use unique per-site passwords.

If your OneLogin password was "pass123", so was the password for your OneLogin-managed accounts at Google, Salesforce, and so on. I believe but am not certain that this was even the case for some sites that used SAML but required passwords for non-HTTP access. Mail clients accessing Gmail is an example.

I do not know if this is still the case. I suspect it would not be difficult to check.

It's a bit of a double-edged sword, but mostly a positive. If this account is compromised, you're fucked. However, if any of your other accounts are compromised, all of the rest are safe. If you used the same password for all sites, that is not true. So basically, you're putting all your eggs in one basket, which you then hope is super safe. That makes this breach pretty scary.

An individual OneLogin relying party does not have credentials to leak that could be used anywhere else. It just verifies signed messages from OneLogin.

The sheer number of databases that have and can lose your password is most of the risk with password reuse.

Companies aren't going to maintain separate user tables for every authenticated service that employees use. The alternative is to have each service handle passwords directly and pass them through to an LDAP server, or run their own SAML IdP with considerable difficulty.

At least an individual company's IdP doesn't have the "hack many companies at once" target on its back.