Plateforme · Identité et accès
Un compte, toutes les applications.
Le Hub tient les comptes, les rôles et les droits pour l’ensemble de vos programmes. On se connecte une fois, on retrouve ses applications, et on retire un accès en un geste.
Ce que ça vous évite
Une page de connexion par programme
Aucune application n’en code : la connexion est celle du Hub, la même partout.
Des mots de passe éparpillés
Un compte par personne, pas un par outil. Au départ d’un collaborateur, on ferme un compte, pas dix.
Des clés d’API dans un tableur
Chaque clé est émise, rattachée à une organisation, limitée à ce qu’elle doit faire, et révocable tout de suite.
Ce que fait le Hub
Comptes, rôles, portées
Les utilisateurs, leurs rôles et les portées que donne chaque rôle (app:carousel,
api:kew:read…). L’accès à une application est une portée comme une autre.
Plusieurs organisations sur un Hub
Chaque organisation (tenant) a ses utilisateurs et ses accès. Une personne peut appartenir à plusieurs, et choisir la sienne à la connexion. Une organisation se suspend et se réactive.
Connexion unique
Le Hub pose une session valable pour toutes les applications du domaine. Chaque route choisit son niveau : ouverte, connexion facultative, connexion obligatoire.
Fournisseur OpenID Connect
Le Hub est lui-même fournisseur d’identité OIDC. Un outil tiers qui sait parler OIDC se branche dessus sans compte supplémentaire.
Clés d’API
Émises par un administrateur ou par l’utilisateur lui-même, stockées sous forme d’empreinte, jamais en clair. Une clé porte une organisation et des portées.
Une page de connexion par marque
Quand le Hub sert plusieurs marques, chacune a sa propre page de connexion, à ses couleurs et sur son propre domaine.
Sous le capot
| Worker | iam_worker — une quarantaine d’actions MCP |
| Actions | create_user, assign_role, assign_scope_to_role, create_tenant, grant_app_access, grant_tenant_access, create_api_key, create_my_api_key, revoke_api_key, suspend_tenant, tenant_consistency_audit, list_oidc_clients, get_my_identity |
| Jetons | JWT RS256, clés publiées en JWKS ; mots de passe en BCrypt ; clés d’API en SHA-256 |
| OIDC | code d’autorisation avec PKCE S256 ; un émetteur (issuer) par domaine de marque |
| En-têtes | le proxy transmet X-SSO-User (identifiant numérique), X-SSO-Email, X-SSO-Scopes, X-SSO-Tenant, et retire tout en-tête x-sso-* venu de l’extérieur. L’application ne voit jamais le jeton. |
| Console | /hub/iam, /hub/iam/tenants |
L’application reçoit donc une identité déjà vérifiée. Elle n’a qu’une chose à tenir : ses propres rôles métier (qui administre, qui consulte), dans sa propre table.
État
Opérationnel sur le Hub thesocle.net (version 3.51.1, relevé du 2026-09-23).
Limite actuelle : le Hub dit qui est connecté et à quelles applications il a droit. Il ne transmet pas de rôle métier. Les rôles propres à une application (administrateur, lecteur…) sont tenus par l’application elle-même ; c’est ce que nous livrons dans chaque programme.