SAML Timing Brief
{{ summaryPrimary }}
{{ summaryLine }}
{{ summaryBand }} Fail {{ statusCounts.Fail }} Warn {{ statusCounts.Warn }} Pass {{ statusCounts.Pass }} {{ sourceFormatLabel }} {{ profileBadge }}
Conditions SP clock Bearer Skew {{ samlClockSkewLabel }}
Name the SAML integration or ticket being reviewed.
Make the capture shape explicit so XML excerpts, POST SAMLResponse values, and OAuth assertion parameters do not get interpreted the same way.
Pick the relying-party decision being reviewed: SP-initiated SSO, IdP-initiated SSO, OAuth bearer assertion, or timing-only forensic excerpt.
Use the response captured at the service provider or the decoded assertion excerpt that contains timing attributes.
{{ sourceStatusLine }}
This is the relying-party clock used for NotBefore, NotOnOrAfter, and SessionNotOnOrAfter checks.
Use strict or exact modes for incident replay, and standard tolerance for normal SSO troubleshooting.
{{ clockSkewLabel }}
Use the verifier-side skew policy, commonly 60 to 300 seconds for SAML integrations.
seconds
{{ assertionWindowLabel }}
Short assertion windows reduce replay exposure and make clock drift easier to isolate.
minutes
{{ confirmationWindowLabel }}
This catches bearer confirmation windows that outlive the intended replay boundary.
minutes
Use strict delivery for production SP acceptance, balanced review for legacy SSO, or timing-only when the excerpt lacks delivery context.
SessionNotOnOrAfter is IdP session evidence, not assertion expiry; choose how much it should influence findings.
{{ replayCacheLabel }}
Keep used assertion IDs at least as long as the accepted NotOnOrAfter evidence remains usable.
minutes
{{ sessionHoursLabel }}
Use this only when your relying party expects bounded IdP session lifetime evidence.
hours
Warn when Conditions omit NotBefore
Most Web SSO assertions include both bounds; leave on for production review evidence.
{{ header }} Copy
{{ cell.text }} {{ cell.text }}
No timing rows available
{{ emptyTableMessage(tab.key) }}
Tags: Encoding, Security
JWT Decoder Inspect a compact or Bearer JWT locally, read claims, and review timing, issuer, audience, signature, TTL, and sensitive-claim warnings.
Morse Code Generator Encode text or TXT files into Morse code with unknown-character checks, WPM and Farnsworth timing, playback, timeline charts, and WAV audio.
Certificate Renewal Window Calculator Plan TLS certificate renewals from population, validity, lead time, spread, daily capacity, retry reserve, and safety buffer before expiry.
Certificate Inventory Expiry Checker Review certificate inventory CSV rows in your browser, rank expiry urgency, owner gaps, manual renewal risk, and public TLS lifetime findings.
Customize
Advanced
:

A SAML sign-on failure can look like a bad certificate, wrong endpoint, or broken username mapping when the real problem is time. The identity provider issues an assertion with its own clock, the relying party checks it with another clock, and browser delivery adds a short period where bearer evidence can be replayed if it is not bounded tightly. A few minutes of drift can make a login appear premature. A broad expiry window can let an old capture remain acceptable longer than the service provider's replay controls were meant to cover.

Security Assertion Markup Language, usually shortened to SAML, separates the identity provider that authenticates a user from the service provider that accepts the resulting assertion. In the common web single sign-on flow, bearer confirmation means the assertion is accepted because it arrives through the expected browser handoff to the right recipient. Timing is therefore part of the trust decision, alongside signature validation, issuer trust, audience restriction, destination binding, request correlation, and replay-cache enforcement.

The timestamps in a SAML response do not all answer the same question. Treating them as one general expiry value is a common source of false rejects and unsafe accepts.

