Documentation

Premiers pas

Authagonal fournit à chaque locataire un serveur OIDC entièrement conforme aux standards. Chaque locataire obtient sa propre URL d'émetteur, son document de découverte et ses points de terminaison de jetons — aucune infrastructure partagée entre les locataires. Vous pouvez passer de zéro à un flux de connexion fonctionnel en moins de 5 minutes.

Créer un tenant

Inscrivez-vous sur authagonal.io et choisissez un slug pour votre tenant. Le slug devient votre domaine d'émetteur : {slug}.authagonal.io. Après avoir créé votre compte, vérifiez votre adresse e-mail pour activer le tenant.

Choisissez un slug unique pour votre tenant lors de l'inscription

Enregistrer un client

Naviguez vers Clients dans la barre latérale du portail et cliquez sur Créer. Entrez un clientId et un clientName pour votre application. Ensuite, configurez au moins une URI de redirection — c'est là où les utilisateurs sont envoyés après l'authentification. Par exemple : https://app.example.com/callback.

Enregistrer un nouveau client OAuth dans le portail

Votre première connexion

Le moyen le plus rapide de s'intégrer est avec oidc-client-ts, une bibliothèque client OIDC légère pour les applications JavaScript et TypeScript.

import { UserManager } from 'oidc-client-ts';

const mgr = new UserManager({
  authority: 'https://acme.authagonal.io',
  client_id: 'my-app',
  redirect_uri: 'https://app.example.com/callback',
  response_type: 'code',
  scope: 'openid profile email',
});

// Redirect to login
mgr.signinRedirect();

// On callback page
const user = await mgr.signinRedirectCallback();
console.log(user.profile); // { sub, email, name, ... }

Si vous préférez une approche minimale sans bibliothèque, vous pouvez utiliser le flux standard OAuth 2.0 authorization code avec un simple fetch :

// 1. Redirect the user to the authorization endpoint
const authorizeUrl = new URL('https://acme.authagonal.io/connect/authorize');
authorizeUrl.searchParams.set('client_id', 'my-app');
authorizeUrl.searchParams.set('redirect_uri', 'https://app.example.com/callback');
authorizeUrl.searchParams.set('response_type', 'code');
authorizeUrl.searchParams.set('scope', 'openid profile email');
authorizeUrl.searchParams.set('code_challenge', codeChallenge);
authorizeUrl.searchParams.set('code_challenge_method', 'S256');
window.location.href = authorizeUrl.toString();

// 2. On the callback page, exchange the code for tokens
const res = await fetch('https://acme.authagonal.io/connect/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: new URLSearchParams(window.location.search).get('code')!,
    redirect_uri: 'https://app.example.com/callback',
    client_id: 'my-app',
    code_verifier: codeVerifier,
  }),
});

const tokens = await res.json();
// tokens.id_token, tokens.access_token, tokens.refresh_token

La page de connexion par défaut de votre locataire

Tableau de bord

Le tableau de bord du portail vous donne un aperçu en temps réel de votre locataire. Il met en évidence les métriques les plus importantes — croissance des utilisateurs, activité d'authentification et navigation rapide vers chaque fonctionnalité du portail.

Vue d'ensemble

En haut du tableau de bord, vous verrez un message de bienvenue ainsi que votre nombre total d'utilisateurs actuel. En dessous, un graphique Utilisateurs actifs quotidiens affiche un historique sur 7 jours des utilisateurs uniques qui se sont authentifiés chaque jour, vous donnant un aperçu rapide des tendances d'engagement.

L'écran d'accueil du tableau de bord avec le graphique DAU et l'aperçu de l'activité

Métriques d'activité

Le panneau de métriques d'activité affiche quatre cartes de statistiques résumant les principaux événements d'authentification :

• Connexions réussies — flux d'authentification complètes
• Connexions échouées — identifiants incorrects, comptes verrouillés ou rejets de politique
• Utilisateurs actifs — utilisateurs uniques qui se sont authentifiés pendant la période selectionnee
• Opérations SCIM — événements de provisionnement d'utilisateurs et de groupes depuis les IdP connectés

Utilisez les filtres de plage temporelle pour basculer entre 24 heures, 3 jours, 7 jours et 30 jours. Toutes les cartes de statistiques et les graphiques se mettent à jour pour refleter la fenêtre selectionnee.

Métriques d'activité avec plage temporelle configurable

Navigation rapide

Sous le panneau de métriques, des cartes de navigation renvoient directement vers chaque fonctionnalité majeure : Clients, Utilisateurs, Groupes, Rôles, SSO, SCIM, Personnalisation et Paramètres. Chaque carte affiche une brève description pour que les nouveaux membres de l'équipe puissent s'orienter rapidement.

Clients

Les clients OAuth représentent les applications qui authentifient les utilisateurs via votre locataire. Chaque client a sa propre configuration pour les URI de redirection, les portées, les types de grants, les durées de vie des jetons et la politique MFA.

Liste des clients

La page Clients affiche un tableau de tous les clients enregistrés. Chaque ligne montre le clientId, le nom d'affichage, les types de grants autorisés sous forme de badges colorés, et si PKCE est activé. Cliquez sur n'importe quelle ligne pour ouvrir l'éditeur de configuration complet.

Liste des clients avec badges de types de grants et indicateurs PKCE

Créer un client

Cliquez sur Créer un client pour enregistrer une nouvelle application. Vous devez fournir deux champs :

• clientId — un identifiant unique pour le client (par ex. my-spa)
• clientName — un nom d'affichage lisible

Enregistrer un nouveau client OAuth

Supprimer un client

Pour supprimer un client, ouvrez la configuration du client et cliquez sur le bouton Supprimer le client en bas de la page. Une confirmation vous sera demandée avant que le client ne soit définitivement supprimé. Toutes les sessions actives et les jetons du client supprimé sont immédiatement invalides.

Référence de configuration du client

Chaque client dispose d'un ensemble complet d'options de configuration organisées en plusieurs sections.

Paramètres généraux

URIs

Les champs URI utilisent une saisie par tags — tapez une valeur et appuyez sur Entrée ou virgule pour l'ajouter. Cliquez sur le X d'un tag pour le supprimer.

Champs de saisie par tags pour la configuration des URIs

Portées et types de grants

Durées de vie des jetons

Configurer les durées de vie des jetons par client

URI de déconnexion

Les clients peuvent enregistrer des URI de déconnexion back-channel et front-channel. Les deux sont optionnelles — configurez celle qui correspond à la façon dont votre application efface sa session.

Politique MFA

Chaque client peut remplacer la politique MFA du tenant par un paramètre par client. Le menu déroulant de politique MFA propose trois options :

Remplacement de politique MFA par client

SSO Entreprise

Le SSO entreprise permet à vos clients d'utiliser leur propre fournisseur d'identité. Authagonal prend en charge la fédération SAML 2.0 et OIDC avec routage par domaine, de sorte que les utilisateurs sont automatiquement diriges vers le bon IdP en fonction de leur adresse e-mail.

Routage SSO par domaine

Connexions SAML 2.0

Pour créer une connexion SAML, naviguez vers la page SSO et sélectionnez l'onglet SAML. Fournissez les informations suivantes :

Lorsque vous enregistrez la connexion, Authagonal récupère le document de métadonnées et importe le certificat de signature de l'IdP, l'URL du point de terminaison SSO et le format d'identifiant de nom. Les métadonnées sont périodiquement rafraîchies pour prendre en compte les rotations de certificats.

Créer une connexion SSO SAML 2.0

Connexions OIDC

Pour créer une connexion de fédération OIDC, sélectionnez l'onglet OIDC et fournissez :

Créer une connexion de fédération OIDC

Routage par domaine

Le routage par domaine redirige automatiquement les utilisateurs vers le bon fournisseur d'identité en fonction de leur domaine d'e-mail. Lorsqu'un utilisateur entre son e-mail sur la page de connexion, Authagonal vérifié si la partie domaine (par ex. acme.com) correspond a une connexion SSO configurée. Si c'est le cas, l'utilisateur est redirigé de manière transparente vers l'IdP de son organisation.

Le routage par domaine associe les domaines d'e-mail aux fournisseurs d'identité

Provisionnement JIT

Par défaut, lorsqu'un utilisateur se connecte via SSO pour la première fois et n'existe pas encore dans votre locataire, Authagonal crée automatiquement son compte (provisionnement Just-In-Time). Cela peut être désactivé par connexion en cochant Désactiver le provisionnement JIT lors de la création ou de la modification de la connexion.

Lorsque le provisionnement JIT est désactivé, seuls les utilisateurs qui ont été pré-provisionnés — via SCIM, la page Utilisateurs du portail ou l'API — peuvent se connecter via cette connexion. Les utilisateurs inconnus reçoivent une erreur access_denied et sont invités à contacter leur administrateur.

Utilisateurs

La page Utilisateurs vous permet de gérer tous les utilisateurs finaux de votre locataire. Vous pouvez rechercher des utilisateurs, voir leurs détails, créer de nouveaux comptes et voir comment chaque utilisateur a été provisionné.

Recherche et pagination

