L'identité de tous vos collaborateurs, sur des standards ouverts.

Obexal est une plateforme souveraine européenne qui authentifie vos collaborateurs, connecte chaque application et gouverne les accès, depuis un seul annuaire et un jeu de protocoles ouverts.

L'essentiel

Cette page rassemble en un seul endroit l'identité des collaborateurs de votre organisation : les personnes de votre effectif et la manière dont elles atteignent les outils dont elles ont besoin. Tout ce qui suit s'appuie sur le même annuaire, le même journal d'audit et le même hébergement souverain : une seule source de vérité à raisonner, plutôt qu'une mosaïque de consoles.

Un identifiant pour chaque application

Obexal est un fournisseur d'identité complet pour les standards que vos applications parlent déjà : OpenID Connect, OAuth 2.1 et SAML 2.0. Vos collaborateurs se connectent une fois et atteignent chaque app connectée, sans verrou propriétaire et sans passerelle qui détourne votre trafic hors de l'Union européenne. La découverte est publiée sur /.well-known/openid-configuration et les clés de signature sur /.well-known/jwks.json : les applications s'intègrent contre des documents plutôt que par configuration manuelle.

Les clients publics utilisent le code d'autorisation avec PKCE, les clients machine utilisent client credentials, et les Pushed Authorization Requests (PAR) déplacent les paramètres d'autorisation vers un canal arrière durci. Les applications échangent le code contre des jetons sur /oauth/token et valident un jeton en direct sur /oauth/introspect. SAML 2.0 fonctionne dans les deux sens : Obexal est un fournisseur d'identité SAML multi-tenant pour vos apps historiques, et un fournisseur de service SAML quand un IdP amont connecte vos équipes. Au-delà d'un catalogue de connecteurs prêts à l'emploi, vous déclarez vos propres applications OIDC et SAML, limitées à votre tenant. Le parcours d'intégration complet est dans la documentation.

Une MFA anti-hameçonnage, jamais de SMS

Une connexion plus sûre ne doit pas rimer avec friction permanente. Obexal propose trois facteurs :

• Passkeys : bâties sur WebAuthn, y compris la connexion sans identifiant (usernameless).
• TOTP : des codes à usage unique basés sur le temps, depuis n'importe quelle app d'authentification standard.
• Code e-mail : des codes à usage unique envoyés par e-mail, en repli.

Jamais de SMS : le message texte est un canal faible et interceptable, et l'écarter est un choix souverain assumé.

Les passkeys sont anti-hameçonnage par conception : l'identifiant est une clé privée qui ne quitte jamais l'appareil et reste liée cryptographiquement à votre domaine, donc un site sosie n'obtient rien. Le MFA s'impose strictement par tenant et par groupe, et le renforcement (step-up) ne réclame un facteur supplémentaire que lorsqu'une action sensible ou un changement de contexte l'exige. Les sessions de confiance restent fluides, les actions sensibles restent protégées, et chaque enrôlement, défi et renforcement s'inscrit au journal d'audit.

Un annuaire, une seule source de vérité

Un seul annuaire fait foi pour vos collaborateurs. Chaque profil porte un prénom et un nom, un nom d'affichage, un poste, un département et une langue préférée, définis par un administrateur ou provisionnés automatiquement, et lus par le portail employé comme par vos applications. Les utilisateurs sont organisés en groupes qui modélisent vos équipes, fonctions ou projets, avec une appartenance directe : la question « qui est dans quoi » reste lisible d'un seul regard.

Personne ne s'inscrit sans y être invité. L'inscription libre est coupée par défaut : un administrateur invite une personne avec un profil pré-rempli, et l'invitation vaut activation. Au premier login, la personne définit un mot de passe ou une passkey et arrive dans les bons groupes dès le premier jour. La fédération des identités apporte la connexion Google, Microsoft ou OIDC générique par tenant, et le LDAP ou Active Directory entrant en fail-closed : si la source ne répond pas, l'accès est refusé plutôt qu'accordé en silence. L'appartenance aux groupes voyage ensuite vers vos applications sous forme de claim groups dans les jetons qu'elles reçoivent.

Des comptes qui suivent l'organigramme