Field or signal Plain meaning Common mistake
IssueInstant When the identity provider issued the assertion. Using it as the acceptance start without checking Conditions.
NotBefore The earliest instant the assertion should be accepted when the value is present. Ignoring clock drift when an otherwise fresh login is rejected as too early.
NotOnOrAfter The exclusive upper bound. At that exact instant, the assertion is already expired. Treating the boundary as inclusive and accepting an assertion at the expiry timestamp.
SubjectConfirmationData Bearer delivery evidence, often with recipient, request correlation, and its own expiry. Assuming bearer expiry and assertion Conditions are always identical.
AuthnInstant and SessionNotOnOrAfter Authentication-session evidence from the identity provider. Reading session lifetime as the assertion replay lifetime.
Timeline diagram comparing a verifier clock with assertion Conditions, bearer delivery, IdP session evidence, and replay-cache retention.

Clock skew is the operational compromise between exact timestamp checks and imperfect infrastructure. Identity providers, service providers, proxies, and log collectors should run on synchronized UTC clocks, but small differences still show up during incident review. A narrow skew allowance catches drift quickly. A wide allowance can reduce nuisance failures, but it also stretches the period in which a captured bearer assertion may pass the verifier's time check.

Good timing evidence narrows the investigation. It can show whether an assertion was not yet valid, already expired, missing a usable upper bound, or configured with a replay window that is too long. It cannot prove that the assertion should be trusted. Signature, issuer, audience, recipient, destination, request ID, decryption, and live replay-cache behavior still need to be verified in the relying-party system.

How to Use This Tool:

Use the checker with the same capture shape, reference clock, and relying-party policy that mattered during the login or incident.

  1. Enter a Partner label for the IdP, SP, tenant, ticket, or integration being reviewed. Use a label that will still make sense when the exported evidence is read later.
  2. Choose Source mode. Auto-detect accepts decoded XML, base64 SAML payloads, HTML form fields, query strings, SAMLResponse values, and OAuth assertion values. Raw XML, SAMLResponse, and OAuth modes intentionally fail when the pasted capture does not match the selected shape.
  3. Select the Review profile that matches the relying-party decision: SP-initiated Web SSO, IdP-initiated Web SSO, OAuth SAML bearer assertion, or a timing-only forensic excerpt. The profile changes delivery expectations, request-correlation severity, expiry fallback behavior, and session handling.
  4. Paste the assertion or response, load a sample, drop a text/XML file, or browse for a SAML source file under 1 MB. Parsing notes call out invalid XML, encrypted-only responses, source-shape mismatches, decoded base64, and captures that do not expose timing attributes.
  5. Set Reference UTC time when recreating an incident. Leaving it blank uses the browser's current UTC clock, which is useful for a current response but misleading for a historical capture.
  6. Set Clock skew policy, assertion and bearer window caps, Bearer confirmation policy, Session evidence policy, replay-cache horizon, and maximum IdP session duration to match the verifier or the policy being tested.
  7. Read Timing Control Matrix first. Confirm the parsed dates in Timestamp Ledger, the selected assumptions in Policy Profile Ledger, and the visual relationship between the reference clock and bounded windows in SAML Timing Window Chart.

Interpreting Results:

Reject now means the selected policy found a hard timing problem, such as an assertion that is not yet valid, already expired, missing a required upper bound, carrying a reversed interval, or lacking required bearer evidence. Treat Fail rows as acceptance blockers until the assertion, clocks, capture source, or verifier policy has been corrected.

Review timing means the capture is parseable but not clean enough for a simple timing pass. Common causes include intentionally wide skew, assertion or confirmation windows beyond local policy, optional-but-expected fields that are missing, session evidence that does not match local expectations, or replay-cache coverage shorter than the accepted validity window. Usable now only means the visible timing rows pass under the selected policy; it is not a full SAML approval.

  • Timing Control Matrix lists each decision row with status, severity, observed value, evidence, and recommended action. Work through Fail rows before treating Warn rows as policy tuning.
  • Timestamp Ledger is the audit trail for parsed dates. Compare IssueInstant, Conditions NotBefore, Conditions NotOnOrAfter, bearer confirmation expiry, AuthnInstant, and SessionNotOnOrAfter against the chosen reference time.
  • Policy Profile Ledger records the capture source, review profile, skew allowance, bearer policy, session policy, replay-cache horizon, and window caps that shaped the decision.
  • SAML Timing Window Chart plots bounded Conditions, bearer, and session windows around the reference marker. A long bar past the marker can indicate replay exposure even when the current reference time still passes.
  • JSON and table exports help preserve review evidence. They do not replace signature validation, issuer trust, audience checks, destination and recipient checks, request binding, decryption, or server-side replay-cache inspection.

