Tester le fournisseur d'identité avec oidcdebugger.com

oidcdebugger.com est un outil en ligne gratuit qui fait office de partie utilisatrice. Vous collez l'URL d'autorisation de Scrydon, votre ID client et vos scopes, cliquez sur Envoyer la requête, et obtenez en retour un code d'autorisation. Vous échangez ensuite le code contre des jetons avec un simple appel curl et décodez l'ID token sur jwt.io.

Cela prend environ cinq minutes et prouve que votre tenant Scrydon sert correctement l'OIDC de bout en bout.

Prérequis

• Une Application enregistrée (client) créée dans Paramètres → Organisation → Applications enregistrées. Consultez Enregistrer un client OAuth.
• L'onglet Identité de Paramètres → Plateforme → Identité ouvert dans une autre fenêtre — vous y copierez les URL.

1. Ajouter le callback du débogueur à votre client

oidcdebugger renvoie le code d'autorisation à https://oidcdebugger.com/debug. Scrydon n'accepte que les redirections correspondant aux URI de redirection enregistrées de votre client, vous devez donc ajouter cette URL comme redirection autorisée pour votre client de test.

2. Démarrer le flux d'autorisation

3. Échanger le code contre des jetons

La page de résultats de oidcdebugger affiche un paramètre code=... dans l'URL. Échangez-le contre un ID token et un jeton d'accès.

Copiez le Vérificateur de code depuis oidcdebugger (il l'a généré pour PKCE) et exécutez la commande suivante depuis votre terminal — ajustez {AUTH_URL}, {CLIENT_ID}, {CODE} et {CODE_VERIFIER} :

curl -X POST "{AUTH_URL}/api/auth/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code={CODE}" \
  -d "redirect_uri=https://oidcdebugger.com/debug" \
  -d "client_id={CLIENT_ID}" \
  -d "code_verifier={CODE_VERIFIER}"

Vous devriez recevoir une réponse JSON avec access_token, id_token, refresh_token (si vous avez demandé offline_access), token_type et expires_in.

4. Décoder l'ID token

Collez le id_token dans jwt.io. La charge utile affichera :

{
  "iss": "https://staging.api-platform.scrydon.com",
  "sub": "usr_...",
  "aud": "your-client-id",
  "exp": 1234567890,
  "iat": 1234567890,
  "email": "you@example.com",
  "name": "Your Name",
  "org_id": "org_...",
  "workspace_id": "ws_...",
  "environment_id": "env_..."
}

Les trois dernières revendications (org_id, workspace_id, environment_id) sont spécifiques à Scrydon — votre Mini App les utilise pour router les appels API vers le bon tenant et espace de travail.

Pour vérifier la signature localement, récupérez le JWKS depuis l'URL de l'onglet Identité ({AUTH_URL}/api/auth/.well-known/jwks) et collez-le dans le panneau Vérifier la signature de jwt.io.

5. Appeler le point de terminaison Userinfo

Une dernière vérification — utilisez le jeton d'accès pour appeler Userinfo :

curl "{AUTH_URL}/api/auth/oauth2/userinfo" \
  -H "Authorization: Bearer {ACCESS_TOKEN}"

Vous devriez récupérer les mêmes revendications d'identité sous forme d'objet JSON.

Dépannage

404 sur /api/auth/.well-known/openid-configuration ou /oauth2/token

Confirmez d'abord si le problème vient du DNS, de l'ingress ou de l'application :

# 1. Le nom d'hôte se résout-il ?
curl -I "{AUTH_URL}"

# 2. Un point de terminaison Better Auth répond-il ? /api/auth/session est toujours monté.
curl -s -o /dev/null -w "%{http_code}\n" "{AUTH_URL}/api/auth/session"

# 3. Le plugin OIDC est-il monté ? La découverte devrait retourner 200 + JSON.
curl -s "{AUTH_URL}/api/auth/.well-known/openid-configuration" | head -c 500

Interprétez les résultats :

• Les trois échouent / DNS échoue — le nom d'hôte affiché dans l'interface ne se résout pas. La variable d'environnement PUBLIC_AUTH_URL sur le pod de la plateforme pointe vers un nom d'hôte absent du DNS ou non routé par l'ingress. Demandez à l'opérateur du cluster de corriger le DNS / l'ingress, ou de mettre à jour PUBLIC_AUTH_URL pour pointer vers l'hôte où le pod d'auth est réellement publié.
• /session fonctionne, /oauth2/* retourne 404 — l'application d'auth est accessible mais le plugin @better-auth/oauth-provider n'est pas chargé dans le build en cours d'exécution. Il s'agit de la migration depuis l'ancien oidcProvider. Confirmez que l'image déployée contient le plugin (cherchez oauthProvider( dans packages/multi-tenancy/src/auth/server/auth.ts au commit déployé).
• Les trois fonctionnent — votre ID client est probablement pour un environnement différent, ou votre client n'a pas l'URI de redirection enregistrée. Revenez à l'étape 1 de cette page.

L'application plateforme expose également /api/auth/* comme proxy vers l'hôte d'auth. Préférez frapper l'hôte d'auth directement pour les outils comme oidcdebugger — cela évite toute couche proxy et correspond à ce que les SDK de bibliothèques feront en production.

invalid_client lors de l'échange de jeton

• L'ID client utilisé à l'étape 2 ne correspond pas à celui de l'étape 3. Les Mini Apps émettent des ID clients par environnement — assurez-vous d'avoir utilisé le même de manière cohérente.

invalid_grant: code verifier does not match code challenge

• oidcdebugger génère un nouveau vérificateur de code par requête. Si vous avez actualisé la page entre l'étape 2 et l'étape 3, le vérificateur affiché a été régénéré. Répétez l'étape 2 pour obtenir une nouvelle paire code + vérificateur.

redirect_uri mismatch

• https://oidcdebugger.com/debug n'a pas été ajouté aux URI de redirection du client. Revenez à l'étape 1 et enregistrez à nouveau.

L'écran de connexion boucle sur lui-même

• Votre session Scrydon a probablement expiré en cours de flux. Effacez les cookies pour l'hôte du tenant et réessayez.