Afficher la page d’inscription dans l’interface (champ email, mot de passe, langue, checkbox conditions). Proposer aussi un bouton d’inscription via provider (GitHub / GitLab).

L’utilisateur saisit email, mot de passe et éventuellement langue. Valider côté client les champs (format email, longueur de mot de passe, acceptation des conditions).

Après soumission, afficher un loader et un message d’attente. Le backend crée le compte, renvoie confirmation; si un bonus de crédits est configuré, il est attribué automatiquement.

En cas de succès, rediriger vers le tableau de bord ou afficher une boîte de confirmation. En cas d’erreur (email déjà utilisé), afficher un message clair avec actions possibles (connexion / récupération mot de passe).

Envoyer un email de bienvenue si disponible et proposer la configuration initiale (connecter un dépôt, créer un premier projet). Pour l’UX mobile, afficher le lien pour ouvrir l’app native si existante.

Bouton OAuth : l’utilisateur clique sur “Se connecter avec GitHub” ou “GitLab”. Préparez un état local indiquant l’intention de redirection (pour revenir au bon écran après).

Lancer la redirection vers la page d’autorisation du provider. Si vous utilisez PKCE, générez et stockez le code_verifier côté client avant la redirection.

Après autorisation, le provider redirige vers votre application avec paramètres (code, state, éventuellement tokens). Le client doit extraire ces paramètres et les transmettre au serveur ou les traiter selon votre flow.

Le serveur vérifie les informations du provider. Si l’email associé n’existe pas, le système peut créer automatiquement un compte et éventuellement attribuer des crédits de bienvenue.

Une fois authentifié, établir une session utilisateur. Le client récupère l’état de session et redirige vers la destination initiale prévue (par ex. tableau de bord).

Si le provider ne renvoie pas l’email (cas possible avec GitHub), ne bloquez pas l’utilisateur : proposez un écran secondaire qui demande un email ou complète le profil.

L’administrateur installe l’application GitHub sur le dépôt/organisation. Après installation, l’App peut émettre un jeton d’authentification provisoire côté serveur.

Le serveur génère un jeton d’authentification signé (token court) qui atteste qu’une installation GitHub correspond bien à un utilisateur. Ce jeton est utilisé pour initier une session login sans mot de passe externe.

Le client ou une intégration interne utilise le jeton signé pour demander une session. Le serveur vérifie la signature et associe l’identité GitHub à l’utilisateur existant.

Si aucune correspondance utilisateur n’existe pour l’email GitHub retourné, le système peut créer un compte automatiquement et appliquer les règles d’attribution de crédits.

Limitez la durée de vie des jetons signés et consignez l’usage (logs). Préparez un mécanisme de révocation si l’installation est désinstallée côté GitHub.

L’utilisateur génère une clé d’API depuis son tableau de bord. Affichez la clé une seule fois et incitez à la stocker de façon sécurisée.

Pour les intégrations machine-to-machine, inclure la clé dans l’en-tête d’authentification ou dans le champ dédié. La clé doit être traitée comme un secret (ne pas la logguer).

Lorsqu’une requête contient à la fois une session et une clé, vous pouvez prioriser la clé (flux server-first) ou prioriser la session selon votre règle métier. Le pattern hybride détaillé ci‑dessous montre une stratégie courante.

Permettez la révocation et la rotation des clés facilement depuis l’interface : révoquer doit révoquer instantanément l’accès.

Surveillez l’usage des clés (taux, abuse patterns) et appliquez des quotas/alertes pour prévenir la compromission.

Si une clé est fournie avec la requête, validez-la immédiatement. Si elle est valide, traitez la requête au nom de l’utilisateur associé à la clé.

En l’absence de clé, tomber back sur l’authentification par session utilisateur. Si la session est valide, poursuivre normalement.

Si une clé invalide est fournie, renvoyer une erreur explicite indiquant que la clé est invalide plutôt qu’un message générique de “non authentifié”.

Pour le suivi et la sécurité, stocker (dans le contexte de traitement) le type d’authentification utilisé : “session” ou “api_key”.

Pour les routes publiques qui acceptent les deux, afficher un message côté client expliquant comment préférer l’une ou l’autre méthode selon le cas d’utilisation (interactif vs automatisé).

Intégrer une iframe qui affiche le formulaire d’inscription ou un bouton OAuth. L’iframe doit être conçue pour envoyer un message postMessage vers le parent une fois l’action terminée.

L’iframe peut déclencher le flux OAuth ; à la fin, le serveur redirige vers une page de callback dédiée qui communique avec l’iframe via la session ou via postMessage.

Après création/connexion, l’iframe envoie un message sécurisé au parent contenant le statut (succès/erreur) et éventuellement un token temporaire. Le parent valide l’origine du message avant toute action.

Le parent peut rafraîchir sa session, fermer l’iframe et rediriger l’utilisateur vers l’état post-signup. Si un jeton temporaire est transmis, l’utiliser uniquement pour établir une session côté client, puis le supprimer.

Toujours vérifier l’origine du postMessage. N’acceptez des messages que depuis les origines explicitement autorisées et ne transmettez jamais d’informations sensibles non chiffrées.