Technical Details:

SAML Conditions define the main validity interval for an assertion. NotBefore is the optional lower bound. NotOnOrAfter is the upper bound where the assertion has expired, so an assertion at that exact instant is outside the interval. When either bound is omitted, the missing side is unspecified under the core rules, but many relying-party policies require an explicit expiry because bearer assertions without a clear end are hard to defend during replay review.

Bearer confirmation adds delivery evidence to the subject. In Web Browser SSO, the bearer confirmation data normally points to the assertion consumer service and, for an SP-initiated response, links back to the authentication request. OAuth SAML bearer use is different: a single assertion is presented to a token endpoint, and a suitable bearer confirmation expiry may bound the usable assertion when Conditions do not provide the same upper limit.

Authentication-session timestamps are related but separate. AuthnInstant records when the principal authenticated at the identity provider, and SessionNotOnOrAfter can describe the IdP session lifetime. They help explain reauthentication behavior and long-lived sessions, but they do not make an expired assertion valid again.

Formula Core

Reference-time validation uses a symmetric skew allowance around the relying-party clock. The lower-bound comparison tolerates a small identity-provider clock lead. The upper-bound comparison tolerates a small relying-party clock lead. Both comparisons must stay bounded because the same leeway also affects replay exposure.

R + s ≥ B , R - s < E d = E-B 60000

R is the reference UTC time in milliseconds, s is the configured skew allowance in milliseconds, B is the effective lower bound, E is the effective expiry, and d is the interval duration in minutes. The upper-bound operator stays strict because NotOnOrAfter is exclusive.

A concrete substitution shows the skew effect. If the reference time is 10:00:00Z, skew is 300 seconds, NotBefore is 10:04:00Z, and NotOnOrAfter is 10:10:00Z, then R + s reaches 10:05:00Z and the assertion is not rejected as too early. At a reference time of exactly 10:10:00Z, R - s is 10:05:00Z, so the expiry side still passes during the skew allowance even though the nominal expiry instant has arrived.

Rule Core

Review area Checked signal Why it changes the result
Capture parsing XML text, base64 SAML payload, SAMLResponse field, OAuth assertion value, or timing excerpt. Invalid XML, encrypted-only responses, compressed or binary payloads, and profile/source mismatches block useful timing review.
Response context Response wrapper, Destination, and response-level request correlation. Web SSO profiles need delivery context that a bare assertion excerpt may not contain.
Conditions NotBefore, NotOnOrAfter, and interval order. Missing or reversed bounds can fail or warn depending on the selected profile and local policy.
Current-time validation Reference UTC time adjusted by the configured skew allowance. Assertions fail when the skew-adjusted reference clock is still before the lower bound or at or after the effective expiry.
Assertion lifespan Conditions start to Conditions end, with issue time used as the practical start when the lower bound is absent. Windows beyond the configured maximum assertion lifetime warn because they increase replay exposure.
Bearer confirmation Bearer method, Recipient, InResponseTo, optional lower bound, and bearer NotOnOrAfter. Missing delivery evidence, expired confirmation, mismatched recipient, and confirmation windows that outlive Conditions can change severity.
Replay-cache horizon Assertion ID and the effective accepted validity window. Used assertion IDs should be retained at least as long as the accepted validity period when replay evidence is part of the review.
Authentication session AuthnInstant, SessionNotOnOrAfter, and the configured session-duration cap. Session evidence is reported separately so IdP session lifetime is not mistaken for assertion replay lifetime.

Profile Differences

The selected profile changes severity and fallback behavior, not the meaning of SAML dateTime values.

