Original OpenID 2.0 vs SAML
They are two different protocols of authentication and they differ at the technical level.
From a distance, differences start when users initiate the authentication. With OpenID, a user login is usually an HTTP address of the resource which is responsible for the authentication. On the other hand, SAML is based on an explicit trust between your site and the identity provider so it's rather uncommon to accept credentials from an unknown site.
OpenID identities are easy to get around the net. As a developer you could then just accept users coming from very different OpenID providers. On the other hand, a SAML provider usually has to be coded in advance and you federate your application with only selected identity providers. It is possible to narrow the list of accepted OpenID identity providers but I think this would be against the general OpenID concept.
With OpenID you accept identities coming from arbitrary servers. Someone claims to be http://someopenid.provider.com/john.smith. How you are going to match this with a user in your database? Somehow, for example by storing this information with a new account and recognizing this when user visits your site again. Note that any other information about the user (including his name or email) cannot be trusted!
On the other hand, if there's an explicit trust between your application and the SAML Id Provider, you can get full information about the user including the name and email and this information can be trusted, just because of the trust relation. It means that you tend to believe that the Id Provider somehow validated all the information and you can trust it at the application level. If users come with SAML tokens issued by an unknown provider, your application just refuses the authentication.
OpenID Connect vs SAML
(section added 07-2017, expanded 08-2018)
This answer dates 2011 and at that time OpenID stood for OpenID 2.0. Later on, somewhere at 2012, OAuth2.0 has been published and in 2014, OpenID Connect (a more detailed timeline here).
To anyone reading this nowadays - OpenID Connect is not the same OpenID the original answer refers to, rather it's a set of extensions to OAuth2.0.
While this answer can shed some light from the conceptual viewpoint, a very concise version for someone coming with OAuth2.0 background is that OpenID Connect is in fact OAuth2.0 but it adds a standard way of querying the user info, after the access token is available.
Referring to the original question - what is the main difference between OpenID Connect (OAuth2.0) and SAML is how the trust relation is built between the application and the identity provider:
SAML builds the trust relation on a digital signature, SAML tokens issued by the identity provider are signed XMLs, the application validates the signature itself and the certificate it presents. The user information is included in a SAML token, among other information.
OAuth2 builds the trust relation on a direct HTTPs call from the application to the identity. The request contains the access token (obtained by the application during the protocol flow) and the response contains the information about the user.
OpenID Connect further expands this to make it possible to obtain the identity without this extra step involving the call from the application to the identity provider. The idea is based on the fact that OpenID Connect providers in fact issue two tokens, the access_token, the very same one OAuth2.0 issues and the new one, the id_token which is a JWT token, signed by the identity provider. The application can use the id_token to establish a local session, based on claims included in the JWT token but the id_token cannot be used to further query other services, such calls to third party services should still use the access_token. You can think of the OpenID Connect then as a hybrid between the SAML2 (signed token) and OAuth2 (access token), as OpenID Connect just involves both.
OpenID and SAML2 are both based on the same concept of federated identity. Following are some of the difference between them..
SAML2 supports single sign-out - but OpenID does not SAML2 service providers are coupled with the SAML2 Identity Providers, but OpenID relying parties are not coupled with OpenID Providers. OpenID has a discovery protocol which dynamically discovers the corresponding OpenID Provider, once an OpenID is given. SAML has a discovery protocol based on Identity Provider Discovery Service Protocol. With SAML2, the user is coupled to the SAML2 IdP - your SAML2 identifier is only valid for the SAML2 IdP who issued it. But with OpenID, you own your identifier and you can map it to any OpenID Provider you wish. SAML2 has different bindings while the only binding OpenID has is HTTP SAML2 can be either Service Provider (SP) initiated or Identity Provider (IdP) initiated. But OpenID always SP initiated. SAML 2 is based on XML while OpenID is not based on XML. Most of the application developed in last 3 years were only supporting OpenID Connect. 92% of the 8B+ authentication requests Microsoft Azure AD handed in May 2018 were from OpenID Connect enabled applications.
Putting the technical details aside, being quite late for the party, what I understand that the biggest difference between SAML and other auth standards (inc. OpenID) is that
SAML requires the Identity Provider (IDP) and the Service Provider (SP), to know each other before hand, pre-configured, static authentication and authorization. OpenId (+Connect) doesn't have such a requirement.
This is important for IDPs that want full control over who's accessing the data. Part of the standard is to configure what is provided to specific SPs.
For example, a bank might not want its users to access any services except some predefined ones (because of regulations or other strict security rules).
This doesn't mean that an OpenId IDP, cannot enforce such a restriction. An OpenID implementer can control access, but that's not the purpose of OpenID.
Other than the predefined, strict, static, access control difference, conceptually (not technically), OpenID Connect and SAML are similar.
Bottom line, if you're an SP, you should support what your customers require:
If your customer is an individual end user customers (using their google id for example), forget about SAML. Use OpenID Connect. If your customer is a bank that wants its employees to use your service and export only static list of data it will provide to your service, the bank will probably want you to support SAML. The bank might have an OpenID implementation with client restriction, which will be your lucky day :)
Both SAML and OpenID can act as identity provider (abbreviated IdP) i.e. decentralized authentication protocol(single sign-on identity).
The Security Assertion Markup Language (SAML) is a set of profiles for exchanging authentication and authorization data across security domains. In the SAML domain model, an identity provider is a special type of authentication authority. Specifically, a SAML identity provider is a system entity that issues authentication assertions in conjunction with an SSO profile of SAML. A relying party that consumes these authentication assertions is called a SAML service provider. Source
OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID Foundation. OAuth is for authorization protocol, rather than an authentication protocol and OpenID specifically designed as an authentication protocol. OIDC uses simple JSON Web Tokens (JWT), they are easier to consume by JavaScript.
SAML 2.0 OAusth2 OpenID Connect What is it? Open standard for authorization and authentication Open standard for authorization Open standard for authentication History Developed by OASIS in 2001 Deployed by Twitter and Google in 2006 Deployed the OpenID Foundation in 2014 Primary use case SSO for enterprise apps API authorization SSO for consumer apps Format XML JSON JSON
Follow WeChat
Success story sharing
