tarsolutionOIDC
Compare HTTPS discovery endpoints and supported grants. JWT verification requires an explicit issuer, audience and trusted JWKS; no token-provided key URL is followed.
Inspect OIDC discovery, verify JWTs and test authorized service clients.
01 Input
02 Output
A little clarity awaits.
Start with a sample or add your own input.
Your result will appear here.
Ready when you areJSON API · no cache
A CLOSER LOOKThe details behind
The details behind
the result.
Understand the format, the calculation, and what to look for.
Service clients
Client Credentials sends one authorized request and masks token material. No production credential storage, refresh loop, automatic revocation or user-password collection occurs.
SAML scope
Metadata and assertion structure inspection only. XML signature, trust-chain, replay protection, PKCE login and SP-initiated sessions are not implemented by this inspector; parsing is never reported as authentication success.
Inputs explained
- Flow
- Flow
- Discovery / token URL
- Public HTTPS endpoint. Token requests never follow redirects.
- Client ID
- Client ID
- Client secret
- Used once; never stored or returned.
- Client authentication
- Client authentication
- Scope
- Scope
- I am authorized to test this service client
- I am authorized to test this service client
- JWT
- A signed JWT. Only fingerprint and selected non-identity claims appear in the report.
- Trusted JWKS
- Public keys from an independently trusted provider. Do not use a JWKS URL supplied by the token itself.
- Expected issuer
- Expected issuer
- Expected audience
- Expected audience
- Expected nonce
- Expected nonce
- SAML metadata / assertion XML
- Untrusted XML is parsed with entities disabled. Signature verification is not performed; no login session is created.