Note (October 2026): An earlier version called SSO outdated, described SAML as a separate layer added after SSO and said the test tool scans networks; SAML is one protocol that delivers SSO, and a SAML test checks one sign-in exchange at a time.
Single sign-on (SSO) lets a user log in once and reach several applications without logging in again. SAML (Security Assertion Markup Language) is an open, XML-based OASIS standard that delivers SSO: an identity provider authenticates the user and sends a digitally signed assertion to each application, which never sees the password. Free tools such as the SAML 2.0 Test Service Provider and Mock SAML let IT teams test a SAML setup with test accounts.
Key Takeaways
- SSO is the goal (one login for many apps); SAML is one protocol that delivers it, alongside OpenID Connect and Kerberos.
- SAML 2.0 has been an OASIS standard since March 2005 and uses three roles: principal, identity provider and service provider.
- With SAML, the password goes only to the identity provider; apps receive signed XML assertions.
- SSO is a single point of failure, so protect the identity provider with multi-factor authentication.
- Free SAML test tools are for test accounts only; they check one sign-in at a time and do not scan networks.
Single sign-on (SSO) and SAML are two of the most common terms in workplace identity management, and a company’s IT team needs to understand both before connecting business apps to a central login. In this article, we’re going to talk about a few IT elements that your workers should know about, including SSO, SAML, and a free application you can utilize if you want to test them.
What Precisely are SSO and SAML?
Before we get into free SSO and SAML testing apps, we should define each of these terms, so you know what they mean. We’ll start with SSO, which stands for single sign-on.
Single sign-on is an authentication approach that lets a user log in once and then reach several related applications without entering credentials again. Larger organizations with many business apps tend to benefit the most, because each employee otherwise needs a separate login for every app.
SAML is one of the main protocols that makes single sign-on work between separate systems. SAML stands for security assertion markup language. It is an open standard through which parties can exchange authentication and authorization data.
The most common time that your business might use SAML is when you have both an identity provider and a service provider, and you’re trying to authenticate between those two. It’s an XML-based language that’s most useful for the type of security assertions we’re describing.
The SSO and SAML Connection
SSO is not outdated technology. SSO is the goal (one login for many apps), and SAML is one of several ways to deliver it; others include OpenID Connect and Kerberos.
SSO and SAML are therefore not two separate layers where one is added on top of the other. How secure a SAML-based SSO setup is depends largely on how well the identity provider checks who is logging in.
SAML does not send a worker’s password to each application. The password goes only to the identity provider, and the application instead receives a digitally signed XML assertion, a form of what IT professionals would call secure tokens. This reduces the number of places where a password can be exposed, although it does not remove risk on its own.
Fewer passwords is a realistic goal, but no protocol guarantees secure sign-ins. Because SAML moves the password check to one identity provider, the protection on that identity provider, such as multi-factor authentication, largely decides how safe every connected application is.
How Much Does SSO Matter?
SSO matters because it reduces the number of passwords each employee has to create and remember, which cuts down on password fatigue. They are there to reduce cyberattacks, many of which hackers perpetrate against networks with weak passwords and few other security protocols in place.
Fewer passwords also means fewer password-related help-desk requests, one of the IT cost savings commonly listed for SSO. Breaches can often occur if a single repeated password leaks. The trade-off is that SSO creates a single point of failure: if a user’s identity-provider credentials are stolen, every connected application is exposed, which is why security guidance pairs SSO with multi-factor authentication.
SSO and SAML Testing
One other thing to understand, though, is that you can’t simply install an SSO and SAML protocol and then hope for the best. You need to test each SAML connection, when it is first set up and after any configuration change, to confirm that the identity provider and the application exchange assertions correctly.
This is where certain apps or services come into play. There’s great news, though, especially for the thrifty business owner: some of them are free.
A SAML login involves three parties, which the standard calls roles. The first is the service provider (SP), meaning the web app. The second is the principal, usually the person trying to log in. The third is the identity provider (IdP), which authenticates the user and issues the assertion.
One free option is the SAML 2.0 Test Service Provider at sptest.iamshowcase.com, a demonstration site that stands in for the application so you can check that your identity provider works. Its own home page says it trusts every identity provider and is suitable for demonstration purposes only, so use test accounts rather than real user data.
How Does the Testing Work?
The SAML Test Service Provider can speed up SSO testing. The simplest starting point is IdP-initiated SSO, in which your identity provider sends an unsolicited SAML assertion to the test site. The test site publishes its own SAML metadata file, which you load into your identity provider.
SAML metadata is an XML document that describes a SAML deployment, such as its entity ID, its protocol endpoints and the public keys used to check signatures; it is not a record of network activity. In your IdP, you create a generic SAML connector from the test site’s metadata.
When the IdP sends an assertion, the test site parses it and displays the attributes and authentication details it contains. The site also offers attribute-handling and color-theme options.
The System Will Create a Unique URL
For SP-initiated testing, you import your IdP’s metadata into the test tool, and it creates a unique URL that you use for logins throughout testing. Opening that URL sends a SAML AuthnRequest to your IdP, which then returns a SAML response to the test site.
The URL will map back to the IdP. This shows exactly which attributes and authentication details your identity provider releases for a test user. You should be able to find out how well it works and whether you need to change anything in the future.
You might have to repeat this metadata import process during the testing. You also need administrator access to your IdP, because the connector settings are changed there.
A SAML test does not scan your network. It checks one sign-in exchange at a time, so you can repeat logins quickly or step through them slowly while you change settings.
You can do this test for free with two goals in mind. One is to confirm that a new or changed SAML connection works as intended. The other is to troubleshoot a connection that fails, by seeing exactly what the identity provider sends.
Either way, a free SAML test tool is a low-cost way to check SSO before real users depend on it. It is not a security audit or a penetration test, so treat it as one step alongside multi-factor authentication on the identity provider.
How Does SAML Single Sign-On Work Step by Step?
A SAML single sign-on login passes messages between the service provider and the identity provider through the user’s browser. In the common SP-initiated flow, the steps are:
- The user opens the application (the service provider).
- The service provider sends a SAML AuthnRequest to the identity provider through the browser. With the HTTP Redirect binding, the message is deflated, Base64-encoded and URL-encoded, in that order, and placed in a SAMLRequest parameter.
- The identity provider authenticates the user, for example with a password plus a second factor.
- The identity provider returns a Base64-encoded SAMLResponse, usually through an HTML form posted by the browser, containing an assertion with a digital signature and a Conditions element that says when the assertion is valid.
- The service provider checks the signature with the identity provider’s public key from the shared metadata, checks the conditions and logs the user in.
Because SAML messages are encoded rather than encrypted by default, IT teams often decode them while troubleshooting. A URL decoder and a Base64 decoder turn a captured SAMLRequest or SAMLResponse value back into readable XML (a redirect-binding request also needs to be inflated). Use only test accounts when pasting captured messages into any tool.
What Is the Difference Between SAML, OpenID Connect and Kerberos?
SAML, OpenID Connect and Kerberos are all ways to deliver single sign-on, but they come from different eras and use different formats.
| Protocol | Published by | Key date | Data format | Typical use |
|---|---|---|---|---|
| SAML 2.0 | OASIS Security Services Technical Committee | Standard since March 2005 | XML assertions | Browser-based SSO between an identity provider and business web apps |
| OpenID Connect | OpenID Foundation | Published February 2014 | JSON over a RESTful HTTP API | An authentication layer on top of OAuth 2.0 |
| Kerberos | Ticket-based network protocol | Not covered here | Tickets | Ticket-granting tickets for SSO inside a network, including Integrated Windows Authentication |
What Is the Difference Between IdP-Initiated and SP-Initiated SSO?
SAML 2.0 supports both IdP-initiated and SP-initiated single sign-on, a flexibility earlier SAML versions did not offer.
| Flow | Where the login starts | What happens |
|---|---|---|
| IdP-initiated | The identity provider’s portal | The IdP sends an unsolicited SAML assertion to the application |
| SP-initiated | The application | The application sends a SAML AuthnRequest to the IdP, and the IdP replies with a SAML response |
Which Free Tools Can Test SAML SSO?
Several free tools let IT teams test SAML SSO without connecting a real business application. All of them are for testing only.
| Tool | What it simulates | Notes (as of October 2026) |
|---|---|---|
| SAML 2.0 Test Service Provider (sptest.iamshowcase.com) | A service provider (the app side) | Supports IdP-initiated and SP-initiated SSO and displays received attributes; trusts all identity providers and describes itself as a test and demo site, not a secure site |
| Mock SAML (mocksaml.com, by BoxyHQ) | An identity provider | A free SAML 2.0 identity provider for testing SSO integrations; provides downloadable metadata and is marked “Not for production use” |
| SAMLTool.com (by OneLogin) | Online SAML developer tools | Online SAML testing and debugging tools plus open-source SAML toolkits for PHP, Python and Ruby, with Java and .NET toolkits in beta |
SAML SSO Testing Checklist
- Create a test user in your identity provider; never use a real employee account on a public test site.
- Exchange metadata: load the test tool’s metadata into the IdP, or your IdP’s metadata into the test tool, so each side knows the other’s entity ID, endpoints and public key.
- Run an IdP-initiated login from the IdP portal and confirm the test site shows the expected attributes.
- Run an SP-initiated login from the test tool’s unique URL and confirm the AuthnRequest and response complete.
- Check the authentication details in the assertion, for example which authentication method was used.
- Repeat the test after every change to the IdP connector before switching the real application over.
What Are the Main Risks of SSO?
The main risk of SSO is that it becomes a single point of failure. Once a user is authenticated, stolen identity-provider credentials can open every connected app, and an identity-provider outage can block access to all of them at once. Pairing SSO with multi-factor authentication, such as one-time password tokens or smart cards, reduces the credential risk. For the wider picture, see these guides on how to improve user authentication, ways to increase password management security and how to check if your passwords have been compromised.
Frequently Asked Questions
Is SSO the same as SAML?
No. SSO (single sign-on) is the result: one login gives access to several applications. SAML is one protocol that delivers SSO by passing signed XML assertions from an identity provider to a service provider. OpenID Connect and Kerberos are other ways to deliver SSO.
Is SAML outdated?
SAML 2.0 became an OASIS standard in March 2005 and remains the current major version of SAML. Many newer apps use OpenID Connect, published in February 2014, but SAML 2.0 remains a standard option for browser-based business SSO.
What is an identity provider (IdP)?
An identity provider is the SAML role that authenticates the user and issues assertions about that user. The service provider (the application) relies on those assertions to decide whether to grant access.
What is SAML metadata?
SAML metadata is an XML document that describes a SAML identity provider or service provider. At minimum it shares the entity ID and protocol endpoints, and it usually carries the public keys used to verify signatures, so the two sides can trust each other.
Is it safe to use a free SAML test site?
A free SAML test site is fine for test accounts but not for real user data. The SAML 2.0 Test Service Provider says it trusts every identity provider and is not a secure site, and Mock SAML is marked “Not for production use.”
Does SAML protect against stolen passwords?
SAML keeps passwords away from individual applications, but it does not stop an attacker who steals the identity-provider login. That is why SSO is commonly paired with multi-factor authentication on the identity provider.
