Erreurs

Les erreurs que votre application peut recevoir, leur cause et comment les corriger.

3 min de lecture · Mis à jour le 18/10/2026 · API v1

Les erreurs OpenID Connect arrivent à trois endroits : sur une page pismile (configuration invalide), sur votre adresse de redirection (?error=…), ou en réponse à l'appel de l'endpoint de jeton.

Affichées sur pismile#

Quand pismile ne peut pas faire confiance à l'adresse de retour, il ne redirige pas vers votre site : l'erreur s'affiche sur pismile.

Situation	Cause	Correction
`client_id` inconnu	Identifiant mal copié, application supprimée, ou mélange sandbox/production	Recopiez le `client_id` depuis la console
`redirect_uri` refusée	L'adresse ne correspond pas exactement à une adresse déclarée	Comparez schéma, domaine, port, chemin et barre finale ; déclarez l'adresse dans la console

Reçues sur votre adresse de redirection#

pismile renvoie l'utilisateur vers votre site avec error (et parfois error_description) au lieu de code. Le paramètre state est toujours recopié : vérifiez-le aussi en cas d'erreur.

HTTP

https://votre-site.com/login/oauth2/code/pismile?error=access_denied&state=af0ifjsldkj

`error`	Cause	Que faire
`access_denied`	L'utilisateur a refusé de partager ses informations	Affichez un message neutre et proposez de réessayer
`invalid_scope`	Scope inconnu, ou non activé pour votre application (souvent `address`)	Retirez le scope ou activez-le dans la console
`invalid_request`	Paramètre manquant ou invalide (par exemple `code_challenge_method` autre que `S256`)	Vérifiez la requête d'autorisation
`unauthorized_client`	Votre application n'est pas autorisée pour ce flux	Utilisez `response_type=code`
`login_required`	`prompt=none` alors que l'utilisateur n'est pas connecté à pismile	Relancez sans `prompt=none`
`consent_required`	`prompt=none` alors que l'utilisateur n'a pas encore donné son accord	Relancez sans `prompt=none`
`server_error`, `temporarily_unavailable`	Incident côté pismile	Réessayez plus tard ; contactez le support si cela persiste

Reçues de l'endpoint de jeton#

Réponse HTTP 400 ou 401, au format JSON :

JSON

{ "error": "invalid_grant" }

`error`	Cause	Correction
`invalid_client`	Secret erroné ou régénéré, ou secret envoyé dans le corps au lieu de l'en-tête `Authorization`	Vérifiez `PISMILE_CLIENT_SECRET` et utilisez `client_secret_basic`
`invalid_grant`	Code expiré ou déjà utilisé, `redirect_uri` différente de celle de l'autorisation, ou `code_verifier` incorrect	Échangez le code immédiatement et une seule fois ; gardez le même `code_verifier` en session
`unsupported_grant_type`	`grant_type` autre que `authorization_code`	Corrigez la requête

Problèmes fréquents#

« invalid_client » juste après la création de l'application
Le secret n'est affiché qu'une seule fois : s'il a été mal copié, régénérez-le dans la console et mettez à jour votre variable d'environnement.
Boucle de redirection après la connexion
Votre session ne conserve pas le state ou le code_verifier entre l'aller et le retour. Vérifiez la configuration des cookies, notamment SameSite, et qu'un seul domaine est utilisé (pas un mélange de localhost et 127.0.0.1).
Ça marche en sandbox, pas en production
L'application de production a son propre client_id, son propre secret et ses propres adresses de redirection, en https sur un domaine vérifié. Vérifiez les trois.
Les utilisateurs « changent » entre sandbox et production
C'est normal : le sub est propre à chaque application. Voir Scopes et claims.

Cette page vous a-t-elle aidé ?