Auth API

L'Auth API est le flux OAuth qui authentifie un ServiceUser (un abonné ordinaire du produit exploité par un Space) via la connexion sociale. Lorsque l'utilisateur se connecte avec un fournisseur (par exemple Google) rattaché à la configuration ServiceLogin, cette API délivre un accessToken et un refreshToken. L'accessToken délivré est un jeton Bearer utilisable uniquement pour les appels ACMA et ACDA ; il ne peut pas servir pour CMA ni CDA. Aucun jeton ne franchit la frontière d'identité.

L'URL de base est https://auth.weegloo.com/v1, et tous les chemins se trouvent sous /spaces/{spaceId}/.... Tous les corps de requête et de réponse sont au format JSON. Pour une application navigateur, il est recommandé d'utiliser le SDK officiel weegloo-service-user plutôt que de manipuler directement ces requêtes et réponses HTTP. Cette page décrit le format des requêtes et des réponses HTTP que ce SDK utilise en interne. Consultez-la lorsque vous implémentez le flux vous-même dans un environnement où le SDK n'est pas disponible (serveur, natif, script).

Flux de connexion

Le flux de connexion ci-dessous concerne une application de navigateur web. Les applications natives (Android, iOS) traitent le rappel différemment et sont abordées séparément dans Rappel d'application native.

La connexion se déroule en quatre étapes.

1. Dirigez le navigateur vers l'URL d'entrée de connexion (/spaces/{spaceId}/login/oauth2/{provider}). Cette URL démarre la chaîne de redirections qui mène à l'écran de connexion du fournisseur (Google).
2. Une fois la connexion terminée, Weegloo renvoie le navigateur vers le callbackUrl défini dans le ServiceLogin, en ajoutant ?exchangeToken=<jeton à usage unique> à l'adresse.
3. La page de rappel lit l'exchangeToken dans l'adresse et l'envoie au point de terminaison d'échange de jetons (POST /spaces/{spaceId}/oauth/token), qui retourne en réponse un accessToken et un refreshToken.
4. Vous appelez ensuite ACMA et ACDA avec l'accessToken comme jeton Bearer. Avant son expiration (expiresAt), renouvelez-le avec le refreshToken, et révoquez les jetons lors de la déconnexion.

L'exchangeToken est à usage unique. Retirez-le immédiatement de la barre d'adresse juste après avoir traité le rappel, afin d'éviter son exposition et sa réutilisation (le SDK s'en charge automatiquement).

Rappel d'application native : pont de deep link

Les applications natives Android et iOS se connectent elles aussi via le même flux OAuth. Toutefois, comme le callbackUrl n'accepte qu'une adresse web, la manière de les raccorder diffère.

D'après la documentation, le callbackUrl pris en charge est une adresse web comme https://.... Un schéma personnalisé enregistré par l'application, comme myapp://, est rejeté et ne peut donc pas servir directement d'adresse de rappel. C'est pourquoi une application native définit son callbackUrl sur une page pont en https déployée sur Web Hosting, et cette page transmet le ?exchangeToken=... reçu lors du rappel vers le deep link de l'application (par exemple myapp://auth/callback?exchangeToken=...). Avec cet exchangeToken, l'application effectue elle-même l'échange de jetons (étape 3 du flux de connexion ci-dessus, POST /spaces/{spaceId}/oauth/token).

• Seul l'exchangeToken à usage unique passe par le deep link. Les accessToken et refreshToken ne transitent pas par le deep link, car l'application les obtient en effectuant elle-même l'échange. La page pont retire elle aussi l'exchangeToken de l'adresse après l'avoir transmis (même principe que le rappel du flux de connexion).
• Utilisez autant que possible des deep links vérifiés (Android App Links, iOS Universal Links). Un schéma personnalisé non vérifié peut être intercepté par une autre application installée sur l'appareil.
• Créez le client OAuth du fournisseur (par exemple Google) de type Web application, même pour une application native, car la redirection OAuth ne pointe pas vers l'application mais vers auth.weegloo.com (une adresse web).

La façon de déployer la page pont est traitée dans Web Hosting.

Modèle de jetons

L'échange et le renouvellement de jetons retournent une réponse de jetons de même forme. Les chaînes de jetons et les horodatages contenus dans la réponse correspondent aux valeurs d'exemple ci-dessous ; en réalité ce sont des chaînes secrètes opaques (comme le flux passe par la connexion du fournisseur, les valeurs réelles ne peuvent pas être reproduites telles quelles).

{
  "accessToken": "QY3xK9pR2mLs7Vc0Zt8Nf4Wd1Bj6Hg5Ua2Ee9Ck3PoZt8Nf4Wd",
  "tokenType": "Bearer",
  "scope": ["APP"],
  "createdAt": "2026-06-18T05:00:00.000Z",
  "expiresAt": "2026-06-19T05:00:00.000Z",
  "refreshToken": "Rf7Hn2Qw9Zx4Tp1Lk6Vc3Bm8Yd5Gs0Ae2Uj7Co4NeLk6Vc3Bm",
  "refreshExpiresAt": "2026-06-21T05:00:00.000Z"
}

La durée de vie des trois jetons est la suivante.

• L'exchangeToken est à usage unique et de courte durée. Il doit être échangé aussitôt après le rappel. Il n'est pas inclus dans la réponse d'échange ; il est transmis dans l'adresse à l'étape 2 du flux de connexion.
• La durée de vie de l'accessToken n'est pas une valeur fixe. L'instant exact d'expiration est porté par le champ expiresAt de la réponse, c'est donc cette valeur qui fait foi. L'accessToken est réservé à ACMA et ACDA.
• Le refreshToken est valable trois jours après sa délivrance (refreshExpiresAt). Lorsque vous appelez le renouvellement, une nouvelle paire accessToken et refreshToken est délivrée et l'ancienne paire est révoquée (rotation). À chaque renouvellement, le refreshToken précédent n'est plus utilisable.

API

L'URL de base des quatre points de terminaison ci-dessous est dans tous les cas https://auth.weegloo.com/v1. Ils sont présentés dans l'ordre suivant : entrée de connexion (GET), échange de jetons (POST), renouvellement de jetons (POST), déconnexion (DELETE).

Documents connexes

• Connexion ServiceUser (concept) : comment configurer le ServiceLogin dans le studio de contenu.
• ACMA : l'API qui manipule le contenu des membres avec le jeton délivré.
• ACDA : l'API de lecture transmise aux membres.