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).
• appRights : liste de droits applicatifs de type resource.action accumulés depuis les profils. Détail de la forme réelle (profile.rights, objets {code, name, description, category}) dans le modèle de contrôle d'accès.
• features : activation vérifiée en cascade App ∧ Network ∧ Customer via l'endpoint dédié (voir modèle de contrôle d'accès) — pas un champ précalculé de /me.
• 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",

  "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"
  ],

  "lastLoginAt": "2026-05-19T10:30:00.000Z",
  "createdAt": "2026-01-15T08:00:00.000Z"
}

---

Description de chaque champ

Identité

Niveaux d'accès

Le champ userLevel n'est plus retourné par /me — il a été retiré du payload (MeResponseDto ne le porte plus). Il n'est plus utilisé pour contrôler la création d'invitations (voir API Invitations — Création) ; les droits d'accès reposent exclusivement sur adminLevel et appRights (profils).

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 HDS

Le champ wakaRoles (rôles métier transversaux CONFIG/EXPLOIT/DPO/AUDIT/BILLING/CYBER) a été décommissionné côté plateforme — ne vous basez pas sur lui, même s'il apparaît encore dans du code ou de la documentation plus ancienne.

É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 : ce n'est PAS un champ précalculé de /me — vérifiez l'activation en cascade (App ∧ Network ∧ Customer) via GET /api/config/app-features/check/{customerWid}/{featureCode}. Exemple de codes de feature : 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 : hdsRoles, les droits d'équipe (wgrl) et les profils. Le concept wakaRoles lui-même a été décommissionné (ni dans le JWT, ni dans /me). 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 droits d'équipe et aux profils vit exclusivement dans /me ; l'activation des features se vérifie via un endpoint dédié (voir ci-dessus) : appelez /me 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