Sécurité & bonnes pratiques

La redirect_uri doit correspondre exactement

CrowAccounts compare la redirect_uri reçue à la liste enregistrée caractère pour caractère — pas de correspondance par préfixe, pas de joker. Enregistre une URI par environnement (développement, staging, production) plutôt que d'essayer de les faire tenir dans un seul motif.

Toutes tes redirect_uri doivent être en https://. http:// n'est toléré que pour localhost / 127.0.0.1, en développement local — toute autre URL en http:// est refusée à l'enregistrement. Sans ça, le code d'autorisation (qui donne un accès complet au compte tant qu'il n'a pas expiré) transiterait en clair sur le réseau, interceptable par quiconque partage le même réseau (wifi public, proxy compromis...).

Utilise systématiquement le paramètre state

CrowAccounts te renvoie le state tel quel, mais ne le vérifie pas lui-même : c'est un mécanisme pour toi, pas pour lui. Génère une valeur aléatoire unique par tentative de connexion, stocke-la côté session avant la redirection vers /oauth/authorize, et vérifie qu'elle correspond exactement à ton retour avant d'échanger le code — sinon rien n'empêche un attaquant de forger une redirection de retour avec un code qui n'est pas le sien.

Traite les jetons comme des secrets

• Stocke access_token et surtout refresh_token côté serveur, jamais dans le localStorage ou un cookie non httpOnly accessible en JavaScript.
• Persiste le refresh_token le plus récent à chaque rotation, et supprime l'ancien — le conserver "au cas où" ne sert à rien (il est révoqué côté serveur dès la rotation) et déclenchera la détection de vol si jamais il est présenté par erreur. Détail dans la référence OAuth2.
• Si tu reçois invalid_grant avec un message de réutilisation détectée, considère la session comme définitivement compromise : renvoie l'utilisateur en authentification complète plutôt que de retenter.

Webhooks : vérifie, ne fais jamais confiance par défaut

Valide systématiquement la signature X-CrowAccounts-Signature avant de traiter un événement, avec une comparaison en temps constant (crypto.timingSafeEqual) plutôt qu'un === classique — sinon le temps de réponse de ta comparaison peut lui-même fuiter de l'information exploitable pour deviner la signature attendue. Le détail complet, avec exemple de code, est sur la page Webhooks.

Ne demande que les scopes dont tu as réellement besoin

Chaque scope supplémentaire est une donnée personnelle de plus que tu détiens, et une ligne de plus sur l'écran de consentement qui peut faire hésiter un utilisateur. Déclare et demande uniquement email, phone ou birthday si ta fonctionnalité en dépend réellement — tu peux toujours étendre le scope plus tard (voir Scopes & profil), l'utilisateur sera alors reprompté spécifiquement pour cette extension.