Sécurité & RBAC

Aurabase utilise le Row-Level Security (RLS) natif de PostgreSQL. Cela signifie que vos règles d'accès sont écrites en SQL, stockées dans la base, appliquées à chaque requête — y compris celles faites par le SDK, PostgREST, ou psql direct.

Sur un projet MongoDB, il n'y a pas de RLS. L'isolation y est assurée par un champ réservé _owner_id : toute lecture d'un rôle non privilégié est filtrée sur le sub du JWT, et toute écriture estampille ce champ. Trois conséquences à connaître avant de déboguer une liste vide : un document créé avec une clé service_role n'a aucun _owner_id et devient donc invisible à tous les utilisateurs authentifiés (réponse [] en HTTP 200, sans erreur) ; un appelant anon sans JWT reçoit un 403 sur une collection non publique ; et _owner_id, réservé, n'est jamais modifiable par le client. Une collection s'ouvre en lecture à tous par l'opt-in explicite public_read.

Contourner une policy est impossible côté client. Le gateway valide chaque JWT avant d'ouvrir une connexion Postgres avec le rôle approprié. Les claims (auth.uid(), auth.role(), auth.tenant()) sont injectés via request.jwt.claims — non modifiables depuis une requête SQL.

Chaque requête suit le même chemin. Le gateway décode le JWT, vérifie sa signature (JWKS tournant RS256), extrait les claims, ouvre une connexion Postgres avec SET LOCAL role + SET LOCAL request.jwt.claims. Toutes les policies qui référencent auth.*() utilisent ces claims.

Client  →  Gateway     verify JWT (JWKS RS256)
           ↓           extract { sub, role, tenant, exp }
        Postgres      SET LOCAL role = authenticated
                      SET LOCAL request.jwt.claims = {...}
           ↓
        SELECT ... FROM posts WHERE ...
           ↓ (RLS injecte la policy USING)
        SELECT ... FROM posts WHERE author_id = auth.uid()

Les policies sont attachées à une table + une opération (SELECT/INSERT/UPDATE/DELETE) + un rôle. Plusieurs policies sur la même paire sont combinées en OR. Utilisez using pour filtrer les lignes existantes, with check pour valider les nouvelles valeurs.

alter table posts enable row level security;
-- Lecture : auteur uniquement
create policy "posts_own_read"
  on posts for select
  to authenticated
  using (auth.uid() = author_id);

Les rôles applicatifs (admin, editor, viewer, billing…) sont définis dans project_{uuid}_auth.roles. Chaque utilisateur peut avoir N rôles. L'auth-server injecte roles dans le JWT, et auth.has_role('admin') devient utilisable dans vos policies.

-- Admin voit tout
create policy "posts_admin_read"
  on posts for select
  to authenticated
  using (auth.has_role('admin'));
-- Billing voit les colonnes sensibles en vue dédiée
create view posts_billing as
  select id, author_id, revenue_cents from posts
  where auth.has_role('billing');

Chaque événement sécurité est logué dans project_{uuid}_auth.auth_audit_log : signin, signout, password_change, mfa_enroll, role_granted, service_role_access, failed_auth. Rétention 30 jours sur Pro, 2 ans sur Enterprise.