Je ne connais pas assez votre stack ou votre cas d’utilisation, mais je pense avoir déjà résolu un problème similaire, et certaines idées pourraient vous être utiles.
J’ai une application Next.js où j’ai besoin que le côté client ait un JWT valide pour effectuer des appels à mon API backend s’il existe une session Discourse.
Pour cela, j’utilise Discourse comme mon fournisseur d’identité via DiscourseConnect.
Dans mon cas, je fais cela avec un seul appel fetch côté client avec { credentials: "include" }, ce qui ne fonctionne que parce que j’ai tout configuré avec un seul domaine et que l’appel fetch suit transparentement les redirections.
Mon client récupère un /auth/token personnalisé, qui vérifie l’existence de _t (juste pour éviter une redirection inutile sinon) et renvoie une redirection vers une URL sécurisée /session/sso_provider construite selon la documentation du sujet lié, avec nonce/sso/sig, et une return_sso_url pointant vers un /auth/callback personnalisé, qui extraira les données envoyées par Discourse, construira et renverra un jeton JWT que mon client pourra utiliser à partir de ce moment-là.
Je pense que votre cas d’utilisation peut être résolu de manière similaire.