NIST defines single sign-on as an authentication process by which one account and its authenticators are used to access multiple applications in a seamless manner, generally implemented with a federation protocol. For a consumer app, that is Sign in with Google. For a business product, it means letting a customer's staff log in through their company's Okta, Microsoft Entra or Google Workspace, using SAML or OpenID Connect.
Larger customers ask for SSO because it lets them enforce their own password and two-factor rules and switch off a departing employee's access everywhere at once. For you it moves password handling to the identity provider, but it adds new ways to fail. Your app must validate the signed response properly: the signature, the issuer, the audience and the expiry. It must also decide how an SSO identity maps to an account in your database.
The classic mistake is linking accounts by email address alone. If your app trusts any identity provider's claim that a user owns a given email, someone who controls a provider can assert another customer's address and land in their account. Use a maintained library or your auth provider's SSO feature, tie each customer domain to its own provider configuration, and only trust email claims the provider marks as verified.