Les comptes suivent l'organigramme automatiquement. En entrant, Obexal est un serveur SCIM 2.0 sur /scim/v2/Users : votre SIRH ou votre IdP amont crée, met à jour et désactive les comptes sans intégration sur mesure. Le périmètre entrant est la ressource Users ; les groupes se gèrent dans l'annuaire Obexal lui-même. En sortant, Obexal est un client SCIM vers toute application qui expose un endpoint SCIM 2.0, et lui pousse les évènements de création, de mise à jour et de désactivation vers chaque cible déclarée.

L'enjeu tient autant au dernier jour qu'au premier : suspendez un compte une fois, et Obexal le déprovisionne en aval via les cibles SCIM, automatiquement. Si une poussée échoue, l'échec est enregistré au journal d'audit plutôt qu'avalé en silence, et vous pouvez lancer une synchronisation à la demande pour réconcilier une cible. Chaque évènement de provisioning, succès comme échec, est auditable et peut être envoyé vers votre SIEM.

Un accès qui suit l'appartenance aux groupes

Assignez un ou plusieurs groupes à une application et elle devient réservée à leurs membres : un utilisateur ne l'atteint que par son appartenance. Une application sans groupe assigné reste ouverte à toute l'organisation : la restriction est toujours un choix explicite, lisible dans la console. Attachez des groupes à une application et le droit prend effet immédiatement pour chaque membre ; quittez le groupe et l'accès disparaît. Vos applications n'ont pas à appeler Obexal pour connaître les droits d'un utilisateur : elles les lisent dans le claim groups du jeton.

L'administration reste séparée par conception. Des rôles RBAC personnalisés, bâtis sur un catalogue de permissions explicite avec une garde anti-escalade, gouvernent qui peut faire quoi dans la console Obexal. Ces rôles ne fuient jamais dans les jetons applicatifs : ils pilotent la console, pas vos apps. Seul le claim groups voyage vers vos applications, ce qui garde l'autorisation simple à raisonner et simple à auditer.

Des règles simulées avant d'être appliquées

Les règles d'accès sont un code versionné sur trois dimensions explicites, plus le risque adaptatif :

• Réseau : autoriser ou refuser par blocs CIDR et plages IP.
• Horaire : restreindre l'accès par jour et par heure.
• Pays : décider contre une base GeoIP résolue 100 % en local ; aucun service externe n'est appelé et aucune adresse IP ne quitte la plateforme.

Le risque adaptatif ajoute six signaux déterministes et explicables (nouvelle IP, nouvel appareil, heure inhabituelle, changement d'IP rapide, rafale d'échecs, voyage impossible) ; quand le risque monte, la politique renforce vers MFA plutôt que de bloquer sèchement.

Parce qu'un changement d'accès ne devrait jamais être une surprise, toute version candidate de politique se rejoue en simulation contrefactuelle sur des connexions réelles avant sa mise en production : vous lisez exactement qui serait autorisé, renforcé ou refusé. Appliquez-la quand l'impact correspond à votre intention, et si une version se révèle mauvaise, restaurez la précédente en une seule étape. À noter : l'appareil n'est pas une dimension de politique sur laquelle on écrit des règles, un nouvel appareil est simplement l'un des six signaux de risque.

Souverain, et vérifiable

Obexal est hébergé en France, dans un datacenter en région parisienne, avec résidence des données dans l'UE. Aucune dépendance hors UE ne se trouve dans le chemin des requêtes, il n'y a aucun CDN externe, et les polices sont auto-hébergées. Le trafic passe en TLS 1.2 au minimum, 1.3 privilégié, avec HSTS. Les mots de passe sont hachés en Argon2id sous une politique alignée NIST 800-63B et ANSSI, et les mots de passe compromis sont refusés via une blocklist vérifiée entièrement en local. Les secrets applicatifs, du secret client OAuth aux clés de signature SAML et aux jetons SCIM, sont chiffrés AES-256-GCM au repos. Sur les certifications, nous disons le statut réel : non certifié à ce jour, avec une correspondance ISO 27001:2022 documentée et une feuille de route SecNumCloud engagée.

L'identité des collaborateurs n'est qu'une moitié de la plateforme. Pour la connexion des clients finaux, voir le CIAM ; pour l'identité des agents IA et des services, voir l'identité des agents IA ; et si vous quittez un autre IdP, le guide de migration couvre la coexistence progressive plutôt qu'une bascule brutale. La posture de sécurité complète est sur la page sécurité.

Questions fréquentes

Continuer : CIAM, l'identité de vos clients · Agents IA · Migrer depuis un autre IdP