SAML sign-in fails

SAML is the older of the two ways to hand sign-in over to an identity provider such as Microsoft Entra ID, Okta or Google Workspace. The provider signs a small XML document — an assertion — saying who the person is, and the browser posts it to us. We check twenty things about that document before we believe it. This article lists the refusal each check produces, what is wrong on the provider's side when it fires, and how to fix it.

The ten rejection strings, in one place

Every refusal is one of these ten, sometimes with a detail appended. If you have the log line, start here and read the matching section. If you do not, each section also describes what the fault looks like from your side — the setting at the provider that produces it — so you can usually work it out without us.

saml: malformed SAML Response
saml: SAML Response status is not Success
saml: signature verification failed
saml: signature does not cover the element it claims to
saml: response carries more than one assertion
saml: assertion audience does not include this service provider
saml: assertion recipient is not this endpoint
saml: assertion InResponseTo does not match the request
saml: assertion is outside its validity window
saml: assertion has already been consumed

Two more come from the signature layer: saml: unsupported signature or digest algorithm, and saml: signature verification failed: no pinned certificate, which means the provider record has no certificate on it yet.

Signature: the certificate is wrong, stale or absent

This is the most common failure after a provider rotates its signing certificate, and it is silent until the old certificate stops being used. The verifier resolves the signature properly — canonicalising the XML, following the reference, checking that the signature covers the element it claims to — so the failure modes are more specific than 'the signature is bad'.

More than one assertion, and duplicate identifiers

A legitimate response carries exactly one assertion; two is refused outright. This check exists because of an attack this product was once vulnerable to — appending a forged second assertion carrying a copy of the genuine signature, so that the reader took the last assertion while the signature check validated the first. If you see this rejection, either your provider is doing something unusual or somebody is testing your sign-in. It is not a configuration knob.

The related malformed cases, saml: malformed SAML Response: no assertion and ... root element is <something other than Response>, usually mean the wrong document reached the wrong endpoint — a provider configured with our metadata URL where the ACS URL was wanted.

Audience: the provider is talking to somebody else

The audience restriction names who the assertion is for. If it does not name us we refuse it, because otherwise any application your provider serves becomes a way into your Qorionix tenant. The companion message, ... : no AudienceRestriction, means the provider omitted the element entirely.

What to fix: the field at the provider is usually called Audience URI, Entity ID, SP Entity ID or Identifier. Set it to our service-provider entity ID exactly, including the scheme and any trailing path. It is published in our metadata document at GET /api/v1/saml/metadata — copy it from there rather than typing it. A trailing slash counts.

Destination and recipient: the assertion was addressed elsewhere

Two checks in two places in the document, one underlying misconfiguration: the provider is posting to a URL that is not our assertion consumer service.

• saml: assertion recipient is not this endpoint: Response Destination "https://old.example.com/saml/acs" — the Destination attribute on the response.
• saml: assertion recipient is not this endpoint: SubjectConfirmationData Recipient "https://old.example.com/saml/acs" — the Recipient attribute inside the subject confirmation.

What to fix: the field is usually called Single sign-on URL, ACS URL, Reply URL or Assertion Consumer Service URL, and it must be our ACS endpoint taken verbatim from our metadata. The commonest cause is a provider application copied from another environment and never re-pointed. Both attributes come from the same setting at nearly every provider, so fixing one fixes both.

InResponseTo: solicited and unsolicited sign-ins

InResponseTo says which of our requests an assertion answers, and its two failures pull in opposite directions.

• saml: assertion InResponseTo does not match the request: got "_abc", want "_def" — the assertion answers a different sign-in attempt. Usually a stale tab, a back-button re-post, or two sign-ins started in parallel. Fix: start a fresh sign-in; if it is reproducible, look for a provider caching responses.
• saml: assertion InResponseTo does not match the request: unsolicited assertion carries InResponseTo "_abc" — the sign-in began at the provider, so we sent no request, but the assertion claims to answer one. Fix: configure the provider-initiated flow so it does not populate InResponseTo when there was no request. An assertion answering a request we never sent is what an attacker replays, which is why this is refused rather than ignored.

NotBefore, NotOnOrAfter and clock skew

An assertion carries a window in which it is valid, and we allow two minutes of clock skew either side. The sibling messages are saml: assertion is outside its validity window: bearer confirmation expired at <time> and, on an unparseable value, saml: malformed SAML Response: NotOnOrAfter "...".

What to fix: almost always the identity provider's clock, not ours. Check it against a network time source. Two minutes is a deliberate allowance: wider, and a replayed assertion stays usable for longer than it should. If your provider issues very short windows — some issue thirty seconds — a slow corporate proxy can also push a legitimate assertion out of its window, and the fix is to lengthen the window at the provider rather than to widen our skew.

Two structural cases sit in the same family: saml: malformed SAML Response: assertion has no Conditions and saml: malformed SAML Response: no usable bearer SubjectConfirmation. Both mean the provider omitted a required element. Every mainstream provider emits them; a heavily customised one may not.

Replay: the assertion has already been used

Each assertion may be used exactly once, and consumed assertions are recorded in the database, scoped per provider, so a second presentation is refused no matter which of our servers receives it. An in-memory record would have degraded that guarantee to once per server per window, which is not single use at all.

When this fires legitimately: somebody refreshing the page after signing in, or a browser re-posting a form. Tell them to start again from the sign-in link rather than reloading. When it does not: if you see it repeatedly for one account without a matching user action, treat it as a replay attempt and look at the source addresses in your provider's logs.

A valid assertion for somebody who is not in your organisation

The last check is not about the document at all. Once the assertion verifies, the subject has to resolve to an active member of the organisation that owns the provider record. A perfectly signed assertion naming somebody who belongs to a different tenant is refused, and so is one naming somebody who has been deactivated.

This check is what makes a federation trust safe to hold: without it, registering a provider would be the same as being able to sign in as anyone in any tenant. It is also why adding one is a privileged action — a provider whose assertions become logins for your tenant is a second front door. Only roles holding the SSO write permission can create one, and the metadata-parse helper is gated at the same level because it makes us fetch a URL on your behalf.

Before you contact us

Three checks catch nearly everything. Re-copy the entity ID and ACS URL from GET /api/v1/saml/metadata by clipboard rather than by hand; that covers most first-time failures. Replace the signing certificate from the provider's current metadata and confirm it is on SHA-256; that covers most failures that appear suddenly on a working configuration. Then compare both clocks. If none of those helps, send us the timestamp and your organisation identifier and we will find the log line naming the check that failed. The two malformed-input cases — invalid form and missing SAMLResponse, both 400 — are visible to you directly and mean the post carried no assertion at all.

• Single sign-on with SAML — the setup guide.
• OIDC sign-in fails — the newer protocol, and the one to prefer for a new integration.