Profile Timing emphasis Common interpretation boundary
SP-initiated Web SSO Strict wrapper, bearer, recipient, and request-correlation evidence. Missing InResponseTo is a stronger failure signal because the response should answer an authentication request.
IdP-initiated Web SSO Bearer and recipient evidence remain important, but request correlation may be absent by design. A missing request ID is not automatically the same problem as it would be in SP-initiated SSO.
OAuth SAML bearer assertion Single assertion evidence, token-endpoint recipient context, and a required usable expiry. A suitable bearer confirmation expiry may provide the usable upper bound when Conditions do not.
Forensic timing excerpt Partial timestamp evidence for investigation notes. Useful timing rows can be preserved, but missing delivery context should not be treated as verifier approval.

Timestamp parsing normalizes common ISO-style SAML dateTime values to UTC for comparison. A date without a time is treated as midnight UTC, and a date-time without an explicit zone is treated as UTC so the row remains reviewable. Those repairs are investigation notes, not proof that the identity provider emitted ideal SAML dateTime values.

Limitations and Privacy Notes:

This checker is a timing and policy aid, not a full SAML verifier.

  • It does not verify XML signatures, issuer keys, certificate chains, audience restrictions, destination binding, decryption keys, request correlation against SP logs, or live replay-cache state.
  • Timing checks run in the browser against the pasted or loaded capture. SAML assertions can contain names, email addresses, attributes, tenant identifiers, endpoint details, and request IDs, so handle captures as sensitive incident data.
  • Encrypted-only responses do not expose timing attributes until they are decrypted in an approved environment. Do not paste decryption keys into a timing-only review.
  • The browser's current clock is useful only when it represents the verifier clock being tested. Use the incident timestamp for repeatable review of historical captures.
  • Compressed or binary captures need to be decoded before timing review unless the pasted value is a supported encoded SAML payload.

Worked Examples:

A normal SP-initiated Web SSO response has a short Conditions window, bearer confirmation that expires at or before the Conditions expiry, a recipient endpoint, and request-correlation evidence. With a reference time inside the window and a standard five-minute skew allowance, the current-time and bearer rows should pass while the timestamp ledger shows the exact instants used for the decision.

A clock-drift incident often shows a NotBefore value several minutes ahead of the relying-party reference time. If production tolerance is 60 seconds and the assertion starts eight minutes in the future, current-time validation should fail as not yet valid. The durable fix is clock synchronization or corrected IdP lifetime policy, not widening skew until the symptom disappears.

An OAuth SAML bearer assertion may rely on bearer confirmation expiry when Conditions do not expose their own upper bound. The same XML can look incomplete under a Web SSO profile because that profile expects response delivery context that an OAuth token exchange does not use in the same way.

FAQ:

Does a Pass result mean the SAML response is trusted?

No. Pass rows only cover visible timing evidence under the selected policy. Signature, issuer, audience, destination, recipient, request-correlation, and replay checks still belong in the relying-party verifier.

Why does NotOnOrAfter fail at the exact timestamp?

NotOnOrAfter is an exclusive upper bound. The assertion is valid before that instant, not at or after it.

Why should I enter a reference UTC time?

A reference time makes incident review repeatable. Leaving it blank uses the browser's current UTC clock, which can make an old assertion look expired even if it was valid during the incident.

Why can the same capture change status under another profile?

Profiles describe different relying-party decisions. SP-initiated Web SSO expects request-correlation and response delivery context, IdP-initiated Web SSO can omit request correlation, OAuth bearer review uses token-endpoint semantics, and forensic review preserves partial timing evidence.

What should I do with encrypted assertions?

Decrypt them in an approved environment, then paste only the assertion timing excerpt or a safe response capture. Encrypted-only responses do not reveal the timestamp fields needed for local timing review.

Glossary:

Identity provider
The system that authenticates the user and issues the SAML assertion.
Relying party
The service provider or application that decides whether to accept the assertion.
Conditions
The assertion element that can define the main validity interval using NotBefore and NotOnOrAfter.
Bearer confirmation
A subject confirmation method where possession and delivery of the assertion are enough for the relying party to evaluate it.
Clock skew
The allowed difference between the identity-provider clock and relying-party clock during timestamp validation.
Replay cache
A record of accepted assertion IDs retained long enough to prevent the same assertion from being reused.

References: