SAML 2.0 · OpenID Connect

Find the exact step where sign-in breaks.

SSO Doctor maps sanitized SAML and OIDC evidence onto the protocol flow, runs deterministic checks, and shows each finding with the evidence behind it and the change to verify next.

Start a free diagnosis Open a sample case

Free tier: No AI inference
Evidence: Sanitized only
Raw input: Not retained

case c7e1·4b09·saml·aud

Illustrative

Service provider

User agent

Identity provider

01Request protected resourceStep 1: Request protected resource. Passed. GET /app — no SP session present.
02302 with AuthnRequestStep 2: 302 with AuthnRequest. Passed. HTTP-Redirect binding. ID=_req4a91.
03Deliver AuthnRequestStep 3: Deliver AuthnRequest. Passed. Browser follows redirect to the IdP SSO endpoint.
04Authenticate · issue ResponseStep 4: Authenticate · issue Response. Warning. IssueInstant 14:02:11Z. SP log reports receipt at 14:00:09Z.
05POST Response to ACSStep 5: POST Response to ACS. Passed. HTTP-POST binding to /saml/acs. Destination matches.
06Verify signatureStep 6: Verify signature. Warning. Response is signed. Assertion carries no signature.
07Evaluate ConditionsStep 7: Evaluate Conditions. Failed. AudienceRestriction does not contain the SP entityID.
08Establish sessionStep 8: Establish session. Not reached. Not reached — validation failed upstream.

criticalSAML-COND-AUD · step 07

Audience does not match the SP entityID

observedhttps://app.example.test/samlexpectedhttps://app.example.test/saml/metadata

The diagnostic path

Built for the engineer behind the incident.

Identity failures surface far from their cause. A login loop is a symptom; an audience string with a missing path segment is the cause. SSO Doctor works from evidence toward the cause.

01
Describe the failure
Protocol, flow type, the exact error text, and what changed recently. Context narrows which rules matter.
02
Sanitize in the browser
A local pre-flight scan flags private keys, client secrets, bearer tokens, raw JWTs, and cookies before anything is submitted.
03
Inspect deterministically
Rule-based checks place each signal on the protocol flow and mark the first step where validation fails.
04
Fix, then verify
Every finding ships with observed vs. expected values, remediation steps, and a check to confirm the fix.

Anatomy of a finding

Evidence first. Opinion never dressed up as fact.

Severity: Critical blocks sign-in. High will block once upstream issues are fixed. Info needs no action.
Confidence: Confirmed, likely, or possible — stated separately from severity so a guess never looks like a fact.
Evidence: Observed and expected values side by side, with the exact element or log line they came from.
Reference: The specification section the rule enforces, so the fix can be defended in a change review.

Example output · OIDCIllustrative

EvidenceConfirmed by evidence

Field	Observed	Expected	Source
iss (ID token)	https://login.example.test/tenant-a/	https://login.example.test/tenant-a	Decoded ID token
issuer (discovery)	https://login.example.test/tenant-a	—	Discovery document

Remediation

1.Determine which value the provider actually emits for this tenant; the discovery issuer and token iss should be identical.
2.Configure the RP from the discovery document instead of a hand-entered issuer, or align the manual value exactly.
3.Do not normalize or strip trailing slashes in validation code to work around this.

Verify before closing

Decode a new ID token and confirm iss equals the discovery issuer byte-for-byte.

OpenID Connect Core 1.0 §3.1.3.7 (step 2); Discovery 1.0 §4.3

Plans

The diagnosis is free. The write-up is optional.

Findings always come from the deterministic engine. AI reports explain and prioritize those findings — they do not replace them, and they never run on the Free tier.

Compare plans in detail

Free

No AI inference

Deterministic inspection for every incident.

$0forever

SAML 2.0 and OIDC rule-based checks
Protocol flow map with failing step
Findings with evidence and severity
Remediation and verification checklists
Client-side secret pre-flight scan

Results are not stored after you leave the page.

Start a diagnosis

Standard

Pay per report

An AI-written report when you need to explain it.

$12per AI report

Everything in Free
AI narrative of the findings
Plain-language root cause summary
Change plan ordered by risk
Markdown and PDF export

Credits are purchased in advance. One report per credit.

Buy report credits

Advanced

40 Advanced reports / seat / month

For identity teams running SSO at scale.

$59per seat / month

Everything in Standard
Deeper cross-finding correlation
Reports workspace with search and filters
Before / after validation comparisons
Retention controls for report metadata

Fixed monthly allowance. Usage beyond it is blocked, not billed.

Start Advanced

Data handling

Designed for evidence that crosses security boundaries.

Sanitized evidence only

Never submit passwords, private keys, client secrets, session cookies, or raw tokens. The pre-flight scan helps catch them.

Raw submissions not retained

Evidence is processed for the diagnosis and discarded. Saved reports keep findings and a case fingerprint, not your input.

Entitlements enforced server-side

AI report access and monthly allowances are checked by the backend before any generation request is made.

No production access

SSO Doctor never connects to your IdP, SP, or tenant. It reads what you paste, and nothing else.

SSO Doctor is a diagnostic decision aid. Results may be incomplete or inaccurate. Independently validate findings before making production changes.

Have an incident open right now?

Paste the sanitized evidence. Get the failing step.