The Security Assertion Markup Language (SAML), is an open standard that allows security credentials to be shared by multiple computers across a network. It describes a framework that allows one computer to perform some security functions on behalf of one or more other computers:

Authentication: Determining that the users are who they claim to be

Authorization: Determining if users have the right to access certain systems or content

Strictly speaking, SAML refers to the XML variant language used to encode all this information, but the term can also cover various protocol messages and profiles that make up part of the standard.

SAML 2.0 was introduced in 2005 and remains the current version of the standard. The previous version, 1.1, is now largely deprecated. SAMLDiffs has a great summary of the difference between the versions.

SAML is one way to implement single sign-on (SSO), and indeed SSO is by far SAML's most common use case.

What is a SAML provider?

In SAML lingo, a provider is an entity — generally, a server or other computer — within a system that helps the user access the services he or she wants. Systems that provide or consume SAML services are generically called service providers; the most important kind of service provider is an identity provider.

An identity provider is the entity within the system that makes sure the user really is who they claim to be — it provides authentication. It may also determine what services, if any, that user is authorized to access across various entities in the system. There are various implementations that can provide authentication services in line with the SAML standard — Salesforce can serve this role, for instance, and so can LDAP, RADIUS, or ActiveDirectory.

What is a SAML assertion?

A SAML assertion is the XML document by which all the information we've been discussing is transmitted from one computer to another. Once an identity provider has determined that you are who you say you are and have the right to access the content or services you're interested in, it sends a SAML assertion to the server that actually can actually provide those services to you. A SAML assertion may be encrypted for increased security.

For more on all these terms, check out the official SAML glossary from OASIS.

A SAML example

This all might seem kind of abstract, so here's a high-level example of how a SAML authentication transaction would play out. A graphical illustration is provided in Figure 1. The user agent would in most cases be a web browser.

Imagine you're the user in an environment with single sign-on and you're trying to get access to some resource on a server. The sequence of events goes like this:

You try to access the resource on the server, which in SAML terminology is a service provider. The service provider in turn checks to see if you're already authenticated within the system. If you are, you skip to step 7; if you're not, the service provider starts the authentication process. The service provider determines the appropriate identity provider for you and redirects you to that provider — in this case, the single sign-on service. Your browser sends an authentication request to the SSO service; the service then identifies you. The SSO service returns an XHTML document, which includes the authentication information needed by the service provider in a SAMLResponse parameter. The SAMLResponse parameter is passed on to the service provider. The service provider processes this response and creates a security context for you — basically, it logs you in — and then tells you where your requested resource is. With this information, you can now request the resource you're interested in again. The resource is finally returned to you!

You'll notice that a lot of this is pretty high level: for instance, there's no explanation of how SAML knows what the appropriate identity provider is, or how the identity provider determines that you're who you say you are. That's not just us leaving things out: the SAML standard doesn't define how these things happen, leaving IT lots of leeway on how to set things up. As noted above, for instance, multiple technologies can be used for the actual authentication piece; whether you choose Salesforce, LDAP, or something else, the SAML assertions will then carry the information that you have in fact been authenticated from one provider to another.

If you want a closer look at the guts of the messages being passed back and forth in a SAML transaction, check out the examples here from OneLogin. You can dig into the full XML code for the kinds of assertions being passed from the identity provider to the service provider in the scenario outlined above.

SAML vs. OAuth: What’s the difference?

OAuth is a somewhat newer standard than SAML, developed jointly by Google and Twitter beginning in 2006. It was developed in part to compensate for SAML's deficiencies on mobile platforms and is based on JSON rather than XML.

Other than SAML's less-than-stellar mobile support, what's the difference between the two? As we've seen, the SAML standard defines how providers can offer both authentication and authorization services. OAuth, on the other hand, only deals with authorization. OpenID Connect is an even newer standard, developed in 2014, that provides authentication services, and is layered on top of OAuth.

[ Related: What is OAuth? What security pros need to know about the open authorization framework ]

Another major difference is their use cases. While SAML theoretically was designed for use on the open internet, in practice it's most often deployed within enterprise networks for single sign-on. OAuth, by contrast, was designed by Google and Twitter for internet scale.

SAML tutorials: Some good places to learn more about SAML

Ready to learn more? Here are some great, in-depth SAML tutorials:

More on single sign-on and identity management: