OIDC Integration Log Collection and Vendor Communication Workflow

Why complete logs are required

• OIDC providers often interpret standard behavior differently; without request/response-level detail, it is hard to isolate which side is misconfigured.
• Error strings alone are rarely sufficient for vendor support. Step-by-step test context and phased outcomes are needed.

Pre-test technical baseline

1. Freeze the test matrix: fix account, scope, redirect URI, and grant_type combinations before running rounds.
2. Align timestamps: synchronize clocks across client, IdP, and proxy layers.
3. Standardize fields: use common event ID, response code, error class, and reproduction-step fields.
4. Mask sensitive values: redact token, secret, and personal data while preserving troubleshooting signal.

Required evidence set

1. Client-side logs: for Jamf Connect, built-in debug output (or the official support profile) is the primary source and is generally not substitutable; curl/Postman captures are for other clients, not a replacement for Jamf Connect logs.
2. Server-side logs: request same-window IdP logs from provider, including client_id, grant_type, and scope context.
3. Traffic or trace records: use approved capture methods or vendor-provided collection scripts when deeper reproduction is required.
4. Test matrix records: track exact values per run (including redirect URI, auth flow, and account) with outcome status.

Communication and triage workflow

1. Provide one complete package per round: combine client logs, server logs, matrix, and timeline to avoid repeated evidence requests.
2. State protocol delta explicitly: reference RFC or official docs and show expected behavior versus observed behavior.
3. Single-variable retest: change one parameter at a time and rerun same path.
4. Post-meeting closure notes: record conclusion, missing evidence, and next steps after each session.

Common issues and triage order

1. Auth page works but token exchange fails: verify client_secret, redirect URI, and grant_type first.
2. Token returned but login still fails: compare claim mapping with local account-binding rules.
3. Same config succeeds intermittently: inspect time sync and certificate chain first, then proxy forwarding behavior.
4. Vendor cannot reproduce: provide event-ID-based end-to-end timeline with request/response comparison.

Technical validation checklist

1. Same incident can be correlated between client and server logs.
2. Test matrix includes reproducible steps and outcome markers.
3. Sensitive values are masked without losing diagnostic value.
4. Each round uses single-variable changes for comparable results.
5. Root cause can be scoped clearly to client, IdP, or proxy layer.

References

• OpenID Connect Core 1.0
  https://openid.net/specs/openid-connect-core-1_0.html
• OAuth 2.0 Framework (RFC 6749)
  https://www.rfc-editor.org/rfc/rfc6749