Vue d’ensemble
Ayeba agit comme fournisseur d’identité. Après autorisation par l’utilisateur, votre application reçoit des jetons lui permettant de reconnaître de façon stable la même personne à travers vos services, sans gérer elle-même le mot de passe Ayeba.
Les identifiants de votre application (client_id, client_secret, redirect URIs) sont délivrés exclusivement dans la console OAuth après authentification. Ils ne sont pas publiés sur les pages marketing du site.
Découverte OpenID
Comme pour tout fournisseur OpenID Connect conforme, les endpoints publics sont décrits dans le document de découverte. Votre serveur doit lire ce document plutôt que de coder en dur des chemins susceptibles d’évoluer :
https://ayeba.app/.well-known/openid-configuration
Ce document expose notamment les adresses d’autorisation, d’échange de jetons et d’informations utilisateur, ainsi que les algorithmes de signature des id_token.
Flux authorization code
Le flux recommandé pour les applications serveur est le code d’autorisation ( response_type=code. L’utilisateur est redirigé vers Ayeba, s’authentifie et consent, puis revient sur votre redirect_uri avec un code à courte durée de vie.
L’échange du code contre des jetons s’effectue uniquement côté serveur, avec votre client_secret (ou PKCE pour les clients publics). Ne placez jamais le secret dans une application frontale, un dépôt public ou une URL.
Paramètres usuels de la requête d’autorisation : client_id, redirect_uri (exactement enregistrée), scope, state (anti-CSRF), et le cas échéant code_challenge.
Scopes
- openid — identité OpenID ; nécessaire pour recevoir un id_token.
- email — adresse e-mail associée au compte Ayeba.
- profile — nom affiché et éléments de profil.
Demandez uniquement ce dont votre produit a réellement besoin. Un usage excessif des scopes peut retarder ou empêcher la vérification de l’application.
Clients publics (PKCE)
Pour les applications qui ne peuvent pas conserver un secret (certaines SPA, clients natifs), utilisez PKCE avec la méthode S256 : un code_challenge à l’étape d’autorisation, puis le code_verifier lors de l’échange de jetons. Même dans ce cas, validez toujours le paramètre state et restreignez les redirect URIs.
Profil utilisateur
Après obtention d’un access_token, votre serveur peut consulter l’endpoint userinfo (découvert via OpenID Configuration) pour lire l’identifiant stable sub et, selon les scopes accordés, l’e-mail et le profil. Traitez sub comme clé primaire d’identité côté votre application — pas l’e-mail seul, qui peut évoluer.
Bonnes pratiques
- Échangez les codes et stockez les secrets uniquement côté serveur.
- Utilisez HTTPS en production pour toutes les redirect URIs.
- Vérifiez le paramètre state à chaque retour d’autorisation.
- Révoquez et régénérez un secret dès qu’il a pu être exposé.
- Informez clairement vos utilisateurs de l’usage que vous faites de leurs données.
- Respectez la politique développeurs et les droits des personnes décrits sur ayeba.app/droits.