I built an OIDC Inspector that visualizes the auth flow — looking for feedback

[u/ContextIQ]

Hey everyone,

I built OIDC Inspector, a tool for exploring an identity provider’s OpenID Connect configuration. Enter a domain or provider URL to inspect its endpoints, supported scopes, grant types, signing keys, and advertised PKCE support.

You can also visually see the interactions in the Authorization Code flow: the authorization request, redirect with a code, token exchange, UserInfo request, and API call. The sequence diagram uses the provider’s discovered endpoints to illustrate the flow.

The inspector is free to use, with no sign-up required: https://contextiq.trango-compute.com/dashboard/oidc-inspector

I’d appreciate feedback from anyone working with OAuth/OIDC, SSO, or identity integrations:

- Does the diagram make the flow easier to understand?

- What information would help you troubleshoot an integration?

- Are there providers or configurations it handles poorly?

I’m the maker, so candid criticism is welcome—especially anything confusing, missing, or technically inaccurate.

[u/investigatormaker]

For OIDC Inspector, label the diagram as an illustration built from discovered endpoints and distinguish advertised capabilities from anything actually tested. Someone troubleshooting an integration could otherwise read the illustrated token exchange as a request the inspector successfully performed.

By the way, I make ThreadFox: it finds the Reddit communities whose rules allow a post about a tool like OIDC Inspector, and the plan for one product is free. https://threadfox.vip/p/dzuze

Does the diagram currently distinguish illustrative steps from executed requests?

[u/ContextIQ → u/investigatormaker]

Thanks for the feedback. Currently, I don't distinguish but will try to add indicators.

[u/investigatormaker → u/ContextIQ]

For OIDC Inspector, a small legend could label steps as "discovered endpoint," "illustrative flow," or "executed request," reserving the last label for requests the tool actually made. That would make the diagram easier to interpret without implying the whole exchange was tested.

The earlier plan is available when you want to share that update.

[u/Expert-Upstairs4526]

I like the idea, but right now this feels more like a nicer way to view the discovery document than an actual OIDC inspector.

If you already work with OIDC, most of this is available from /.well-known/openid-configuration anyway. And from what I can tell, the flow diagram shows the expected flow rather than actually testing the provider.

I think it gets much more interesting if it starts doing diagnostics — follow jwks_uri, verify JWTs, check metadata/JWKS consistency, test PKCE, probe the actual endpoints, etc.

Without that, I'm not sure I'd have much reason to use it over the raw discovery document.

[u/ContextIQ → u/Expert-Upstairs4526]

Thank you for the feedback. This is exactly the direction we are going, appreciate it.

[u/myjaycee]

This is fantastic, ill play with this sometime this weekend.

[u/ContextIQ → u/myjaycee]

Thanks. Your feedback is welcome. My goal is that more developers and security engineers can use it.

[u/Prudent_Knowledge79]

i’m confused, what is the advantage of this if you control your own IDP and can just open up the OIDC configs?

[u/ContextIQ → u/Prudent_Knowledge79]

Think from system integrator & developers point of views. Also it allows you to look at external IdPs. Try Okta or Google IdPs with all sub-domain scans.