La barre de recherche prend en charge le filtrage par adresse e-mail ou identifiant utilisateur. La recherche est debounced à 300 ms pour que les résultats se mettent à jour au fur et à mesure de la saisie sans surcharger l'API. Les résultats sont pagines à 50 utilisateurs par page — utilisez les contrôles de navigation en bas du tableau pour naviguer entre les pages.

Tableau des utilisateurs

Le tableau des utilisateurs affiche les colonnes suivantes pour chaque utilisateur :

La liste des utilisateurs avec barre de recherche et pagination

Créer des utilisateurs

Cliquez sur Créer un utilisateur pour ajouter un nouvel utilisateur local. Le formulaire requiert :

Créer un nouvel utilisateur local

Langue préférée

Chaque utilisateur dispose d'une langue préférée qui pilote à la fois son interface hébergée et les e-mails transactionnels qu'Authagonal lui envoie (vérification, réinitialisation de mot de passe, bienvenue, et plus). Vous pouvez la définir lors de la création d'un utilisateur et la modifier à tout moment depuis sa page de détail. Si aucune langue préférée n'est définie, Authagonal se replie sur l'anglais. Le sélecteur propose toutes les langues prises en charge : anglais, allemand, français, espagnol, portugais, vietnamien et chinois simplifié.

Définir la langue préférée d'un utilisateur sur sa page de détail

Détail de l'utilisateur

Cliquez sur n'importe quelle ligne de la liste des utilisateurs pour ouvrir sa page de détail. De là, vous pouvez modifier les données du profil, gérer les rôles, réinitialiser la MFA, consulter les attributs personnalisés et supprimer l'utilisateur.

Profil

Modifiez l'e-mail, le prénom/nom, le téléphone, l'entreprise, l'ID externe et l'indicateur actif de l'utilisateur. Les changements d'e-mail doivent rester uniques dans le locataire ; l'API renvoie email_in_use s'il est déjà pris.

Rôles

Attribuez et retirez les rôles définis sur la page Rôles. L'appartenance aux rôles est incluse dans les jetons ID et d'accès lorsque le client a includeRolesInTokens activé.

Authentification multifacteur

Consultez chaque identifiant MFA enregistré pour l'utilisateur — application d'authentification (TOTP), WebAuthn/passkeys et codes de récupération — chacun avec ses horodatages d'enregistrement et de dernière utilisation. Supprimez des identifiants individuels ou réinitialisez toute la MFA. Réinitialiser force l'utilisateur à s'inscrire à nouveau à sa prochaine connexion.

Attributs personnalisés

Données clé/valeur arbitraires attachées à l'utilisateur. Les clés doivent être uniques. Les attributs sont exposés via l'API de profil utilisateur et SCIM, et peuvent être mappés sur des revendications du jeton d'accès en configurant les userClaims d'une portée personnalisée.

Supprimer l'utilisateur

Supprime définitivement l'utilisateur et toutes ses identifiants MFA. Saisissez l'e-mail de l'utilisateur pour confirmer — aucune annulation possible.

Groupes

Les groupes vous permettent d'organiser les utilisateurs et d'inclure l'appartenance aux groupes dans les jetons. Les groupes peuvent être créés manuellement dans le portail ou provisionnés automatiquement via SCIM depuis un fournisseur d'identité externe.

Liste des groupes

La page Groupes affiche tous les groupes de votre locataire avec les informations suivantes :

Liste des groupes avec indicateurs de source

Créer un groupe

Cliquez sur Créer un groupe et entrez un displayName pour le groupe. Les noms de groupes doivent être descriptifs et uniques au sein de votre locataire (par ex. "Engineering", "Billing Admins", "Beta Testers").

Détail du groupe et membres

Cliquez sur n'importe quel groupe pour ouvrir la vue de détail. Ici, vous pouvez voir tous les membres actuels et gérer l'appartenance :

• Ajouter des membres — Entrez un identifiant utilisateur pour ajouter un utilisateur au groupe.
• Supprimer des membres — Cliquez sur le bouton de suppression à côté d'un membre pour le retirer individuellement.

Gérer l'appartenance au groupe dans la vue de détail

Groupes dans les jetons

Lorsque includeGroupsInTokens est activé sur un client, le jeton ID inclut une revendication groups contenant les appartenances aux groupes de l'utilisateur. Chaque entrée inclut l'id et le name du groupe :

{
  "sub": "user-123",
  "email": "[email protected]",
  "groups": [
    { "id": "grp-001", "name": "Engineering" },
    { "id": "grp-002", "name": "Beta Testers" }
  ]
}

Rôles

Les rôles prennent en charge le contrôle d'accès basé sur les rôles (RBAC) dans votre application. Définissez les rôles dans Authagonal, assignez-les aux utilisateurs et utilisez la revendication roles dans les jetons pour appliquer l'autorisation dans la logique de votre application.

Gestion des rôles

La page Rôles affiche un tableau de tous les rôles définis avec édition en ligne. Chaque rôle possède :

Créer un rôle

Cliquez sur Créer un rôle et fournissez un nom et une description. Les noms de rôles doivent être concis et suivre une convention de nommage coherente dans votre application (par ex. minuscules avec tirets : billing-admin).

Édition en ligne

Les rôles supportent l'édition en ligne directement dans le tableau. Cliquez sur l'icône de crayon sur n'importe quel rôle pour entrer en mode édition — les champs de nom et de description deviennent modifiables. Modifiez les valeurs, puis cliquez sur l'icône de coche pour enregistrer. Les modifications prennent effet immédiatement.

Supprimer un rôle

Cliquez sur l'icône de suppression sur n'importe quel rôle pour le retirer. Une confirmation vous sera demandée avant que le rôle ne soit définitivement supprimé. La suppression d'un rôle n'invalide pas retroactivement les jetons existants — le rôle sera absent des nouveaux jetons émis après la suppression.

Édition en ligne des rôles dans le tableau des rôles

Rôles dans les jetons

Les rôles assignés à un utilisateur sont inclus en tant que revendication roles dans le jeton ID. Votre application peut lire cette revendication pour prendre des décisions d'autorisation :

{
  "sub": "user-123",
  "email": "[email protected]",
  "roles": ["admin", "billing-admin"]
}

Provisionnement SCIM

SCIM 2.0 (System for Cross-domain Identity Management) permet le provisionnement automatique des utilisateurs et des groupes depuis les fournisseurs d'identité d'entreprise comme Okta, Azure AD, OneLogin et JumpCloud. Une fois configuré, les comptes utilisateurs et les appartenances aux groupes sont automatiquement synchronisés depuis l'IdP en amont vers votre locataire Authagonal.

Synchronisation du cycle de vie des utilisateurs SCIM avec provisionnement en aval

Étapes de configuration

Suivez ces étapes pour activer le provisionnement SCIM pour un client :

1. Sélectionnez l'application cliente — Choisissez le client OAuth auquel le provisionnement SCIM sera associe.
2. Générez un jeton SCIM — Fournissez une description et une période d'expiration en jours, puis générez le jeton.
3. Copiez le jeton immédiatement — La valeur brute du jeton n'est affichée qu'une seule fois. Copiez-la avant de fermer la boîte de dialogue.
4. Configurez votre IdP — Dans les paramètres SCIM de votre fournisseur d'identité, entrez l'URL de base et le jeton bearer.
5. Testez la synchronisation des utilisateurs — Déclenchez une synchronisation de test depuis votre IdP et vérifiez que les utilisateurs apparaissent dans le portail Authagonal.

URL de base SCIM

Configurez votre fournisseur d'identité avec l'URL de base suivante :

https://{slug}.authagonal.io/scim/v2

Remplacez {slug} par le slug de votre locataire.

Page de configuration SCIM avec génération de jetons

Gestion des jetons

Les jetons SCIM authentifient les requêtes de provisionnement depuis votre IdP. Vous pouvez gérer plusieurs jetons par client :

Pour révoquer un jeton, cliquez sur le bouton Révoquer à côté de celui-ci. Les jetons révoqués restent visibles dans la liste a des fins d'audit mais cessent immédiatement d'accepter les requêtes.

Gestion des jetons avec indicateurs de jetons actifs et révoqués

Test de connectivite

Vérifiez que votre intégration SCIM fonctionne en interrogeant le point de terminaison ServiceProviderConfig :

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://acme.authagonal.io/scim/v2/ServiceProviderConfig

Une réponse réussie renvoie un document JSON décrivant les fonctionnalités SCIM prises en charge, y compris les opérations en masse, le filtrage et la capacité de changement de mot de passe.

Portées OAuth

Les portées permettent aux clients de demander des portions spécifiques des données ou autorisations d'un utilisateur. Authagonal prend en charge les portées OIDC standards et les portées personnalisées que vous définissez pour vos API.

Portées intégrées

Portées personnalisées

Définissez vos propres portées sur la page Portées. Chaque portée décrit une autorisation ou une ressource qu'un client peut demander (par exemple, billing.read, orders.write).

Revendications personnalisées sur les jetons

