KivTools

Examiner les métadonnées OIDC et générer des valeurs PKCE

Collez les métadonnées, pas des secrets ou jetons de production. L’outil ne contacte pas le fournisseur et ne confirme ni inscription du client ni redirections autorisées.

Fonctionne localement dans votre navigateur
Voir la catégorie: Sécurité et cryptographie (30)
Cette page n'appelle pas le fournisseur d'identité. Collez uniquement les métadonnées, jamais un secret client de production, un code d'autorisation ou un jeton d'accès.
Contexte client Les valeurs facultatives rendent la révision locale plus spécifique.
Métadonnées de découverte OpenID Connect
Valeurs PKCE Généré avec Web Crypto dans ce navigateur.
Vérificateur de codes
Générez un ensemble PKCE pour voir une valeur locale.
Défi du code S256
Générez un ensemble PKCE pour voir une valeur locale.
État
Générez un ensemble PKCE pour voir une valeur locale.
Résumé de l'inspection
  • Collez la découverte OpenID Connect JSON pour l’inspecter.

Préparer une connexion plus sûre pour un client public

Utilisez le code d'autorisation avec PKCE pour les clients de navigateur et mobiles. Ce vérificateur local ne peut pas confirmer l'enregistrement du fournisseur, rediriger les listes d'autorisation URI, la politique de consentement ou le comportement du jeton en direct.

Comment examiner les métadonnées de découverte OIDC et générer des valeurs PKCE

Collez le JSON renvoyé par /.well-known/openid-configuration, cliquez sur Inspecter la configuration OIDC et lisez les constats : la page nomme les champs dont dépend un client public en Authorization Code et sépare les problèmes bloquants des points à vérifier. Les champs client ID et redirect URI sont facultatifs et ne font que préciser cette vérification locale.

Le bouton PKCE tire 48 octets aléatoires, les condense avec SHA-256 et affiche le vérificateur de code, le challenge S256 et une valeur state. Tout se passe dans cet onglet via l’API Web Crypto ; les métadonnées collées ne partent ni vers KivTools ni vers le fournisseur d’identité.

  1. Copiez le JSON du document de découverte du fournisseur, par exemple https://login.example.com/.well-known/openid-configuration, et collez-le dans le champ des métadonnées. Cliquez sur Charger un exemple pour voir d’abord la forme attendue.
  2. Renseignez le client ID et l’URI de redirection que vous avez enregistrés si la vérification locale doit aussi les contrôler. Ces champs sont facultatifs ; vides, le document du fournisseur est quand même examiné.
  3. Cliquez sur Inspecter la configuration OIDC. Les champs et URL obligatoires viennent d’abord, puis les types de réponse, les types d’octroi, les méthodes PKCE et l’URI JWKS, chaque constat portant le chemin du champ concerné.
  4. Réglez les constats bloquants avant d’intégrer : une URL d’endpoint absente, une annonce PKCE limitée à plain ou une redirection http en production cassent le flux. Les points à vérifier méritent une lecture, sans bloquer un environnement de test.
  5. Cliquez sur Générer l’ensemble PKCE, copiez les valeurs avec Copier les valeurs PKCE, gardez le vérificateur dans votre client jusqu’à la requête de jeton, puis cliquez sur Effacer avant de coller le fournisseur suivant.

Ce que déclare le document de découverte et ce que sont les valeurs PKCE

Ce qu’un document de découverte doit déclarer

L’inspecteur lit les champs dont dépend un client navigateur ou mobile : issuer, authorization_endpoint et token_endpoint doivent être des URL absolues — HTTPS en production, HTTP uniquement sur une adresse de bouclage — et jwks_uri doit être annoncé pour permettre la vérification des signatures de jetons. response_types_supported doit contenir code et grant_types_supported doit contenir authorization_code pour le flux Authorization Code.

Le champ qui pèse le plus pour un client public est code_challenge_methods_supported. Sans PKCE, un code d’autorisation intercepté sur un mobile ou via un schéma d’URL propre peut être échangé par celui qui l’a capté ; une annonce qui ne propose que plain, ou qui omet le champ, est donc traitée ici comme bloquante et non comme un avertissement.

Comment les valeurs PKCE sont produites

Générer l’ensemble PKCE tire 48 octets aléatoires de crypto.getRandomValues, les encode en base64url et affiche le vérificateur de 64 caractères. Le challenge S256 est le base64url du condensat SHA-256 de ce vérificateur — 43 caractères — et la valeur state est de 24 octets aléatoires, 32 caractères, à comparer au retour de redirection du fournisseur.

Utilisez S256 : le challenge voyage dans la demande d’autorisation, le vérificateur reste dans votre client jusqu’à la requête de jeton, et un code intercepté entre les deux ne peut pas être échangé. La méthode plain envoie le vérificateur lui-même dans l’URL ; c’est pourquoi un document qui ne prend en charge que plain termine ici sur un constat bloquant.

Ce que cette page ne peut pas confirmer

Le document est lu exactement tel qu’il a été collé. La page ne peut pas dire si le fournisseur a enregistré votre client, si l’URI de redirection figure sur sa liste, quel écran de consentement voit l’utilisateur, ni si les endpoints se comportent comme annoncé : cela demande une vraie demande d’autorisation auprès du fournisseur.

Un résultat sans constat signifie donc que les métadonnées copiées sont cohérentes pour un client public, pas que l’intégration fonctionne. Les flux réels, la durée de vie des jetons et le rafraîchissement restent à tester chez le fournisseur, et le contrôle de l’URI de redirection n’est ici qu’un rappel local de correspondance exacte.

Outils récents :