DWS Blog | 11.11.2025 Ep 18

November 11, 2025

Episode 18

I've Got a Golden Ticket: SAML Misconfigurations and Attacks

Author: Noah Gearhart

Source code: https://github.com/ngearhart/website/blob/main/src/content/blog/post1-sso.md

Misconfigured Single Sign-On (SSO) can compromise your service by handing out golden tickets to attackers. Let's learn about the basics of SSO-enabled services, demonstrate some attacks, and discover how to prevent your service from being similarly compromised.

This post has a companion talk given by me at BSides NoVA 2025. See the video at: https://www.youtube.com/embed/RLvz8-2tjmg

SSO Crash Course

There are two key concepts within SSO: Identity Providers (IdPs) and Service Providers (SPs). Identity Providers serve as the source of truth, the origin for all information about users, their roles, and their group membership. This includes attributes like first and last name, and login credentials like passwords and multifactor tokens.

Common Protocols

The two common protocols for SSO are OAuth (2.0 and 2.1, not an acronym) and Security Assertion Markup Language (SAML) 2.0. Both protocols establish procedures for IdPs and SPs to communicate. Although they are similar in capability, in my experience, OAuth tends to be more popular for open-source integrations and SAML tends to be more popular around the Microsoft ecosystem. One notable difference is that SAML payloads are fully transparent to the user, which is why we will focus on that for the rest of this post.

SAML Basics

The main idea behind SAML is the Assertion. A SAML Assertion asserts something as true, with certain mechanisms to prove its validity.

There are two "flows" by which SAML authentication can occur; that is, there are two mechanisms that allow a user to log in. Let's go through each, as both of them are susceptible to the attacks in question.

IdP-Initiated Login

Some IdPs provide a dashboard that companies may use as an intranet portal or central location for a bunch of links to company services. For example, Okta provides this out of the box. When the user clicks one of the links, they can be immediately logged in using IdP-initiated login.

For these vertical timeline diagrams, I would recommend watching the companion talk for a more direct walkthrough. I understand these flows are not very friendly, but they really are the best way to understand these protocols.

The key part of this flow is the step where the user submits the <SAMLResponse /> near the end. That is strange, right? How does the service provider know the user did not just submit garbage? Hold on to that thought: That is the principle idea behind the attacks we will explore later.

SP-Initiated Login

This flow, although containing more steps, is more likely what you imagine if you have experience using SSO-powered services. In SP-initiated login, the user first tries to connect to the service, but immediately gets redirected to the IdP to fill in their credentials. After that, this flow is the same as IdP-initiated login.

Once again, we have that key step where the SP trusts the <SAMLResponse /> that the user sends.

SAML Integrity

Finally, let's answer our key question. How can the service provider trust the <SAMLResponse />? The protocol uses two mechanisms: Lifetimes and signatures.

SAML Lifetimes

The first and more simple integrity mechanism is Lifetimes. Every <SAMLResponse /> can include NotBefore, NotOnOrAfter, and IssueInstant attributes which instruct the SP to fail the payload if the current time is not within those parameters. Every SP must recognize and act on these parameters to be spec-compliant. However, defeating these attributes is extremely simple, as we can just rewrite them with new, valid timestamps.

Additionally, for SP-initiated login only, the SP can include a "Solicitation Identifier," called an ID attribute in the <AuthnRequest /> and InResponseTo attribute in the <SAMLResponse />, which uniquely represents this one login instance. Once again, this must be verified to be spec-compliant. This is slightly more tricky to defeat, as we have to make a prerequisite anonymous call to the service to have it generate a fresh <AuthnRequest /> for us. Then, we can extract the solicitation ID out of that request and inject it into our counterfeit response. But, if the service allows IdP-initiated login, it may choose to ignore the solicitation ID, allowing us to skip this step.

Finally, we have the <OneTimeUse /> condition. The intention for this is to have the SP track whether this response (identified by its ID attribute) has been submitted previously. If it has, it rejects it. Unfortunately, unlike the two above mechanisms, this condition is stateful. That is, the SP must use a stateful storage mechanism to correctly enforce one time use. For that reason, some SAML SP implementations ignore the <OneTimeUse /> condition. This may be dubiously spec-compliant, but to the end user, it still "works." In my opinion, this should not be viewed as anything but a low-severity weakness, as remediating it would not meaningfully mitigate the attacks I will demonstrate later.

SAML Signatures

SAML also uses the XML Dsig standard to sign parts of the <SAMLResponse /> payload. To create a signature, the signing entity (whoever is generating the payload) picks an XML element and hashes a serialized version of it and its children. Then, it calculates the signature based on this hash and its private key, and attaches this as a new element in the XML document.

As a quick side note, this "put the signature as part of the payload" strategy is unusual for this type of protocol. Most integrity protocols hash and sign the whole body and include the signature separately. This strategy is generally considered weak because parts of the payload may still be modified and preserve a valid signature. The recent OpenPGP.js vuln, CVE-2025-47934, was caused by exactly this. However, the attacks we are exploring do not exploit this weakness.

Sample Payload

Let's look at a sample payload. This is a full, real SAMLResponse.

None

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://saml-demo.noahgearhart.com/saml/acs/" ID="ID_5302d583-16b2-452d-8cf9-e7b08a8970c7" InResponseTo="ONELOGIN_135e2dd36cdd4cd1fad82eeebfceb45e02418e5f" IssueInstant="2025-09-29T00:36:22.435Z" Version="2.0">

<saml:Issuer>

https://keycloak.noahgearhart.com/realms/Demo

</saml:Issuer>

<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<dsig:SignedInfo>

<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<dsig:Reference URI="#ID_5302d583-16b2-452d-8cf9-e7b08a8970c7">

<dsig:Transforms>

<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</dsig:Transforms>

<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<dsig:DigestValue>

lnLQwhAgSQ9y5oD5BEo3NqvSbyLQNEDnLVXacYvEkU8=

</dsig:DigestValue>

</dsig:Reference>

</dsig:SignedInfo>

<dsig:SignatureValue>

D8tFH6JUrXt1ZQPAaLUG7OoNfNkN8HiGzKS6iDIDrhIxfTJY/wxejBYEeBPcSfVCiWZ3c6I0sARUnWPERjZ8mtkJlfbFdhPvl0XYZjv0T94oF9ijw7jYq2jAuH9lnbn9jY3/kuafVaXtHxYE/666xWnJ4bYZ4Y6/ZWhM8oPu+IzSvnQ1dG/T9/QmLpEGYVSFn3TJZBzy9yTLC3Mar3IJDGA0J9L4CL7JprCRK9p5in+kTOC0u6ILctscAZrPIDH6a0JmT3kI+MbjK+GrUA2DC+VDG6v23R0RhFzS3/WU06ejf2yFgZ5EzF/WZ+6xJNcWSKwNm8/UuaRjkI5AA+i6MA==

</dsig:SignatureValue>

<dsig:KeyInfo>

<dsig:X509Data>

<dsig:X509Certificate>

MIIClzCCAX8CBgGZX7Cq9jANBgkqhkiG9w0BAQsFADAPMQ0wCwYDVQQDDAREZW1vMB4XDTI1MDkxOTAxNTUzN1oXDTM1MDkxOTAxNTcxN1owDzENMAsGA1UEAwwERGVtbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALWrPZNUDmavVicPUh9+bOlw4QTgPDAZ01ktIV0ApeLxaN8Nfdy7Q0D7EkvWZhu76LZP4rCmbwzFQ78pqUaYG5iwHRbaErg+wFx0Xvne9vBvCC51tDdAk3FRnTZiQcE0FpZcr9KAesKFv68YacWDpuyBLadzqNykflJo8rHDnxOGXZGIHt28/zwc3Z3Pj9cmROc9/9D+LCa049SLJoLGu39m7W3lY4Xr4YxWMkc/JBsROA2FuQe40P/U1A1qHVYFP8wjjJW7aWZoQQHvpwZ8/grz0Ozi0JdjLLNHjyYtwk5XhvgU28abjGRCZ+wtGzWO9dy7FCcVrjFzR2fVAzifm+sCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAUiA9LfZSyOtTCiqvsRkYPQz1P6jy2ied5YbwnuRDWZJ2Zy9wUWzKJrVuWcPYNo4Jt6vFWyjrm9PmgxqmIdtCxobu3V+tFokzTvu9cbLmRb+oDjiN30eAgwug61El1NJ2mUvVjuD1vJtQ25uiOiHQOsmMNDhIHMQpeoryXnvFT7iwq5YAThfPBV0eC+cDTZfe4lz8IbST8efGtwzZmV+WlufP0wc7cIYrOQCyuZHTM3VzCuRjI8n7YPB4UHLDVRp8MWEf26/tFsePgzPayqz0yzP9eeK5VM2N1iD0+Y2QtS4L2yxMD+cLgiO1U+FgmxppvdWfxuX/UeydZ+xrBBTE5g==

</dsig:X509Certificate>

</dsig:X509Data>

</dsig:KeyInfo>

</dsig:Signature>

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</samlp:Status>

<saml:Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_f7bc3465-deed-4cdb-86b6-0077e65b8064" IssueInstant="2025-09-29T00:36:22.431Z" Version="2.0">

<saml:Issuer>

https://keycloak.noahgearhart.com/realms/Demo

</saml:Issuer>

<saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">

noah.user

</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData InResponseTo="ONELOGIN_135e2dd36cdd4cd1fad82eeebfceb45e02418e5f" NotOnOrAfter="2025-09-29T00:41:20.431Z" Recipient="https://saml-demo.noahgearhart.com/saml/acs/"/>

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore="2025-09-29T00:36:20.431Z" NotOnOrAfter="2025-09-29T00:37:20.431Z">

<saml:AudienceRestriction>

<saml:Audience>

https://saml-demo.noahgearhart.com

</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

<saml:AuthnStatement AuthnInstant="2025-09-29T00:36:22.435Z" SessionIndex="8c82c79c-f799-432d-a629-9b753c35e9d8::5bb2a71b-b81a-4b11-8c31-0c37bb3a31e1" SessionNotOnOrAfter="2025-09-29T10:36:22.435Z">

<saml:AuthnContext>

<saml:AuthnContextClassRef>

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

<saml:AttributeStatement>

<saml:Attribute FriendlyName="uid" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">