Les revendications personnalisées ont deux moitiés. La source est constituée de données par utilisateur : chaque AuthUser dispose d'un dictionnaire customAttributes que vous pouvez peupler depuis le portail (Utilisateurs → utilisateur → Attributs personnalisés), via SCIM, ou via un hook de provisionnement TCC. La libération est par portée : la liste userClaims de chaque portée nomme les clés autorisées à quitter le serveur.

Quand un client demande des portées, Authagonal parcourt les portées accordées, fait l'union de leurs listes userClaims et émet uniquement ces clés depuis les customAttributes de l'utilisateur. Les clés inconnues sont silencieusement ignorées — un client ne peut pas lire un attribut en devinant son nom. Les revendications OIDC standard (sub, email, name, etc.) suivent la spécification et ne sont pas soumises à la liste d'autorisation.

# 1. On the user (Portal → Users → {user} → Custom Attributes)
department = "engineering"
employee_id = "E-1042"
seat_tier = "enterprise"

# 2. On a custom scope (Portal → Scopes → projects.read)
name        = "projects.read"
userClaims  = ["department", "seat_tier"]   # <-- whitelist

# 3. Client requests scope=openid projects.read
# Decoded access token (relevant fields only):
{
  "sub": "u-9b…",
  "scope": "openid projects.read",
  "department": "engineering",
  "seat_tier":  "enterprise"
  // employee_id is NOT emitted — it's not in the whitelist for any granted scope.
}

Attribuer des portées aux clients

Ajoutez les portées autorisées dans l'onglet Clients → Portées & Grants. Un client ne peut demander que les portées qui lui ont été accordées ; les portées inconnues sont rejetées avec invalid_scope.

Personnalisation de marque

Personnalisez l'apparence des pages de connexion de votre tenant. Les paramètres de personnalisation vous permettent d'adapter l'expérience d'authentification à l'identité visuelle de votre produit — des logos et couleurs aux remplacements CSS avancés.

Apparence

Paramètres d'apparence avec aperçu des couleurs en direct

Informations de contact

Options de la page de connexion

Contrôlez les éléments qui apparaissent sur la page de connexion de votre tenant :

Exemple de page de connexion avec personnalisation de marque appliquee

CSS personnalisé

Pour un contrôle total sur l'apparence de la page de connexion, fournissez une URL de fichier CSS dans vos paramètres de charte graphique. Le fichier est chargé après les styles par défaut, vos règles prennent donc le pas.

Mode sombre

L'application de connexion propose des thèmes clair, sombre et système. Les utilisateurs choisissent via un bouton bascule sur la page de connexion ; le choix est conservé entre les sessions. En mode system, la SPA suit prefers-color-scheme en temps réel.

Les valeurs claires sont déclarées dans :root ; les remplacements sombres sont limités à .dark. Le branding du locataire via customCssUrl prévaut toujours — vos couleurs sont préservées quel que soit le thème choisi par l'utilisateur.

Paramètres

Configurez les politiques de sécurité, les webhooks et les paramètres d'environnement à l'échelle du tenant. Ces paramètres s'appliquent globalement à tous les clients sauf s'ils sont remplaces au niveau du client.

Politique de mot de passe

Définissez les exigences de complexité des mots de passe pour tous les utilisateurs de votre locataire :

Configuration de la politique de mot de passe

Politique MFA

La politique MFA à l'échelle du tenant définit le comportement par défaut de l'authentification multi-facteurs. Les clients individuels peuvent remplacer ce paramètre.

Session et verrouillage

Contrôlez la durée des sessions et le comportement de verrouillage des comptes :

Configuration de la session et du verrouillage

Webhooks

Les webhooks vous permettent de réagir aux événements d'authentification en temps réel. Deux événements (onUserAuthenticated, onTokenIssued) sont applicables — par défaut ils se déclenchent de manière asynchrone et ne bloquent pas l'utilisateur, mais vous pouvez activer l'application par événement pour qu'une réponse non 2xx ou un corps {"allow": false} rejette l'action. Les autres événements sont des notifications — toujours fire-and-forget, ne bloquent jamais.

Paramètres de webhook supplémentaires :

Configuration des événements webhook

Vérifier les webhooks

Une fois qu'une URL de webhook est configurée, Authagonal génère un secret de signature propre au tenant (une valeur whsec_… affichée en lecture seule dans Paramètres → Webhooks). Chaque livraison sortante porte un en-tête X-Authagonal-Signature: t=<unix>,v1=<hex>, où v1 vaut HMAC-SHA256(secret, "{t}.{body}") calculé sur le corps brut de la requête. Recalculez-le sur votre point de terminaison et comparez en temps constant pour confirmer que la requête provient réellement d'Authagonal et n'a pas été altérée — et rejetez les livraisons dont le t est trop ancien afin de bloquer les rejeux.

import crypto from 'node:crypto';

// rawBody MUST be the exact bytes Authagonal sent — verify before any JSON re-serialization.
function verifyAuthagonalWebhook(signatureHeader, rawBody, signingSecret) {
  const parts = Object.fromEntries(signatureHeader.split(',').map((p) => p.split('=')));
  const { t, v1 } = parts;

  // Replay protection: reject deliveries older than 5 minutes.
  if (Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;

  const expected = crypto
    .createHmac('sha256', signingSecret)
    .update(`${t}.${rawBody}`)
    .digest('hex');

  return v1.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(v1), Buffer.from(expected));
}

Fenêtre de maintenance

Définissez une fenêtre de maintenance préférée pour les opérations perturbantes telles que les rotations de certificats et les mises à jour d'infrastructure. Choisissez une heure UTC (0-23) — le portail affiche également l'heure équivalente dans votre fuseau horaire local pour plus de commodite.

Environnement bac à sable

L'environnement bac à sable est un clone complet de votre locataire de production, disponible à une URL séparée. Utilisez-le pour tester les modifications de configuration, les intégrations SSO et les points de terminaison webhook sans affecter les utilisateurs en direct.

Le bac à sable est accessible a {slug}-sandbox.authagonal.io.

Contrôles de l'environnement bac à sable

Facturation

Gérez votre abonnement et votre facturation via la page Facturation du portail. Cette page vous donne un aperçu de votre plan actuel et fournit l'accès au portail de facturation Stripe pour gérer les moyens de paiement, les facturés et les changements de plan.

Informations d'abonnement

La page de facturation affiche les détails de votre abonnement actuel en un coup d'oeil. Vous verrez un badge de statut indiquant l'état de votre abonnement — active, trialing, past_due, canceled ou unpaid — ainsi que le nom de votre plan, la période de facturation actuelle (dates de début et de fin), et si votre abonnement est configuré pour s'annuler a la fin de la période en cours.

Gérer l'abonnement

Cliquez sur le bouton Gérer l'abonnement pour ouvrir le portail de facturation Stripe dans une nouvelle fenêtre. De la, vous pouvez mettre à jour vos moyens de paiement, consulter et télécharger les facturés, changer de plan ou annuler votre abonnement.

Si aucun abonnement n'existe encore, un bouton Configurer la facturation est affiché à la place, qui vous guide dans le choix d'un plan et la saisie des informations de paiement.

La page de facturation affiche les détails de votre abonnement actuel et fournit l'accès à Stripe

Domaines personnalisés

Servez vos pages d'authentification depuis votre propre domaine (par ex. auth.votredomaine.com) au lieu du domaine par défaut {slug}.authagonal.io. Les domaines personnalisés offrent à vos utilisateurs une expérience d'authentification transparente et personnalisée.

Ajouter un domaine

Entrez le nom d'hôte que vous souhaitez utiliser dans le formulaire d'ajout de domaine (par ex. auth.votredomaine.com). Une fois ajouté, le domaine apparaîtra dans votre liste de domaines avec le statut pending_verification.

Vérification DNS

Créez un enregistrement CNAME pointant votre domaine vers {slug}.authagonal.io. Une fois l'enregistrement DNS en place, cliquez sur Vérifier pour contrôler la propagation DNS.

auth.yourdomain.com.  CNAME  acme.authagonal.io.

Certificats TLS

Une fois votre domaine vérifié, vous avez besoin d'un certificat TLS pour que les utilisateurs puissent se connecter en toute sécurité via HTTPS. Authagonal prend en charge deux options :

Automatique (cert-manager) — Authagonal provisionné et renouvelle automatiquement les certificats TLS avec cert-manager. C'est l'option recommandée pour la plupart des utilisateurs. Aucune configuration supplémentaire n'est requise.

Apportez le votre (BYO) — Téléchargez votre propre certificat et clé privée au format PEM. Cette option est utile si votre organisation exige des certificats d'une autorite de certification spécifique. L'expiration du certificat est suivie pour que vous puissiez le renouveler avant qu'il n'expire.

Statut du domaine

Chaque domaine affiche un badge de statut indiquant son état actuel : pending_verification (DNS non encore confirmé), verified (DNS confirmé, TLS en attente), active (entièrement opérationnel) ou failed (problème de configuration détecté).

La liste des domaines affiche chaque domaine personnalisé et son statut actuel

Téléchargez votre propre certificat TLS et clé privée au format PEM

Configuration des e-mails

Configurez la façon dont votre locataire envoie les e-mails transactionnels — vérification, réinitialisation de mot de passe et notifications MFA. Choisissez entre l'expéditeur partagé par défaut, un domaine personnalisé vérifié via Resend, ou votre propre serveur SMTP.

E-mails localisés

Les e-mails transactionnels sont envoyés dans la langue préférée du destinataire. Les e-mails de vérification, de réinitialisation de mot de passe, de compte existant, de bienvenue, de facturation et d'invitation d'administrateur sont disponibles en sept langues : anglais, allemand, français, espagnol, portugais, vietnamien et chinois simplifié. Lorsqu'aucun modèle n'existe pour la langue du destinataire, l'e-mail se replie sur l'anglais.

La langue est résolue à partir de la préférence enregistrée du destinataire au moment de l'envoi. Cette préférence peut provenir de plusieurs sources :

• Inscription et enregistrement — capturée à partir de la langue choisie par l'utilisateur sur les écrans de connexion hébergés.
• La page Utilisateurs du portail — définie par un administrateur lors de la création ou de la modification d'un utilisateur.
• Le provisionnement SCIM — mappé depuis le preferredLanguage de l'IdP lorsque les utilisateurs sont synchronisés via SSO.
• La page de compte en libre-service — choisie par l'utilisateur lui-même sur /login/account.

Fournisseurs d'e-mails

Identité de l'expéditeur

L'e-mail et le nom de l'expéditeur sont partagés entre tous les modes de fournisseur. L'e-mail de l'expéditeur est requis ; à défaut, le nom revient à celui du locataire.

Domaine personnalisé Resend

Vérifiez votre domaine d'envoi auprès de Resend une seule fois, puis utilisez-le comme adresse d'expéditeur pour ce locataire. Les enregistrements DNS TXT (SPF, DKIM) sont fournis par la page Domaines ; Resend les valide automatiquement.

SMTP personnalisé

Apportez votre propre serveur SMTP — utile pour les relais internes, les prestataires non pris en charge par Resend, ou la conformité réglementaire.

Domaine d'envoi personnalisé

Avec le fournisseur Resend, vous pouvez enregistrer votre propre domaine pour que les e-mails proviennent de votre marque (par ex. [email protected]) au lieu de @authagonal.io.

1. Allez dans Paramètres → E-mail et sélectionnez le fournisseur Domaine personnalisé Resend.
2. Saisissez votre nom de domaine et cliquez sur Enregistrer.
3. Ajoutez les enregistrements DNS affichés (DKIM, SPF et return path) au DNS de votre domaine.
4. Cliquez sur Vérifier la vérification — une fois le DNS propagé (généralement 1 à 10 minutes), le statut du domaine passera à vérifié.

Tests

Utilisez le bouton Envoyer un e-mail de test dans Paramètres → E-mail pour vérifier votre configuration. Un e-mail de test sera envoyé à votre adresse d'administrateur avec les paramètres enregistrés.

Journal d'audit

Le journal d'audit fournit un enregistrement en lecture seule de toutes les actions administratives effectuées sur votre locataire. Chaque modification effectuée via le portail ou l'API est capturée avec un contexte complet, vous offrant une piste complète pour la conformité et le dépannage.

Colonnes du journal

Actions suivies

Les actions administratives suivantes sont enregistrées dans le journal d'audit :

Le journal d'audit fournit un enregistrement complet de toutes les actions administratives

Sauvegardes

Authagonal sauvegarde automatiquement les données de votre locataire toutes les heures. Les sauvegardes incluent tous les utilisateurs, groupes, rôles, clients, connexions SSO, jetons SCIM, la charte graphique et les paramètres. Vous pouvez consulter l'historique et télécharger la dernière sauvegarde complète depuis la page Sauvegardes.

Fonctionnement des sauvegardes

• Une sauvegarde complète s'exécute une fois par jour, capturant chaque table du shard de stockage de votre tenant.
• Les sauvegardes incrémentielles s'exécutent toutes les heures, ne capturant que les lignes modifiées depuis la dernière sauvegarde.
• Les sauvegardes sont stockées dans Azure Blob Storage avec la même identité gérée que celle de votre locataire.
• Les enregistrements supprimés sont suivis via des tombstones et inclus dans les sauvegardes à des fins d'audit.

Téléchargement des sauvegardes

Cliquez sur « Télécharger la dernière » pour obtenir un fichier ZIP contenant la sauvegarde complète la plus récente fusionnée avec toutes les sauvegardes incrémentielles suivantes. Chaque table est exportée en fichier JSONL (un objet JSON par ligne).

Applications de provisionnement

Les applications de provisionnement reçoivent des notifications webhook en temps réel lorsque des utilisateurs sont créés ou authentifiés dans votre locataire. Cela permet aux systèmes en aval de configurer automatiquement des comptes, d'attribuer des licences ou de synchroniser les données utilisateur sans intervention manuelle.

Comment ca fonctionne

Lorsqu'un événement utilisateur se produit (création ou authentification), Authagonal appelle l'URL de rappel de votre application de provisionnement en utilisant le modèle TCC (Try/Confirm/Cancel). Cette approche en trois phases garantit un provisionnement fiable à travers plusieurs systèmes en aval :

Payload du webhook

Chaque requête webhook inclut un payload JSON avec les champs suivants :

Ajouter une application de provisionnement

Pour ajouter une application de provisionnement, fournissez un nom, une URL de rappel et une clé API optionnelle. La clé API est envoyée en tant que jeton Bearer dans l'en-tête Authorization de chaque requête webhook, permettant à votre application d'authentifier les requêtes provenant d'Authagonal.

Test

Cliquez sur Tester à côté de n'importe quelle application de provisionnement pour envoyer une requête de test à votre URL de rappel. Les résultats du test affichent le code de statut HTTP et le corps de la réponse, vous aidant à vérifier que votre application reçoit et traite correctement les webhooks.

Testez les applications de provisionnement pour vérifier la livraison et le traitement des webhooks

Limites du plan

Le nombre maximum d'applications de provisionnement est configurable par locataire, avec une limite par défaut de 6. Cette limite peut être ajustée par un administrateur si votre workflow nécessite des cibles de provisionnement supplémentaires.

Équipe

La page Équipe gère les administrateurs du portail — les personnes qui peuvent accéder à votre locataire et le configurer via le portail de gestion. Tous les membres de l'équipe ont un accès administratif complet à chaque aspect de la configuration de votre locataire.

Liste des administrateurs

La liste des administrateurs affiche le nom, l'adresse e-mail et la date d'ajout de chaque membre de l'équipe. Un indicateur "Vous" est affiché à côté de la ligne de l'utilisateur actuel pour que vous puissiez facilement identifier votre propre compte.

Inviter des administrateurs

Pour inviter un nouveau membre de l'équipe, fournissez son adresse e-mail, son nom et un mot de passe temporaire (minimum 8 caractères). L'utilisateur invité se connecte avec le mot de passe temporaire et devrait le changer lors de sa première connexion.

Champs d'invitation

Les invitations d'administrateur créent un utilisateur entièrement provisionné — pas d'aller-retour par e-mail requis.

Supprimer des administrateurs

Cliquez sur Supprimer à côté de n'importe quel membre de l'équipe pour révoquer son accès. Une boîte de dialogue de confirmation s'affiche avant que la suppression ne soit finalisee. Vous ne pouvez pas vous supprimer vous-même — il doit toujours y avoir au moins un administrateur dans l'équipe.

Gérez les administrateurs du portail depuis la page Équipe

Support

Ouvrez un ticket de support auprès de l'équipe Authagonal sans quitter le portail. Chaque ticket est une conversation en fil de discussion, pour que vous et notre équipe restiez sur la même longueur d'onde, du premier signalement à la résolution.

Vos tickets

La page de support liste tous les tickets que vous avez ouverts, l'activité la plus récente en premier. Utilisez le badge de statut pour voir d'un coup d'œil ce qui attend une action de votre part et ce qui est entre nos mains.

Vos tickets de support avec objet, statut, priorité et dernière activité

• Chaque ligne affiche l'objet, le statut actuel (ouvert, en attente, résolu ou fermé), la priorité et l'heure de la dernière activité.
• Cliquez sur Nouveau ticket pour en ouvrir un, puis donnez-lui un objet, une priorité et votre premier message.
• Les badges de statut à code couleur permettent de repérer facilement dans la liste les tickets qui requièrent votre attention.

Un fil de ticket

Ouvrir un ticket affiche la conversation complète. Les réponses s'ajoutent dans l'ordre, et les nouveaux messages de notre équipe apparaissent sans recharger la page.

Un fil de ticket entre vous et l'équipe Authagonal

• Les messages en fil entre vous et l'équipe Authagonal sont affichés dans l'ordre chronologique.
• Répondez directement dans le fil et joignez des fichiers pour partager des logs, des captures d'écran ou votre configuration.
• Le fil se met à jour en direct, donc une réponse de notre équipe apparaît dès qu'elle est envoyée.
• Si vous répondez plutôt à un e-mail de notification, votre message est ajouté au fil automatiquement.

Importer et migrer

Migrez un système d’identité existant vers votre locataire Authagonal. Deux sources sont prises en charge — Duende IdentityServer (une base SQL Server) et Auth0 (la Management API). Chacune exécute un aperçu en lecture seule pour que vous vérifiiez exactement ce qui sera copié avant de valider.

Importation depuis Duende IdentityServer

Migrez les clients, portées, utilisateurs et rôles d'une base SQL Server Duende IdentityServer existante vers votre locataire Authagonal. L'importation se déroule en deux phases — aperçu et validation — afin que vous puissiez vérifier ce qui sera copié avant toute modification.

Ce qui est importé

L'importateur lit la ConfigurationDb de Duende et les tables ASP.NET Identity, puis écrit les lignes mappées dans votre locataire. Les artefacts à courte durée de vie (persisted grants, device codes, clés de signature) sont ignorés.

Aperçu avant validation

Collez votre chaîne de connexion ConfigurationDb / IdentityDb de Duende puis cliquez sur Lancer l'aperçu. L'aperçu ouvre une connexion en lecture seule et compte chaque ligne qui serait importée — aucune écriture n'a lieu.

• Décomptes d'entités pour clients, portées, utilisateurs, rôles et affectations de rôles.
• Avertissements d'écrasement lorsque le locataire cible possède déjà des clients, rôles ou portées correspondants.
• Avertissements pour les tables inconnues et colonnes non mappées afin que vous sachiez ce qui sera abandonné.

Panneau d'aperçu avec décomptes et avertissements

Empreintes de mot de passe

Duende stocke les mots de passe au format ASP.NET Identity V3 (PBKDF2). Le PasswordHasher d'Authagonal vérifie directement ce format et réhash vers le format natif à la première connexion réussie — les utilisateurs conservent leur mot de passe existant sans flux de réinitialisation.

Réconciliation des ID utilisateur

Si un utilisateur déjà présent dans ce locataire a la même adresse e-mail qu'un enregistrement entrant, l'import bascule le userId de ce compte vers le sub source avant l'importation, afin que les rôles, connexions et revendications importés soient rattachés au compte existant et que les applications qui référencent déjà l'utilisateur par leur sub source continuent de résoudre après la bascule. Le mot de passe et le profil existants du compte sont préservés ; les rôles source viennent s'ajouter par-dessus. L'aperçu liste chaque compte qui sera réconcilié avant que vous ne validiez.

Exécuter l'importation

Cliquez sur Démarrer l'import après avoir vérifié l'aperçu. La phase de validation écrit les clients, portées, utilisateurs, rôles et références de connexion externe dans les stores de votre locataire. Les lignes en doublon de clientId, scope name, email et role name sont ignorées — l'importateur peut être relancé sans risque.

Ce qui n'est pas importé

• Persisted grants, device codes, sessions côté serveur — courte durée de vie, régénérés automatiquement.
• Clés de signature — Authagonal émet ses propres clés par tenant.
• Colonnes et tables personnalisées — tout ce qui dépasse le schéma standard de Duende remonte en avertissement afin que vous sachiez que ces données sont abandonnées.
• Clients désactivés — importés à l'état désactivé ; réactivez-les depuis la page Clients quand vous êtes prêt.

Importer depuis Auth0

Connectez Authagonal à la Management API de votre locataire Auth0 et transférez vos applications, APIs, rôles, utilisateurs et connexions d’entreprise. Les identifiants d’utilisateur et d’application importés sont conservés, de sorte que les références sub et client_id existantes continuent de se résoudre après la bascule.

Ce dont vous aurez besoin

Créez une application Machine-to-Machine dans Auth0 autorisée pour la Management API, avec ces portées de lecture : read:users, read:clients, read:resource_servers, read:roles, read:connections, read:client_grants. Collez son domaine, son client ID et son client secret dans le formulaire d’import — ils ne servent qu’à l’import.

Ce qui est importé

Mots de passe

La Management API d’Auth0 ne renvoie jamais les empreintes de mot de passe. Si vous disposez de l’export groupé de mots de passe assisté par le support Auth0 (NDJSON), fournissez-le — les empreintes bcrypt sont importées telles quelles et vos utilisateurs conservent leur mot de passe sans réinitialisation. Ce fichier contient aussi l’intégralité de vos utilisateurs, levant la limite de 1 000 utilisateurs du listing de l’API Auth0. Sans lui, les utilisateurs sont importés sous forme de profils et définissent un nouveau mot de passe à la première connexion.

Référence API

Chaque locataire expose un serveur OIDC conforme aux standards à l'adresse https://{slug}.authagonal.io. Tous les points de terminaison suivent les spécifications OAuth 2.0 et OpenID Connect. Cette référence couvre chaque point de terminaison avec lequel votre application peut avoir besoin d'interagir.

Flux Authorization Code avec PKCE

Découverte OIDC & JWKS

Le document de découverte permet aux bibliothèques clientes OIDC de se configurer automatiquement. Aucune authentification n'est requise pour ces points de terminaison.

GET /.well-known/openid-configuration

Renvoie le document de configuration du fournisseur OpenID. La réponse inclut toutes les métadonnées dont votre client a besoin pour interagir avec ce locataire.

GET /.well-known/openid-configuration/jwks

Renvoie le JSON Web Key Set utilise pour vérifier les signatures de jetons. La réponse contient un tableau keys avec des clés publiques RSA, chacune incluant les champs kty, use, kid, alg, n et e.

curl https://acme.authagonal.io/.well-known/openid-configuration

Point de terminaison d'autorisation

GET /connect/authorize

Initie un flux authorization code. L'utilisateur doit avoir une session active ou il sera redirigé vers la page de connexion. En cas de succès, l'utilisateur est redirigé vers votre application avec un code d'autorisation.

Réponse de succès : Redirection 302 vers redirect_uri avec les paramètres de requête code et state.

Réponse d'erreur : Redirection 302 avec les paramètres de requête error, error_description et state.

Pushed Authorization Requests (PAR)

RFC 9126. Au lieu de placer chaque paramètre d'autorisation dans l'URL, votre client les envoie par POST à /connect/par avec une authentification client classique et reçoit en retour une request_uri opaque et de courte durée. Le navigateur visite ensuite /connect/authorize?client_id=...&request_uri=... — rien d'autre n'apparaît dans l'historique du navigateur, les logs du serveur ou les en-têtes Referer, et le serveur a déjà vérifié l'intégrité des paramètres sous authentification du client.

POST /connect/par

L'authentification client est la même que pour /connect/token : HTTP Basic avec client_id/client_secret, ou identifiants encodés dans le formulaire. Les clients publics publient sans secret. Le corps porte les mêmes paramètres que vous enverriez normalement à /connect/authorize ; request_uri lui-même est rejeté (chaîner un PAR est interdit par §2.1 de la spec). Renvoie 201 Created.

Réponse

Sur l'appel suivant GET /connect/authorize?client_id=…&request_uri=…, tous les autres paramètres sont extraits de la charge utile poussée et tout paramètre de requête supplémentaire est ignoré. Le client_id de l'appel d'autorisation doit correspondre au client qui a poussé la requête. Une fois consommée (ou une fois expires_in écoulé), la request_uri est retirée du stockage.

# 1. Push parameters (server returns request_uri + expires_in)
curl -X POST https://acme.authagonal.io/connect/par \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "response_type=code" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "scope=openid profile email" \
  -d "state=$(openssl rand -hex 16)" \
  -d "code_challenge=YOUR_CODE_CHALLENGE" \
  -d "code_challenge_method=S256"

# 2. Send the user to /authorize with only client_id + request_uri
# https://acme.authagonal.io/connect/authorize?client_id=my-app&request_uri=urn:ietf:params:oauth:request_uri:abc123...

Point de terminaison de jeton

POST /connect/token

Échange des identifiants contre des jetons. Les requêtes doivent utiliser Content-Type: application/x-www-form-urlencoded. L'authentification client peut être fournie via HTTP Basic auth (Authorization: Basic base64(client_id:client_secret)) ou comme paramètres dans le corps du formulaire (client_id + client_secret).

Grant Authorization Code

Grant Refresh Token

Grant Client Credentials

Grant Device Code

Réponse de jeton :

curl -X POST https://acme.authagonal.io/connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "client_id=my-app" \
  -d "code_verifier=YOUR_CODE_VERIFIER"

Point de terminaison UserInfo

GET /connect/userinfo

Renvoie les revendications concernant l'utilisateur authentifié. Nécessite un jeton d'accès valide avec la portée openid.

curl https://acme.authagonal.io/connect/userinfo \
  -H "Authorization: Bearer ACCESS_TOKEN"

Introspection de jeton (RFC 7662)

POST /connect/introspect

Valide un jeton et renvoie ses métadonnées. Nécessite des identifiants client (Basic auth ou paramètres dans le corps du formulaire).

Réponse de jeton actif :

Réponse de jeton inactif : { "active": false }

curl -X POST https://acme.authagonal.io/connect/introspect \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "token=ACCESS_OR_REFRESH_TOKEN"

Révocation de jeton (RFC 7009)

POST /connect/revocation

Révoqué un jeton précédemment émis. Nécessite des identifiants client.

Le point de terminaison renvoie toujours 200 OK, même pour les jetons invalides ou déjà révoqués, conformément a la spécification RFC 7009.

Autorisation d'appareil (RFC 8628)

POST /connect/deviceauthorization

Initie le flux d'autorisation d'appareil pour les appareils à saisie limitee (CLI, smart TV, appareils IoT). L'appareil affiche un code à l'utilisateur, qui approuve ensuite la requête sur un appareil séparé disposant d'un navigateur.

Réponse :

Flux d'approbation : L'utilisateur visite la verification_uri, entre le user_code et approuve la requête. Pendant ce temps, l'appareil interroge le point de terminaison de jeton avec le device_code.

Codes d'erreur de polling :

curl -X POST https://acme.authagonal.io/connect/deviceauthorization \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=my-cli" \
  -d "scope=openid profile email"

Fin de session / Déconnexion

GET POST /connect/endsession

Déconnecte la session utilisateur actuelle, declenche la déconnexion back-channel vers tous les clients avec un BackChannelLogoutUri enregistré, et révoqué tous les grants.

Si un post_logout_redirect_uri valide est fourni et correspond a une URI enregistrée, l'utilisateur reçoit une redirection 302. Sinon, une réponse JSON confirme que la session a été terminée.

Référence API SCIM 2.0

Authagonal prend en charge le protocole SCIM 2.0 pour le provisionnement automatisé des utilisateurs et des groupes. Les fournisseurs d'identité tels qu'Okta, Azure AD et OneLogin peuvent utiliser cette API pour maintenir votre locataire Authagonal synchronisé avec votre annuaire d'entreprise.

URL de base : https://{slug}.authagonal.io/scim/v2

Authentification : Toutes les requêtes nécessitent un jeton Bearer. Générez un jeton SCIM dans le portail sous Paramètres > Provisionnement SCIM.

En-têtes communs :

Les points de terminaison de liste prennent en charge la pagination via les paramètres de requête startIndex (base 1) et count (max 200), et le filtrage via le paramètre filter (par ex. userName eq "[email protected]").

Utilisateurs

GET /scim/v2/Users — Lister les utilisateurs avec pagination et filtrage optionnels.

GET /scim/v2/Users/{id} — Obtenir un utilisateur unique par son identifiant utilisateur Authagonal.

POST /scim/v2/Users — Créer un nouvel utilisateur. Renvoie 201 Created.

PUT /scim/v2/Users/{id} — Remplacement complet d'une ressource utilisateur. Tous les champs doivent être fournis.

PATCH /scim/v2/Users/{id} — Mise à jour partielle utilisant SCIM PatchOp.

DELETE /scim/v2/Users/{id} — Supprime l'utilisateur de manière logique (désactivé le compte et révoqué tous les jetons). Renvoie 204 No Content.

curl -X POST https://acme.authagonal.io/scim/v2/Users \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "[email protected]",
    "name": {
      "givenName": "Jane",
      "familyName": "Smith"
    },
    "displayName": "Jane Smith",
    "active": true,
    "externalId": "ext-12345"
  }'

Groupes

GET /scim/v2/Groups — Lister tous les groupes avec pagination et filtrage optionnels.

GET /scim/v2/Groups/{id} — Obtenir un groupe unique par ID, y compris sa liste de membres.

POST /scim/v2/Groups — Créer un nouveau groupe. Renvoie 201 Created.

PUT /scim/v2/Groups/{id} — Remplacement complet d'une ressource de groupe (y compris sa liste de membres).

PATCH /scim/v2/Groups/{id} — Mise à jour partielle pour ajouter ou supprimer des membres du groupe.

DELETE /scim/v2/Groups/{id} — Supprime définitivement le groupe. Renvoie 204 No Content.

curl -X PATCH https://acme.authagonal.io/scim/v2/Groups/GROUP_ID \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
      {
        "op": "add",
        "path": "members",
        "value": [
          { "value": "USER_ID_1" },
          { "value": "USER_ID_2" }
        ]
      }
    ]
  }'

API du portail (automatisation)

L'API du portail permet à votre propre backend d'automatiser tout ce que vous pouvez faire dans le portail — gérer les utilisateurs, les clients, les groupes, les rôles, les portées, les connexions SSO et les paramètres — à l'aide d'un identifiant machine à machine. Il s'agit de la même API que celle appelée par l'interface du portail.

URL de base : https://portal-api.<your-domain>/api/v1. Les requêtes s'authentifient avec un jeton d'accès Bearer ; le locataire est déterminé à partir du jeton, et non de l'URL.

Créer un identifiant d'API

Dans le portail, ouvrez Clients → Create API credential, choisissez un niveau d'accès et donnez-lui un nom. Authagonal génère un client OAuth client_credentials configuré pour l'API du portail et renvoie un ID client et un secret.

Niveaux d'accès

Obtenir un jeton

Échangez l'identifiant contre un jeton d'accès au point de terminaison de jeton de votre tenant administratif — https://<your-tenant>.<your-domain>/connect/token — puis envoyez le jeton dans un en-tête Bearer à l'API du portail. Les jetons sont valides pendant une heure.

# 1. Exchange the credential for an access token (your tenant's token endpoint)
curl -X POST https://acme.authagonal.io/connect/token \
  -d grant_type=client_credentials \
  -d client_id=api-3f2a... \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d scope=tenant:admin

# Response: { "access_token": "ey...", "token_type": "Bearer", "expires_in": 3600 }

# 2. Call the Portal API with the access token
curl https://portal-api.authagonal.io/api/v1/users \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Points de terminaison

Tous les chemins sont relatifs à l'URL de base et nécessitent un jeton d'accès Bearer. La portée indiquée à côté de chaque groupe correspond au niveau d'accès minimal requis pour les identifiants. Les endpoints de liste acceptent les paramètres de requête startIndex et count.

GET/api/v1/clients— Lister les clients OAuth.

GET/api/v1/clients/{id}— Récupérer un client par son ID.

POST/api/v1/clients— Créer un client. Renvoie l'ID du client et, pour les clients confidentiels, un secret à usage unique.

PUT/api/v1/clients/{id}— Mettre à jour un client (URI de redirection, types d'autorisation, durées de vie des jetons, exigences PKCE/PAR).

DELETE/api/v1/clients/{id}— Supprimer un client.

POST/api/v1/clients/api-credential— Générer un identifiant d'API Portal machine-to-machine.

GET/api/v1/users— Lister les utilisateurs. Prend en charge startIndex, count et search (préfixe e-mail / nom).

GET/api/v1/users/count— Nombre total d'utilisateurs du locataire.

GET/api/v1/users/stats/mfa— Statistiques d'inscription à la MFA.

GET/api/v1/users/{id}— Récupérer un utilisateur.

POST/api/v1/users— Créer un utilisateur avec un e-mail et un mot de passe.

PUT/api/v1/users/{id}— Mettre à jour un utilisateur (profil, e-mail, état activé/bloqué).

DELETE/api/v1/users/{id}— Supprimer un utilisateur.

GET/api/v1/users/{id}/mfa— Get a user's enrolled MFA methods.

DELETE/api/v1/users/{id}/mfa— Reset a user's MFA enrollment.

GET/api/v1/roles— Lister les rôles.

POST/api/v1/roles— Créer un rôle.

DELETE/api/v1/roles/{id}— Supprimer un rôle.

POST/api/v1/roles/assign— Attribuer un rôle à un utilisateur.

POST/api/v1/roles/unassign— Retirer un rôle à un utilisateur.

GET/api/v1/groups— Lister les groupes.

GET/api/v1/groups/{id}— Récupérer un groupe et ses membres.

POST/api/v1/groups— Créer un groupe.

POST/api/v1/groups/{id}/members— Ajouter des membres à un groupe.

DELETE/api/v1/groups/{groupId}/members/{userId}— Retirer un membre d'un groupe.

DELETE/api/v1/groups/{id}— Supprimer un groupe.

GET/api/v1/group-role-mappings— Lister les correspondances groupe-rôle (rôles accordés à l'émission du jeton selon l'appartenance au groupe).

GET/api/v1/scopes— Lister les portées d'API.

POST/api/v1/scopes— Créer une portée.

DELETE/api/v1/scopes/{name}— Supprimer une portée.

GET/api/v1/saml/connections— Lister les connexions SAML.

POST/api/v1/saml/connections— Créer une connexion SAML.

DELETE/api/v1/saml/connections/{id}— Supprimer une connexion SAML.

GET/api/v1/oidc/connections— Lister les connexions OIDC.

POST/api/v1/oidc/connections— Créer une connexion OIDC.

DELETE/api/v1/oidc/connections/{id}— Supprimer une connexion OIDC.

GET/api/v1/sso/domains— Lister les domaines routés vers les connexions SSO (découverte du domaine d'origine).

GET/api/v1/branding— Récupérer la personnalisation du locataire (couleurs, logo, langues prises en charge).

PUT/api/v1/branding— Mettre à jour la personnalisation du locataire.

GET/api/v1/settings— Récupérer les paramètres du locataire (webhooks, inscription publique, politique de jetons).

PUT/api/v1/settings— Mettre à jour les paramètres du locataire.

POST/api/v1/settings/webhook-secret/regenerate— Faire pivoter le secret de signature des webhooks.

POST/api/v1/settings/test-email— Envoyer un e-mail de test avec la configuration e-mail actuelle.

GET/api/v1/custom-domains— Lister les domaines de connexion personnalisés et leur statut de vérification.

POST/api/v1/custom-domains— Ajouter un domaine personnalisé.

POST/api/v1/custom-domains/{domain}/verify— Déclencher la vérification DNS d'un domaine personnalisé.

DELETE/api/v1/custom-domains/{domain}— Supprimer un domaine personnalisé.

GET/api/v1/email/domains— Lister les domaines e-mail d'expéditeur.

GET/api/v1/audit— Interroger le journal d'audit du locataire.

Exemple : créer un utilisateur

curl -X POST https://portal-api.authagonal.io/api/v1/users \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "password": "S3cure-temp-passw0rd",
    "firstName": "Ada",
    "lastName": "Lovelace"
  }'

# 200 OK
# { "userId": "8f3a...", "email": "[email protected]" }

Écrans de connexion

Voici les écrans hébergés que vos utilisateurs finaux voient sur le serveur d'authentification de votre tenant. Authagonal livre chaque écran prêt à l'emploi, vous obtenez donc une expérience de connexion complète et sécurisée sans construire la moindre interface. Cette page passe en revue chaque écran et montre quels paramètres du portail le contrôlent.

Connexion

• Flux en deux étapes, e-mail d'abord : l'utilisateur saisit son e-mail et clique sur Continuer, puis le champ du mot de passe apparaît.
• Les boutons d'authentification unique « Continuer avec {provider} » apparaissent automatiquement lorsque des connexions SSO existent.
• Les liens Mot de passe oublié et Créer un compte, chacun pouvant être affiché ou masqué.
• Captcha Cloudflare Turnstile optionnel pour dissuader les tentatives de connexion automatisées.

Contrôlé depuis l'administration du portail

• La Personnalisation de marque définit le logo, la couleur, le nom de l'application, l'e-mail de support et le CSS personnalisé.
• Affichez ou masquez les liens mot de passe oublié et inscription (Personnalisation de marque).
• Les connexions SSO ajoutent les boutons de connexion sociale (page SSO).
• Durée de vie des sessions et seuils de verrouillage (Paramètres → Sécurité).

Inscription

• Collecte le prénom et le nom (optionnels), l'e-mail et un mot de passe.
• Une liste de contrôle de la politique de mot de passe en direct se met à jour à mesure que l'utilisateur saisit, pour que les exigences soient claires avant validation.
• Captcha Cloudflare Turnstile optionnel.
• Un lien « Se connecter » pour les utilisateurs qui ont déjà un compte.

Contrôlé depuis l'administration du portail

• Affichez ou masquez le lien inscription (Personnalisation de marque).
• La politique de mot de passe de votre tenant pilote la liste de contrôle.
• La Personnalisation de marque stylise tout l'écran.

Mot de passe oublié

• L'utilisateur saisit son e-mail, puis voit une confirmation neutre « vérifiez votre e-mail ».
• L'écran ne révèle jamais si un compte existe, ce qui déjoue le sondage par énumération de comptes.
• Un lien « Retour à la connexion » ramène l'utilisateur à l'écran de connexion.

Contrôlé depuis l'administration du portail

• Affichez ou masquez le lien mot de passe oublié (Personnalisation de marque).
• La distribution d'e-mails de votre tenant envoie le message de réinitialisation.
• La Personnalisation de marque stylise tout l'écran.

Réinitialiser le mot de passe

• Champs nouveau mot de passe et confirmer le mot de passe avec une liste de contrôle des exigences en direct, règle par règle.
• Un état clair lien invalide ou expiré lorsque le jeton de réinitialisation n'est plus valide.
• Un état de succès confirmant que le mot de passe a été changé.

Contrôlé depuis l'administration du portail

• La politique de mot de passe de votre tenant pilote la liste de contrôle.
• La Personnalisation de marque stylise tout l'écran.

Défi MFA

• Un sélecteur de méthode entre application d'authentification, passkey et code de récupération.
• Un champ TOTP à 6 chiffres qui se valide automatiquement une fois tous les chiffres saisis.
• La saisie d'un code de récupération pour les utilisateurs qui ont perdu l'accès à leur application d'authentification.
• Un bouton passkey pour une vérification matérielle.

Contrôlé depuis l'administration du portail

• La politique MFA se définit par application (Clients → Sécurité).
• Tout utilisateur disposant d'un facteur enregistré est toujours soumis au défi, quelle que soit la politique.

Configuration MFA

• Affiche le statut des méthodes enregistrées pour que l'utilisateur sache ce qui est déjà configuré.
• Configuration de l'application d'authentification via QR code, avec une clé manuelle de secours et une étape de confirmation.
• Enregistrement d'un passkey pour une authentification matérielle.
• Génération de codes de récupération pour la récupération de compte.
• Une option ignorer facultative lorsque la MFA est en libre-service plutôt qu'obligatoire.

Contrôlé depuis l'administration du portail

• La politique MFA se définit par application ; Obligatoire force la configuration à la connexion (Clients → Sécurité).
• La Personnalisation de marque stylise tout l'écran.

Autorisation d'appareil

• Un champ de saisie du code utilisateur centré pour le code affiché sur l'appareil.
• Une étape d'approbation pour autoriser l'appareil.
• Un écran intermédiaire de connexion lorsque l'utilisateur n'est pas encore authentifié.
• Une confirmation d'approbation une fois l'appareil autorisé.

Contrôlé depuis l'administration du portail

• Activez le grant de code d'appareil sur l'application (Clients → Types de grants).
• Définissez la durée de vie du code d'appareil (Clients → Jetons).

Consentement

• Affiche le logo et le nom du client demandeur.
• Une liste par scope avec des libellés clairs et lisibles pour chaque permission.
• Des boutons Autoriser et Refuser pour accorder ou refuser l'accès.
• Un pied de page d'indication de consentement expliquant ce que la décision implique.

Contrôlé depuis l'administration du portail

• Activez Exiger le consentement par application (Clients → Sécurité).
• Le logo, le nom et l'URL proviennent des propres métadonnées de l'application.
• La Personnalisation de marque habille la carte de consentement.

Applications connectées (grants)

• Liste toutes les applications que l'utilisateur a autorisées, avec leur nom, leurs portées et la date d'autorisation.
• Révoquez l'accès à une application, avec une étape de confirmation avant que cela prenne effet.
• Un état vide convivial lorsque l'utilisateur n'a autorisé aucune application.

Contrôlé depuis l'administration du portail

• La liste est alimentée par les applications nécessitant un consentement.
• La Personnalisation de marque stylise tout l'écran.

Compte

Une page de compte en libre-service hébergée sur /login/account où les utilisateurs connectés gèrent leur propre profil et leur langue préférée, sans accès au portail.

• Modifier les prénom et nom, l'entreprise et le téléphone ; l'adresse e-mail est affichée en lecture seule.
• Choisir une langue préférée parmi les langues prises en charge ; l'interface prévisualise le choix instantanément et le conserve à l'enregistrement.
• La langue enregistrée pilote l'interface hébergée de l'utilisateur et la langue des e-mails transactionnels qu'il reçoit.

Contrôlé depuis l'administration du portail

• Branding habille tout l'écran.
• La même langue préférée est modifiable par un administrateur depuis la page Utilisateurs du portail.

Flux d'authentification

Les flux d'authentification couvrent la manière dont les utilisateurs finaux interagissent avec votre locataire Authagonal — connexion, inscription, réinitialisation de mot de passe et configuration de la MFA. Ces points de terminaison sont utilisés par la page de connexion hébergée et peuvent être appelés directement si vous construisez une interface de connexion personnalisée.

Connexion

POST /api/auth/login

Authentifié un utilisateur avec un e-mail et un mot de passe. En cas de succès, signe un cookie de session et renvoie le profil utilisateur. Si la MFA est configurée, la réponse indique qu'un second facteur est requis avant que la session ne soit complètement établie.

Corps de la requête :

{
  "email": "[email protected]",
  "password": "correct-horse-battery-staple"
}

Réponse de succès :

Réponse MFA requise : Lorsque l'utilisateur a la MFA inscrite, la réponse inclut mfaRequired: true ainsi qu'un challengeId et un tableau methods listant les méthodes MFA disponibles.

Réponse de configuration MFA requise : Lorsque le locataire exige la MFA mais que l'utilisateur ne s'est pas encore inscrit, la réponse inclut mfaSetupRequired: true avec un setupToken pour le flux d'inscription.

Réponses d'erreur :

Vérification SSO : Si le domaine d'e-mail de l'utilisateur a une connexion SSO configurée, le point de terminaison de connexion renvoie sso_required avec une redirectUrl. Le client doit rediriger l'utilisateur vers le fournisseur SSO.

Verrouillage de compte : Après maxFailedAttempts tentatives de connexion échouées consécutives, le compte est verrouillé pendant lockoutDurationMinutes. Les deux valeurs sont configurables dans les paramètres du locataire.

Inscription

POST /api/auth/register

Crée un nouveau compte utilisateur. Un e-mail de vérification est envoyé automatiquement — l'utilisateur doit vérifier son e-mail avant de pouvoir se connecter.

Corps de la requête :

{
  "email": "[email protected]",
  "password": "a-strong-password-here",
  "firstName": "Jane",
  "lastName": "Smith"
}

Succès : 201 Created avec le userId du nouveau compte. S'inscrire avec un e-mail déjà utilise renvoie aussi 201 : nous ne révélons jamais si un e-mail existe (pour empêcher l'énumération de comptes) et prévenons plutôt le véritable titulaire du compte par e-mail.

Réponses d'erreur :

Réinitialisation du mot de passe

POST /api/auth/forgot-password

Demande un e-mail de réinitialisation de mot de passe. Le point de terminaison renvoie toujours une réponse de succès, que l'e-mail existe ou non, pour empêcher l'énumération des e-mails.

{
  "email": "[email protected]"
}

POST /api/auth/reset-password

Réinitialise le mot de passe de l'utilisateur en utilisant le jeton provenant du lien dans l'e-mail.

{
  "token": "RESET_TOKEN_FROM_EMAIL",
  "newPassword": "new-strong-password"
}

Effets secondaires d'une réinitialisation de mot de passe réussie :

• Le compteur de tentatives de connexion échouées est remis à zéro
• Tous les jetons de rafraîchissement existants sont révoqués
• Un nouveau tampon de sécurité est généré (invalidant toutes les sessions existantes)

Configuration et vérification MFA

Authagonal prend en charge trois méthodes MFA : TOTP (applications d'authentification), WebAuthn (clés de sécurité et biométrie) et codes de récupération à usage unique.

Configuration TOTP

POST /api/auth/mfa/totp/setup — Renvoie un URI de données de QR code et une clé de saisie manuelle. L'utilisateur scanne le QR code avec son application d'authentification (Google Authenticator, Authy, 1Password, etc.), puis confirme l'inscription.

POST /api/auth/mfa/totp/confirm — Confirme l'inscription TOTP en validant un code à 6 chiffres provenant de l'application d'authentification.

{
  "code": "123456"
}

Configuration WebAuthn

POST /api/auth/mfa/webauthn/setup — Renvoie les options de création d'identifiants pour l'API WebAuthn. Le navigateur appelle navigator.credentials.create() avec ces options.

POST /api/auth/mfa/webauthn/confirm — Confirme l'inscription WebAuthn en soumettant la réponse d'attestation du navigateur.

Codes de récupération

POST /api/auth/mfa/recovery/generate — Génère 10 codes de récupération à usage unique de 8 caractères. Chaque code peut être utilise exactement une fois pour contourner la MFA.

Vérification MFA

POST /api/auth/mfa/verify — Complète le défi MFA après une connexion par mot de passe réussie.

Statut MFA

GET /api/auth/mfa/status — Renvoie les méthodes MFA actuellement inscrites de l'utilisateur.

Flux de connexion SSO

Authagonal prend en charge les connexions SSO basées sur SAML 2.0 et OIDC. Le routage par domaine detecte automatiquement quel fournisseur SSO utiliser en fonction de l'adresse e-mail de l'utilisateur.

Vérification SSO

GET /api/auth/[email protected]

Flux SAML

L'utilisateur est redirigé vers GET /saml/{connectionId}/login qui envoie une SAML AuthnRequest au fournisseur d'identité. L'IdP authentifié l'utilisateur et renvoie une réponse SAML au point de terminaison Assertion Consumer Service (ACS). Authagonal valide l'assertion, crée ou met à jour l'utilisateur et signe un cookie de session.

Les métadonnées SAML pour configurer votre IdP sont disponibles à GET /saml/{connectionId}/metadata.

Flux OIDC

L'utilisateur est redirigé vers GET /oidc/{connectionId}/login qui redirige vers le fournisseur d'identité en amont avec PKCE. Après l'authentification de l'utilisateur, le callback a /oidc/callback échange le code d'autorisation, valide le jeton ID et crée ou met à jour l'utilisateur.

Provisionnement JIT : Les flux SAML et OIDC prennent en charge le provisionnement just-in-time. Si l'utilisateur n'existe pas encore dans le locataire, il est créé automatiquement à partir des revendications du fournisseur d'identité. S'il existe déjà, ses attributs de profil sont mis à jour pour correspondre aux dernières valeurs du fournisseur.

Créer une interface de connexion personnalisée

Remplacez les écrans de connexion, d'inscription, de réinitialisation de mot de passe et de MFA hébergés par Authagonal par votre propre interface, pendant qu'Authagonal continue de gérer l'authentification, la MFA, le SSO, les sessions et l'émission de jetons. Deux approches : utiliser notre bibliothèque de composants React, ou appeler directement l'API d'authentification depuis n'importe quel framework. C'est une option à activer — activez d'abord Custom login UI dans les paramètres du locataire.

Prérequis : un domaine personnalisé sur votre racine

La session de connexion est un cookie first-party, votre interface et le serveur d'authentification Authagonal doivent donc partager un domaine enregistrable. Pointez un domaine d'authentification personnalisé vers Authagonal sur la même racine que celle de votre application — par ex. l'authentification sur login.acme.com, l'application sur app.acme.com. Le paramètre Custom login UI reste désactivé tant qu'aucun domaine personnalisé actif n'existe.

Ajoutez également l'origine de votre interface (par ex. https://app.acme.com) aux Allowed CORS origins de votre client OAuth — la même liste que celle définie pour l'échange de jetons.

React : @authagonal/login

npm i @authagonal/login fournit la logique d'authentification et l'interface dans un seul paquet — le même que celui sur lequel repose la connexion hébergée par Authagonal. Choisissez votre niveau :

• Application complète — intégrez App et personnalisez-la via le branding.
• Composer des pages — utilisez LoginPage, MfaChallengePage, ResetPasswordPage… dans votre propre mise en page.
• Primitives + logique — créez vos propres écrans avec AuthLayout/Button/Input et le client API (login, mfaVerify, forgotPassword, …).

import { AuthLayout, Input, Button, login, ApiRequestError } from '@authagonal/login';

function MyLogin() {
  async function onSubmit(email: string, password: string) {
    try {
      const res = await login({ email, password });        // POST /login (sets the session cookie)
      if (res.mfaRequired) {/* render your MFA step → mfaVerify(...) */}
      else window.location.href = res.returnUrl;            // hand off to /connect/authorize
    } catch (e) {
      if (e instanceof ApiRequestError) {/* show e.message */}
    }
  }
  return <AuthLayout>{/* your own markup + <Input/> <Button/> */}</AuthLayout>;
}

N'importe quel framework : appeler l'API d'authentification

Pas sur React ? Appelez directement les points de terminaison du flux d'authentification (sous /api/auth), puis basculez vers le flux OIDC standard /connect/authorize. Envoyez credentials: 'include' pour que le cookie de session soit stocké.

# 1. Authenticate (browser fetch — credentials:'include' so the session cookie is stored)
curl -i -X POST https://login.acme.com/api/auth/login \
  -H "Content-Type: application/json" \
  -H "Origin: https://app.acme.com" \
  --data '{"email":"[email protected]","password":"..."}'
# (handle {"mfaRequired":true} → POST /api/auth/mfa/verify, then continue)

# 2. Hand off to the OAuth flow — top-level navigation to the authorize endpoint with PKCE:
# https://login.acme.com/connect/authorize?client_id=my-app&redirect_uri=...&response_type=code
#   &scope=openid%20profile%20email&code_challenge=...&code_challenge_method=S256
# The session cookie (same-site) authenticates the user; you get back a code → exchange at /connect/token.

Plans et limites

Authagonal propose quatre niveaux de plan. Tous les plans incluent toutes les fonctionnalités — la seule différence est la limite d'utilisateurs actifs mensuels (MAU) et la tarification des dépassements.

Niveaux de plan

Utilisateurs actifs mensuels (MAU)

Un utilisateur actif mensuel est tout utilisateur unique qui s'authentifié avec succès au moins une fois pendant un mois de facturation. Les utilisateurs provisionnés via SCIM mais qui ne se sont pas connectés ne comptent pas dans votre total MAU.

Dépassement — Si votre plan prend en charge le dépassement, les utilisateurs au-delà de la limite MAU sont facturés au tarif par utilisateur indiqué dans le tableau des plans ci-dessus. Vous pouvez définir un plafond de dépassement pour limiter votre depense maximale pour la période de facturation.

Application — Si votre plan ne prend pas en charge le dépassement (Starter), les utilisateurs au-delà de la limite MAU ne peuvent pas se connecter jusqu'à la prochaine période de facturation ou jusqu'à ce que vous passiez à un plan qui prend en charge le dépassement.