Concepts Clés

Cette page définit les concepts fondamentaux d’Auris. Chaque terme est expliqué dans le contexte de la façon dont Auris l’utilise. Si tu es nouveau dans la gestion des identités et des accès, lire cette page avant les guides rendra le reste de la documentation plus facile à suivre.

Tenant

Un environnement isolé dans Auris. Chaque configuration, utilisateur, application, rôle et politique appartient à un tenant. Les tenants ne peuvent pas partager de données — un compte utilisateur dans le tenant A ne peut pas s’authentifier sur une application enregistrée dans le tenant B.

En interne, chaque tenant correspond à un realm Keycloak. Keycloak applique l’isolation du realm au niveau du référentiel d’identité.

Dans les requêtes API, le tenant actif est identifié par l’en-tête x-tenant. Les SDK le définissent automatiquement en fonction du domain configuré à l’initialisation.

Les déploiements single-tenant utilisent un seul tenant (généralement appelé 'default'). Les produits SaaS multi-tenant créent un tenant pour chaque organisation cliente — c’est différent du concept d’Organization d’Auris, qui est un regroupement B2B au sein d’un seul tenant Auris.

Application

Un client enregistré avec Auris. Tout logiciel utilisant l’authentification Auris doit être enregistré comme application. Une application a :

• Un Client ID unique (identifiant public, sûr à intégrer dans le code du navigateur)
• Un Client Secret optionnel (privé, uniquement pour les clients M2M côté serveur)
• Une liste d’URI de Redirection autorisés (appliqués exactement — pas de wildcards)
• Un Type d’Application qui détermine les flux OAuth 2.0 disponibles

Types d’application :

Utilisateur

Une identité gérée par Auris au sein d’un tenant. Les utilisateurs ont :

• Un ID unique (claim sub dans les JWT)
• Une adresse e-mail (identifiant principal)
• Nom d’utilisateur, prénom, nom et numéro de téléphone optionnels
• Un ou plusieurs rôles (via des attributions de rôle)
• Des overrides de permissions optionnels (ALLOW ou DENY sur des permissions spécifiques, indépendamment des rôles)
• Une ou plusieurs méthodes d’authentification (mot de passe, compte social, passkey, etc.)
• Des configurations 2FA optionnelles (TOTP, SMS, WebAuthn)

Rôle

Une collection nommée de permissions. Les utilisateurs sont attribués aux rôles ; les rôles définissent ce que ces utilisateurs sont autorisés à faire. Les rôles sont scopés à un tenant.

Un utilisateur peut avoir plusieurs rôles. Lors de la vérification d’une permission, tous les rôles sont évalués — si un rôle accorde ALLOW et qu’aucun n’accorde DENY, la permission est accordée.

Permission

Une capacité représentée sous forme de chaîne action:ressource. Exemples :

• manage:users — accès CRUD complet aux utilisateurs
• view:invoices — accès en lecture aux factures
• approve:expenses — possibilité d’approuver les notes de frais

Les permissions ont des valeurs tri-state :

DENY gagne toujours sur ALLOW.

Access Token

Un JWT (JSON Web Token) de courte durée qui prouve l’identité de l’utilisateur et porte ses permissions. Les access tokens sont :

• Signés avec RS256 (RSA + SHA-256) en utilisant la clé privée d’Auris
• Vérifiés par tout service ayant accès à l’endpoint JWKS public d’Auris
• Envoyés dans l’en-tête HTTP Authorization: Bearer <token> aux API protégées
• De courte durée (défaut : 15 minutes — configurable par tenant)

Refresh Token

Un token opaque de longue durée utilisé pour obtenir de nouveaux access tokens après l’expiration du token actuel. Les refresh tokens sont :

• Opaques — ce sont des chaînes aléatoires, pas des JWT.
• Longévifs (défaut : 7 jours — configurable par tenant)
• À utilisation unique — chaque fois qu’un refresh token est utilisé, Auris invalide l’ancien et en émet un nouveau (rotation du refresh token)

ID Token

Un token OpenID Connect (OIDC) contenant les informations du profil de l’utilisateur authentifié. Les ID tokens sont :

• Des JWT, signés avec RS256 comme les access tokens
• Destinés à l’application cliente pour afficher les informations utilisateur
• Non envoyés aux API — les API doivent utiliser l’access token

PKCE

Proof Key for Code Exchange (RFC 7636). Une extension de sécurité au flux Authorization Code d’OAuth 2.0 qui prévient les attaques d’interception du code d’autorisation.

Auris applique S256 (hachage SHA-256) — le PKCE plain n’est pas accepté. Tous les SDK Auris gèrent la génération et la vérification PKCE automatiquement.

RBAC

Role-Based Access Control. Le modèle de permissions dans lequel :

• Les utilisateurs sont attribués à des rôles
• Les rôles ont des permissions
• Les permissions contrôlent l’accès aux actions et ressources

Dans Auris, RBAC est implémenté comme Niveau 2 du modèle d’autorisation à trois niveaux.

FGA

Fine-Grained Authorization. Un système de contrôle d’accès basé sur les relations en style Zanzibar pour les permissions au niveau de l’objet. FGA répond à la question : « Cet utilisateur spécifique peut-il accéder à cet objet spécifique ? »

FGA utilise trois concepts fondamentaux :

• Modèle d’Autorisation — un schéma qui définit les types d’objets et les relations
• Tuples de Relation — des faits stockés dans la base de données
• Vérification — une requête récursive qui détermine si un sujet a une relation avec un objet

SSO

Single Sign-On. Un mécanisme qui permet aux utilisateurs de s’authentifier une fois avec un fournisseur d’identité (IdP) et d’obtenir automatiquement l’accès à plusieurs applications.

Auris supporte deux protocoles SSO :

• SAML 2.0 — protocole basé sur XML largement utilisé par les IdP enterprise (Okta, Azure AD, ADFS)
• OIDC (OpenID Connect) — protocole moderne basé sur JSON

SCIM

System for Cross-domain Identity Management (RFC 7643/7644). Un protocole standard pour le provisionnement et le déprovisionnement automatisés des utilisateurs.

Avec SCIM activé :

• Quand les RH créent un nouvel employé dans Okta ou Azure AD, cet utilisateur est automatiquement provisionné dans Auris
• Quand un employé est licencié, son compte Auris est automatiquement déprovisionné

M2M

Machine-to-Machine. Authentification serveur à serveur dans laquelle aucun utilisateur humain n’est impliqué. Utilise le grant Client Credentials d’OAuth 2.0.

MFA

Multi-Factor Authentication. Demander aux utilisateurs de prouver leur identité avec plus d’un facteur. Auris supporte trois méthodes MFA :

Actions

Des fonctions JavaScript personnalisées qui s’exécutent pendant les flux d’authentification dans un environnement sandbox. Les Actions te permettent d’étendre le comportement d’Auris.

Organisation

Une entité B2B au sein d’un tenant. Les organisations sont utilisées quand tu construis un produit que tu vends à d’autres entreprises — chaque client est modélisé comme une Organisation.

Domaine Personnalisé

Une fonctionnalité qui te permet de servir les pages de login hébergées d’Auris depuis ton domaine (ex. auth.votre-entreprise.com).

Webhook

Un callback HTTP qu’Auris envoie à ton serveur quand des événements spécifiques se produisent. Les webhooks sont signés avec HMAC-SHA256.

OIDC Discovery

Le mécanisme standard par lequel les clients OIDC découvrent la configuration d’un fournisseur d’identité. Auris publie son document OIDC Discovery sur :

GET /.well-known/openid-configuration