VoriTools

Review OIDC metadata and generate a PKCE set

Paste provider metadata, not production secrets or tokens. This checks declarations without contacting the provider or confirming client registration and redirect allowlists.

Runs locally in your browser
View category: Security & Cryptography (30)
This page does not call the identity provider. Paste only metadata, never a production client secret, authorization code, or access token.
Client context Optional values make the local review more specific.
OpenID Connect discovery metadata
PKCE values Generated with Web Crypto in this browser.
Code verifier
Generate a PKCE set to see a local value.
S256 code challenge
Generate a PKCE set to see a local value.
State
Generate a PKCE set to see a local value.
Inspection summary
  • Paste OpenID Connect discovery JSON to inspect it.

Prepare a safer public-client sign-in flow

Use Authorization Code with PKCE for browser and mobile clients. This local checker cannot confirm provider registration, redirect URI allowlists, consent policy, or live token behavior.

How to review OIDC discovery metadata and generate PKCE values

Paste the JSON that /.well-known/openid-configuration returns, press Inspect OIDC configuration and read the findings: the page names the fields a public Authorization Code client depends on and separates blocking problems from items worth reviewing. The client ID and redirect URI boxes are optional and only make that local review more specific.

The PKCE button draws 48 random bytes, hashes them with SHA-256 and shows the code verifier, the S256 challenge and a state value. All of it runs in this tab through the Web Crypto API, and the metadata you paste is never sent to VoriTools or to the identity provider.

  1. Copy the JSON from the provider discovery document, for example https://login.example.com/.well-known/openid-configuration, and paste it into the metadata box. Press Load example first if you want to see the expected shape.
  2. Add the client ID and the redirect URI you registered when the local review should check them too. Both fields are optional; leaving them empty still checks the provider document.
  3. Press Inspect OIDC configuration. Required fields and URLs are listed first, then response types, grant types, PKCE methods and the JWKS URI, each finding tagged with the metadata path that produced it.
  4. Resolve the blocking findings before integrating: a missing endpoint, a plaintext-only PKCE advertisement or an http redirect in production are the ones that break the flow. Review items are worth reading but do not stop a test setup.
  5. Press Generate PKCE set, copy the values with Copy PKCE values, keep the verifier in your client until the token request and press Clear before pasting the next provider.

What the discovery document declares, and what the PKCE values are

What a discovery document has to declare

The inspector reads the fields a browser or mobile client depends on: issuer, authorization_endpoint and token_endpoint must be absolute URLs - HTTPS in production, HTTP only on loopback addresses - and jwks_uri has to be advertised so token signatures can be verified. response_types_supported has to include code and grant_types_supported has to include authorization_code for the Authorization Code flow.

The field with the most effect on a public client is code_challenge_methods_supported. Without PKCE, an authorization code captured on a mobile device or through a custom URL scheme can be redeemed by whoever intercepted it, so an advertisement that offers only plain, or omits the field, is treated as blocking rather than as a warning.

How the PKCE values are produced

Generate PKCE set takes 48 random bytes from crypto.getRandomValues, encodes them as base64url and prints the 64-character code verifier. The S256 challenge is the base64url of the SHA-256 digest of that verifier - 43 characters - and the state value is 24 random bytes, 32 characters, to be compared when the provider redirects back with the authorization code.

Use S256: the challenge travels in the authorization request, the verifier stays in your client until the token request, and a code captured in between cannot be exchanged. The plain method puts the verifier itself in the URL, which is why a document that supports only plain ends this inspection with a blocking finding.

What this page cannot confirm

The document is read exactly as pasted. The page cannot tell whether the provider registered your client, whether the redirect URI is on its allowlist, what consent screen the user sees, or whether the endpoints behave as advertised; those checks need a real authorization request against the provider.

A clean result therefore means the copied metadata is consistent for a public client, not that the integration works. Live flows, token lifetimes and refresh behaviour still have to be tested against the provider, and the redirect URI check here is a local exact-match reminder only.

Recent tools: