Troubleshoot an authentication flow step by step

Typical symptoms: the browser remains at the identity provider, the service provider rejects the response, a login loops, or the application shows an audience, destination, signature, or expiry error.

Capture and isolate

1. Clear the panel, start capture, and reproduce one login from the service provider.
2. Stop capture after the error or final application return.
3. Select Protocols > SAML and temporarily keep Hide static enabled.
4. Find the outbound request containing SAMLRequest and the return request containing SAMLResponse.

Inspect the evidence

Resolve or escalate

• Correct the service-provider ACS, entity ID, identity-provider issuer, audience, or metadata when browser evidence shows a mismatch.
• Compare certificate validity and signing expectations; the extension identifies visible signatures but does not cryptographically validate trust.
• If the request exists but no response returns, investigate identity-provider policy and authentication using the request ID and timestamp.
• Provide both SAML message IDs, issuer, destination, status, timestamps, and the sanitized assessment to the federation administrator.

Typical symptoms: invalid state, redirect URI mismatch, missing callback, repeated authorization, access denied, expired token, wrong tenant, or successful identity-provider authentication followed by an application error.

Capture and isolate

1. Capture one login from the client application through the authorization server and back.
2. Select Protocols > OAuth/OIDC/Bearer. Rows may match because they carry OIDC parameters or Bearer evidence even when only canonical endpoints receive the OAuth tag.
3. In Flow Analysis, select OIDC and choose the transaction matching the login time and state value.
4. Confirm that the authorization request and callback belong to the same transaction before interpreting validation results.

Inspect the evidence

Resolve or escalate

• Correct registered redirect URIs and client configuration when the captured request differs from the provider registration.
• Investigate application session creation when the callback succeeds but the browser returns to an unauthenticated application.
• Do not report a missing browser token as a defect when the application performs the code exchange on its backend.
• Preserve state aliases, timestamp, provider error, tenant, Entra trace/correlation IDs, or Okta request ID for provider and application logs.

Typical symptoms: repeated redirects, return to the login page, OAM error page, credential submission without application access, missing session cookie, or a slow OAM/WebGate exchange.

Capture and isolate

1. Start at the protected application URL, clear the panel, and reproduce one login.
2. Select Protocols > OAM/WebGate and keep Hide static enabled.
3. In Flow Analysis, select OAM and choose the attempt matching the start time.
4. Read the sequence from protected resource/WebGate to OAM credential collection, credential submission, WebGate reply, and application return.

Inspect the evidence

Resolve or escalate

• Use cookie ownership highlights to determine whether the missing transition belongs to WebGate or the OAM server.
• Use the first failing request rather than the final error page as the starting point for log analysis.
• Search WebGate, OHS, OAM, WebLogic, and application logs using the captured ECID, RID, request ID, timestamp, host, and endpoint.
• Include the complete redirect sequence and note whether credential collection, session creation, and application return were observed.

Typical symptoms: repeated 401 responses, a browser credential prompt, WNA collector failure, Kerberos not selected, or NTLM shown in red.

Capture and isolate

1. Capture the protected request from a domain-joined test system where WNA is expected.
2. Select Protocols > WNA/Kerberos/NTLM.
3. Open Flow Analysis, select WNA, and verify the challenge and browser response are in the same attempt.
4. Select the relevant requests and open Kerberos / X.509 for header-level evidence.

Interpret the exchange

• An initial 401 with WWW-Authenticate: Negotiate is an expected challenge, not automatically a failure.
• A following Authorization: Negotiate indicates that the browser submitted an SPNEGO token. The inspector decodes browser-visible token bytes locally and looks for the NTLMSSP signature, Kerberos mechanism OID 1.2.840.113554.1.2.2, and AP-REQ evidence.
• Confirmed Kerberos identifies Kerberos OID or AP-REQ evidence. Confirmed NTLM fallback identifies NTLMSSP even when wrapped by Negotiate. Undetermined SPNEGO means the visible token does not contain enough recognized evidence. Challenge only and Token redacted / not captured distinguish an absent browser response from evidence Chromium intentionally omitted.
• For an imported NetLog, open NetLog Analysis > Auth and choose Trace exchange. The trace inspects nested token fields locally, hides the token value, reports its length and detection evidence, and recommends the next Kerberos, NTLM, browser-policy, or restricted-capture check.
• Repeated challenges with no browser token indicate browser policy, trusted-zone, URL, or client configuration should be checked before server authentication.
• A submitted token followed by rejection requires SPN, service account, keytab, DNS, clock, KDC, and server-log validation outside the browser.

Resolve or escalate

• If no token is sent, validate browser integrated-authentication policy, trusted URL configuration, proxy behavior, and hostname use.
• If NTLM is sent, verify DNS canonicalization and SPN registration before treating the OAM endpoint as the primary cause.
• If Negotiate is rejected, provide the challenge sequence, host, WNA endpoint, timestamps, HTTP statuses, and token scheme; do not share token bytes broadly.

Typical symptoms: no certificate prompt, wrong certificate selected, certificate accepted by TLS but rejected by the application, expired certificate, or OAM X.509 collection failure.

Capture and inspect

1. Capture one attempt beginning at the protected X.509 resource.
2. Select Protocols > X.509 and locate /oam/CredCollectServlet/X509 or forwarded certificate evidence.
3. Open Kerberos / X.509 and review the visible subject, issuer, serial number, validity period, and thumbprints.
4. Check Request and Response for forwarded certificate headers, redirects, status, and OAM/WebGate session cookies.

Resolve or escalate

• Correct expired or not-yet-valid certificates and confirm the expected issuing CA and subject-mapping rule.
• Verify that the proxy or web tier forwards certificate information in the header expected by the application or OAM integration.
• Provide subject, issuer, serial number, thumbprint, collector endpoint, timestamp, ECID/request ID, and final HTTP result without sharing private keys.

Prepare the evidence

1. On the affected system, open Chrome DevTools before reproducing the login.
2. In Network, preserve the log if navigation clears requests, reproduce one clean attempt, and export the HAR with content through the approved process.
3. Transfer the HAR securely. Treat it as sensitive until it has been reviewed and sanitized.

Import and analyze

1. On the analysis computer, select the extension toolbar icon to open Offline Viewer. No website or DevTools window is required.
2. Select Import File, or drop the HAR, panel JSON export, or Firefox SAML-tracer JSON export onto the viewer.
3. Use the DevTools panel instead only when comparing the saved evidence with a live inspected tab. Load Network HAR applies only to entries already exposed by the browser Network model.
4. Wait for the imported request count, then use protocol filters and Flow Analysis as for live traffic.
5. If decoded SAML, bodies, cookies, or token evidence is absent, verify that the source HAR retained request/response headers and content.
6. Export a sanitized assessment after selecting the relevant transaction.

Capture the NetLog

1. Open chrome://net-export, start logging to disk, and reproduce one clean authentication or connection failure.
2. Return to Net Export and stop logging. Protect the JSON file as sensitive diagnostic evidence.
3. Select the extension toolbar icon, open Offline Viewer, and import the file. DevTools is optional for saved NetLog analysis.

Use NetLog Analysis

1. Start with Issues to identify explicit Chromium Net errors and challenge/retry events.
2. Narrow to Auth, DNS, Proxy, TLS, Sockets, HTTP/2, or QUIC based on the first failed stage.
3. Select a source in the left navigator to isolate its events and expand each event to inspect raw parameters.
4. For an authentication challenge finding, select Trace exchange. Follow the five stages: challenge, client token, retries, final outcome, and recommended next check. Use Previous or Next to compare repeated challenges.
5. For TLS or certificate evidence, select Trace TLS connection. Compare endpoint/connect evidence, handshake, certificate validation, protocol negotiation, connection reuse, and the final outcome.
6. For DNS, proxy, socket, HTTP, HTTP/2, QUIC, or other findings, select Investigate. Review the triggering event, linked Chromium sources, related evidence, final visible outcome, and recommended investigation path.
7. Follow the recommended next action, then correlate the timestamp, hostname, source, and Net error with proxy, DNS, certificate, gateway, or browser policy evidence.

Choose the contextual action

Trace one problematic request

1. Search for the affected hostname, URL fragment, or Chromium error to remove unrelated browser activity.
2. Start with the earliest meaningful failure near the reproduction time, not simply the largest error count.
3. Open its contextual action and verify the triggering event, source correlation, related evidence, and final visible outcome.
4. Expand the highlighted timeline event and follow its source dependencies in timestamp order.
5. Use Previous and Next to compare retries of the same category.
6. Confirm whether later ERR_ABORTED, cancelled, or retry events are consequences of an earlier DNS, proxy, TLS, or authentication failure.