Somewhere around 80–90% of enterprises use Active Directory for user authentication, so if that is your target market, AND you are building an application that will be deployed on-premises (inside the corporate firewall with Active Directory), the easiest approach is to use Integrated Windows Authentication (IWA). IWA uses SP-Negotiate to provide authentication services using Kerberos, NTLM, and other mechanisms. Using IIS as a web server on a domain-joined server makes this a pretty trivial exercise. With configuration magic, most other popular web servers can use IWA as well. That would provide your application with authentication and single sign-on (SSO) functionality in an on-prem environment.
If you’re building an application that runs outside of the firewall, or if you are building a multi-tenant application (same application used by multiple enterprises… think “cloud SaaS app”), or you want to support enterprises that use public identity providers like Azure Active Directory or Okta, then you should implement SAML 2 relying party support, in particular the web SSO profile. Many (not most) enterprises have a SAML identity provider (IdP) service that they can use to provide authentication assertions to a web application. This let’s enterprises provide their own authentication service (often Active Directory) and then provide evidence of authentication to your application via SAML messages. Most web servers have SAML modules you can just plug in, but configuring the conn