The two protocols are the main contenders for how single sign on (SSO) automation happens for the vast majority of use cases. The two come at the problem from somewhat different histories, perspectives, and functionality. In particular, they differ in terms of how they can be used for just-in-time user provisioning, how they interact with service and identity providers in the SSO connection dialogs, their relative performance, how they are positioned in terms of consumer or enterprise software plays, and the number of known security vulnerabilities.
SAML was originally created back in 2002 as a way to exchange XML information between various websites, and has since grown into its role in providing common logins among trusted sites. OpenID came out in 2006 and was designed for consumers to have common logins, but the sites don’t have to necessarily have this “circle of trust.” SAML is more often found in commercial situations, and OpenID has been implemented by a number of the larger consumer SaaS websites such as Google and Facebook.
An SSO request can be initiated in one of two ways, either by the service provider (such as the application site itself) or by the identity provider (the SSO vendor or some other identity store such as an enterprise Active Directory). SAML supports both methods, but OpenID only supports the former.
When it comes to performance, SAML is usually cited as better than OpenID, because it makes use of browser redirects and is a smoother process. However, OpenID is generally thought of as easier to implement.
Both have experienced some security issues. SAML has been the subject of one vulnerability and OpenID has seen some phishing attacks and can be compromised if the originating email addresses aren’t validated properly.