Bien démarrer

OAuth2 et PKCE

Distinguez la connexion au nœud, les redirections d’application et la limite actuelle de l’accès API délégué.

Deux usages différents d’OAuth

Un nœud Lyra peut utiliser Google, GitHub, Discord ou Apple comme fournisseur d’identité pour connecter un utilisateur. Ce flux serveur par code d’autorisation utilise PKCE et un état CSRF à usage unique. Il connecte une personne à Lyra ; il n’autorise pas une application tierce à appeler l’API Lyra.

L’accès délégué tiers n’est pas public en V1

Lyra ne publie actuellement aucun endpoint OAuth2 d’autorisation ou de jeton pour les applications développeurs. Utilisez les jetons Bot pour les intégrations et la session Lyra normale uniquement pour les actions humaines internes. Le champ URI de redirection est réservé au futur flux délégué et ne doit pas être présenté comme une prise en charge active.

Flux PKCE de connexion au nœud

  • GET /auth/oauth/providers ne liste que les fournisseurs activés par l’administrateur du nœud
  • GET /auth/oauth/:provider/authorize crée un état aléatoire et un vérificateur PKCE conservés brièvement dans Redis
  • Le callback consomme l’état une seule fois, échange le code puis associe l’identité vérifiée
  • Le navigateur reçoit les identifiants Lyra renouvelables, jamais le jeton du fournisseur

Sécurité des URI de redirection

Les URI d’application sont validées comme URL HTTP ou HTTPS absolues. HTTP n’est accepté que pour le développement sur localhost. Le futur flux délégué devra imposer une correspondance exacte, PKCE S256, des codes courts à usage unique et des scopes explicites avant de rendre ce champ opérationnel.

text
https://app.example.com/oauth/lyra/callback
http://localhost:5173/callback