SAML Assertion

Imagine showing your student ID at the cinema box office. The cashier doesn’t verify it themselves — they trust the school that issued it. A SAML assertion works the same way. It’s a small digital document issued by a trusted authority that confirms: This person exists, they have successfully logged in, and they are allowed to do certain things. The online service you’re visiting reads this document and lets you in — without requiring its own username or password. SAML stands for Security Assertion Markup Language, meaning a language for security statements in a machine-readable format.

Why SAML assertions shape everyday business life

Large companies often use dozens of different software systems: one tool for email, one for payroll, one for project planning. Without SAML, every employee would have to create a separate account and manage a separate password for each of these services. With SAML, a single login is enough to gain access to all services. This principle is called Single Sign-On, or SSO for short.

The security benefit is considerable. Fewer passwords mean a smaller attack surface. The IT department can also centrally revoke access when an employee leaves the company — a single click instead of deleting thirty individual accounts. This is a practical reason why SAML is now standard in companies and government agencies.

How an assertion travels from A to B

The SAML process involves two main roles. The Identity Provider, or IdP, is the trusted authority that knows the user and issues the assertion — for example, a company’s login system. The Service Provider, or SP, is the service you actually want to use, such as a cloud application. The user themselves acts more like a messenger: they carry the assertion from the IdP to the SP without being able to open or alter it.

An assertion contains three types of statements. First: Who is this person? Second: When did they log in and how — with a password, with a second security check? Third: What are they allowed to do, which role or group do they belong to? For the SP to be able to trust the assertion, it is digitally signed. A signature is a mathematical checksum that reveals tampering. If someone has altered even a single character, the signature no longer matches.

Assertions are also time-limited. Each one contains a timestamp and an expiration date. An expired assertion is rejected by the SP. This prevents an attacker from reusing an intercepted assertion at a later time.

Where SAML assertions show up in everyday life

Anyone who logs into Microsoft 365 or Google Workspace at a school or university using their school account is usually experiencing SAML in the background. The school is the Identity Provider, Microsoft or Google is the Service Provider. The student only enters their password once at the school — and afterward gains access to all connected services without any further login.

In tech news, SAML often comes up in connection with data breaches or security vulnerabilities. In 2021, for instance, a vulnerability became known in several SAML libraries that allowed attackers to forge assertions by bypassing signature verification. Such incidents show how critical correct implementation is: SAML is only as secure as the software that implements it.

A common misconception is equating SAML with OAuth or OpenID Connect. All three solve similar problems, but in different ways. SAML is older, dating back to 2002, and is built on XML as its data format — a verbose, structured text format. OAuth and OpenID Connect, by contrast, rely on a more modern, more compact format and are more commonly used in mobile apps and public web services. In enterprise environments with existing infrastructure, however, SAML remains the dominant technology to this day.