Contexte utilisateur — Structure du payload /me

/me est votre source de vérité côté frontend pour tout ce qui concerne l'identité et les droits de l'utilisateur courant. Appelez-le une fois après le login, stockez le résultat dans un context React.

Pourquoi cette étape

Le JWT Keycloak contient l'identité minimale (sub, email, niveaux admin). Mais pour construire une UI conditionnelle (masquer/afficher des boutons selon les droits, afficher le bon nom d'organisation, etc.), vous avez besoin du payload complet que seule l'API /me retourne.

/me agrège les données de plusieurs sources (Keycloak claims, DB config, profils, équipes) en un seul appel.

Concepts clés

• adminLevel : niveau hiérarchique admin de l'utilisateur (WakaAdmin → None).
• wakaRoles : rôles métier transversaux (CONFIG, EXPLOIT, DPO, AUDIT, BILLING, CYBER).
• appRights : liste de droits applicatifs de type resource.action accumulés depuis les profils.
• features : features activées en cascade App ∧ Network ∧ Customer.
• profiles : profils Wakastart assignés à l'utilisateur (détermine les appRights).
• teams : équipes dont l'utilisateur est membre, avec son level et ses droits dans chaque équipe.

---

Appel

httpCopier
GET /api/me
Authorization: Bearer <keycloak_access_token>
x-enriched-token: <wakastart_token>

Les deux headers sont requis. La réponse est la même que l'utilisateur appelle avec un Bearer JWT ou une API key.

---

Réponse complète

jsonCopier
{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "wid": "WKST05",
  "email": "john@acme.com",
  "firstName": "John",
  "lastName": "Doe",
  "keycloakId": "kc-550e8400-e29b-41d4-a716-446655440000",
  "isActive": true,

  "adminLevel": "CustomerAdmin",
  "userLevel": "ADMIN",

  "wakaRoles": ["CONFIG", "EXPLOIT"],
  "hdsRoles": [],

  "customer": {
    "id": "uuid",
    "wid": "ACM001",
    "name": "Acme Corp",
    "subdomain": "acme"
  },
  "partner": {
    "id": "uuid",
    "wid": "PTR001",
    "name": "Wakastellar"
  },
  "network": {
    "id": "uuid",
    "wid": "NET001",
    "name": "Production"
  },

  "teams": [
    {
      "id": "uuid",
      "wid": "TEAM01",
      "name": "DevOps",
      "teamLevel": "ADMIN",
      "appRights": "rw"
    }
  ],

  "profiles": [
    {
      "id": "uuid",
      "wid": "PRF001",
      "name": "Administrateur"
    }
  ],

  "appRights": [
    "partners.read",
    "users.read",
    "users.write",
    "users.create",
    "users.update",
    "users.delete",
    "apps.read",
    "apps.create",
    "teams.read",
    "teams.members.add",
    "infra.read",
    "infra.deploy",
    "audit.read",
    "profiles.assign",
    "api-keys.read",
    "api-keys.create",
    "api-keys.revoke"
  ],

  "features": ["invitations", "antivirus"],
  "lastLoginAt": "2026-05-19T10:30:00.000Z",
  "createdAt": "2026-01-15T08:00:00.000Z"
}

---

Description de chaque champ

Identité

Niveaux d'accès

Hiérarchie adminLevel :

textCopier
WakaAdmin     → Accès total plateforme (super-admin Wakastellar)
OwnerAdmin    → Accès total plateforme (propriétaire partner)
AppsAdmin     → Applications, profils, droits
NetworkAdmin  → Réseaux, customers, apps
CustomerAdmin → Customers, utilisateurs, équipes
User          → Accès basique (propre profil)
None          → Aucun accès admin

Hiérarchique : un NetworkAdmin possède aussi les droits de CustomerAdmin et User.

Contexte multi-tenant

Rôles métier

Équipes

appRights dans le contexte équipe est un champ libre encodé sur la team (distinct des appRights globaux de l'utilisateur).

Profils et droits applicatifs

• profiles : profils assignés. Un profil = un ensemble de AppRight côté DB.
• appRights : tableau dédupliqué et fusionné de tous les droits provenant de tous les profils. Format : {resource}.{action}.
• features : features activées en cascade (App ∧ Network ∧ Customer). Exemple : invitations, antivirus, hds.

---

Ce qui est dans /me vs dans le JWT

[!WARNING] Le JWT enrichi (wakaToken) est signé et doit tenir sous la limite de 4 Ko d'un cookie. Plusieurs claims autrefois présents en ont été retirés et ne sont plus disponibles que via /me : wakaRoles, hdsRoles, les droits d'équipe (wgrl), les features (wftr) et les profils. Si votre code lit encore ces informations directement depuis le JWT décodé plutôt que via /me, il lit des valeurs obsolètes ou absentes.

Le JWT contient l'identité, les niveaux d'accès et le contexte multi-tenant — de quoi router et faire un premier contrôle grossier. Tout ce qui touche aux rôles métier, droits d'équipe, profils et features vit exclusivement dans /me : appelez-le systématiquement avant de construire une UI conditionnelle ou un guard basé sur ces champs.

---

Aller plus loin

• Cache et invalidation /me : quand appeler /me, mise en cache, invalidation
• Contrôle d'accès : comment utiliser appRights dans vos guards
• Utilisation de l'API : comment passer les tokens dans vos requêtes