Hébergeur Cloud depuis 2024

Retour aux articles
Infra 12 min de lecture

Authentik : centraliser l'authentification SSO de votre PME

VaultAura Team

9 mars 2026

Authentik : centraliser l'authentification SSO de votre PME

Déployez Authentik en self-hosted pour unifier vos connexions SSO, gérer les identités et sécuriser vos apps internes.

Authentik : reprendre le contrôle sur l'authentification de votre PME

Gérer les accès dans une PME qui grandit, c'est souvent le début d'un cauchemar silencieux. Un compte Azure AD par-ci, un login Nextcloud par-là, des credentials GitLab que personne ne sait plus qui a créés, et au final des utilisateurs qui réutilisent le même mot de passe partout parce que c'est "plus simple". On connaît tous cette situation. Et franchement, c'est un risque énorme.

C'est là qu'Authentik entre en jeu. Un outil open source, auto-hébergeable, qui permet de centraliser toute l'authentification de votre infrastructure via SSO — Single Sign-On — et de reprendre la main sur qui accède à quoi. Pas de licence à payer, pas de dépendance à un éditeur américain, et une flexibilité que les solutions SaaS ne peuvent pas vraiment offrir.

Voilà ce qu'on va explorer ensemble dans cet article.


Pourquoi la gestion des identités est un angle mort dans les PME

Le vrai problème : la dispersion des comptes

Dans la majorité des PME qu'on accompagne à Lyon, on retrouve le même schéma. Cinq ou dix applications métier, chacune avec sa propre base d'utilisateurs. L'employé qui part ? Il faut penser à le désactiver sur la messagerie, sur le VPN, sur l'outil de ticketing, sur le wiki interne, sur le cloud de fichiers... Et bien sûr, on en oublie toujours un.

Ce n'est pas de la négligence. C'est simplement que sans une solution centralisée, le processus de départ (ou d'arrivée) d'un collaborateur devient une opération manuelle à haut risque d'erreur.

Un truc souvent oublié : les anciens comptes actifs sont l'une des premières portes d'entrée utilisées lors d'une intrusion. Un ex-salarié dont le compte Nextcloud est toujours actif six mois après son départ, c'est un vecteur d'attaque concret.

SSO : c'est pas que du confort utilisateur

On pense souvent au SSO comme un outil de confort — un seul login pour tout, la belle vie. Mais c'est surtout un outil de sécurité. En centralisant l'authentification, vous pouvez appliquer des politiques cohérentes : MFA obligatoire, sessions avec timeout, restrictions par IP ou par appareil.

D'ailleurs, si vous n'avez pas encore mis en place le MFA dans votre organisation, je vous invite vraiment à lire notre article sur l'authentification multifacteur — c'est complémentaire à ce qu'on fait avec Authentik, et franchement indispensable.


Ce qu'Authentik propose concrètement

Un Identity Provider complet

Authentik joue le rôle d'Identity Provider (IdP). En clair, c'est lui qui valide votre identité, et les applications lui font confiance pour ça. Dès que vous vous connectez à une application compatible, celle-ci redirige vers Authentik qui vérifie qui vous êtes, puis vous renvoie vers l'appli avec un jeton d'autorisation.

Il supporte les protocoles standard du marché :

  • SAML 2.0 — pour les applications plus classiques ou entreprise
  • OAuth2 / OpenID Connect (OIDC) — pour les applis modernes
  • LDAP — pour les applis legacy qui ne parlent que ce langage
  • RADIUS — utile pour certains équipements réseau ou VPNs

Du coup, vous pouvez connecter à peu près n'importe quoi. Nextcloud, GitLab, Grafana, Proxmox, Portainer, des applis web custom... La compatibilité est large.

Les flows : la vraie puissance d'Authentik

Ce qui distingue vraiment Authentik des alternatives, c'est son système de flows. Un flow, c'est un parcours d'authentification que vous définissez vous-même. Vous voulez que certains utilisateurs passent par une vérification MFA par TOTP, d'autres par WebAuthn, et que les admins aient un flow encore différent avec confirmation par email ? C'est possible.

En prod on a eu le cas où un client voulait que les connexions depuis l'extérieur du réseau local déclenchent systématiquement un challenge MFA, mais pas depuis le réseau interne. Avec les policies Authentik basées sur la géolocalisation du réseau, c'est configurable en quelques minutes.

Outpost et proxy provider

Un des cas d'usage les plus pratiques : le proxy provider. Authentik peut protéger des applications qui ne supportent pas nativement OAuth ou SAML. Via un outpost (un composant proxy déployé sur votre infra), Authentik intercepte les requêtes et exige une authentification avant de laisser passer.

C'est exactement le même principe qu'un reverse proxy avec une couche d'auth. Si vous connaissez déjà les proxys et reverse proxys, vous voyez tout de suite l'intérêt.


Déployer Authentik : le côté pratique

Architecture recommandée

Authentik tourne en container. L'installation officielle s'appuie sur Docker Compose, ce qui le rend accessible même sans cluster Kubernetes. En production, vous aurez besoin de :

  • Un container authentik-server (le cœur de l'application)
  • Un container authentik-worker (pour les tâches asynchrones)
  • Une base de données PostgreSQL
  • Redis (pour le cache et les sessions)
# Extrait docker-compose.yml — configuration de base Authentik
version: "3.4"

services:
  postgresql:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: authentik
      POSTGRES_USER: authentik
      POSTGRES_PASSWORD: ${PG_PASS}  # Défini dans le fichier .env
    volumes:
      - database:/var/lib/postgresql/data

  redis:
    image: redis:alpine
    restart: unless-stopped
    command: --save 60 1 --loglevel warning
    volumes:
      - redis:/data

  server:
    image: ghcr.io/goauthentik/server:latest
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}  # Clé générée aléatoirement
    ports:
      - "9000:9000"   # HTTP
      - "9443:9443"   # HTTPS
    depends_on:
      - postgresql
      - redis

  worker:
    image: ghcr.io/goauthentik/server:latest
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
    depends_on:
      - postgresql
      - redis

volumes:
  database:
  redis:

La configuration initiale

Au premier démarrage, Authentik crée un compte admin par défaut accessible via /if/flow/initial-setup/. Vous définissez le mot de passe admin, et ensuite tout se passe depuis l'interface web — propre, claire, bien organisée.

Première chose à faire : créer votre annuaire d'utilisateurs. Authentik peut soit gérer ses propres utilisateurs en interne, soit se synchroniser avec un Active Directory ou un LDAP existant. C'est une question que les gens se posent souvent : est-ce qu'Authentik remplace l'AD ? Non, il le complète. Il peut s'y connecter, importer les utilisateurs, et déléguer l'authentification finale à votre AD tout en ajoutant des fonctionnalités par-dessus (MFA, flows personnalisés, etc.).

Si vous avez déjà déployé un Active Directory dans votre PME, l'intégration avec Authentik est vraiment fluide — c'est un combo puissant.

Connecter une première application : exemple avec Nextcloud

Voici le principe pour connecter Nextcloud via OIDC :

Côté Authentik :

  1. Créer un Provider de type "OAuth2/OpenID Provider"
  2. Définir le redirect URI : https://nextcloud.mondomaine.fr/apps/oidc_login/oidc
  3. Récupérer le Client ID et le Client Secret générés
  4. Créer une Application qui pointe vers ce provider

Côté Nextcloud :

// Dans config/config.php de Nextcloud
'oidc_login_provider_url' => 'https://authentik.mondomaine.fr/application/o/nextcloud/',
'oidc_login_client_id' => 'VOTRE_CLIENT_ID',
'oidc_login_client_secret' => 'VOTRE_CLIENT_SECRET',
'oidc_login_auto_redirect' => false,  // Mettre true pour forcer le SSO
'oidc_login_end_session_redirect' => true,
'oidc_login_attributes' => [
    'id' => 'preferred_username',  // Attribut utilisé comme identifiant
    'mail' => 'email',
    'name' => 'name',
],

En pratique, ça prend vingt minutes sur une installation propre. Et une fois fait, vos utilisateurs n'ont plus qu'un seul endroit où s'authentifier.


Les fonctionnalités qui font vraiment la différence

Blueprints : versionner sa configuration

Authentik supporte les blueprints — des fichiers YAML qui décrivent votre configuration (flows, providers, applications). C'est une feature souvent sous-estimée, mais elle est fondamentale pour une vraie gestion sérieuse.

Vous pouvez versionner vos blueprints dans Git, les rejouer sur une nouvelle instance, et avoir une configuration reproductible. C'est exactement l'approche Infrastructure-as-Code appliquée à votre couche d'authentification.

# Exemple de blueprint minimal pour créer un groupe
version: 1
metadata:
  name: Groupes de base PME
entries:
  - model: authentik_core.group
    state: present
    identifiers:
      name: Collaborateurs
    attrs:
      name: Collaborateurs
      
  - model: authentik_core.group
    state: present
    identifiers:
      name: Admins IT
    attrs:
      name: Admins IT

Policies et règles d'accès granulaires

Au-delà du SSO basique, Authentik permet de définir des règles d'accès très fines. Vous pouvez conditionner l'accès à une application à l'appartenance à un groupe, à un attribut utilisateur, à l'adresse IP source, ou à la réussite d'un challenge MFA spécifique.

Par exemple : seuls les membres du groupe "Admins IT" peuvent accéder à Proxmox, et uniquement depuis le réseau local ou via VPN. Les autres reçoivent une page d'erreur claire. C'est simple à configurer, et ça évite d'avoir à gérer des règles de pare-feu pour chaque application.

WebAuthn et passkeys

Authentik supporte WebAuthn nativement, ce qui ouvre la porte aux passkeys et aux clés de sécurité physiques (YubiKey, etc.). Pour les accès les plus sensibles — Proxmox, votre firewall, votre serveur de sauvegardes — c'est le niveau de sécurité qu'on recommande systématiquement.

Franchement, quand vous pouvez proposer à vos admins de se connecter avec une clé physique plutôt qu'un mot de passe, c'est une évolution que personne ne regrette.

Notifications et alertes

Authentik peut envoyer des alertes en cas d'événements suspects : tentatives de connexion échouées répétées, connexion depuis un nouveau pays, compte verrouillé. Les notifications partent par email ou via webhook — ce qui permet de les intégrer dans Slack, Teams, ou votre outil de monitoring.


Authentik vs les alternatives

Comparaison rapide

CritèreAuthentikKeycloakOktaAzure AD
Open source✅ Oui✅ Oui❌ SaaS❌ SaaS
Auto-hébergeable✅ Oui✅ Oui❌ Non❌ Non
Interface moderne⚠️ Complexe
Courbe d'apprentissageModéréeÉlevéeFaibleFaible
CoûtGratuitGratuit💰💰💰
Proxy provider❌ Natif

Keycloak : l'alternative la plus comparable

Keycloak est la référence dans le monde open source. Il est plus mature, plus documenté, et utilisé dans des contextes enterprise très larges. Mais sa complexité est réelle. La configuration est moins intuitive, l'interface plus austère, et la courbe d'apprentissage significativement plus raide.

Pour une PME qui veut un résultat concret rapidement, Authentik est généralement plus adapté. Pour une grande organisation avec des équipes dédiées et des besoins très spécifiques de customisation, Keycloak peut être pertinent.

Pourquoi pas Okta ou Azure AD External Identities ?

Les solutions SaaS ont l'avantage de la simplicité de démarrage. Mais elles ont deux limites majeures pour les PME qui y sont sensibles : le coût (qui monte vite avec le nombre d'utilisateurs) et la souveraineté des données. Vos données d'authentification, vos logs de connexion, vos configurations de sécurité... tout ça réside chez un éditeur américain soumis au Cloud Act.

Si la souveraineté numérique vous préoccupe — et elle devrait — un hébergement on-premise ou chez un hébergeur cloud souverain français avec Authentik est une alternative sérieuse.


Ce qu'on voit trop souvent en déploiement

Les erreurs classiques

Ne pas activer le MFA dès le départ. Déployer Authentik sans MFA, c'est centraliser l'authentification sans vraiment la renforcer. Si quelqu'un compromet le mot de passe d'un utilisateur, il a accès à toutes les applications connectées d'un coup. Le MFA casse ce scénario.

Mal gérer les sessions. Par défaut, les sessions Authentik sont longues. En prod, on a eu le cas où un collaborateur avait une session active depuis trois semaines sur une machine partagée — pas idéal. Pensez à configurer des timeouts adaptés à vos usages.

Oublier les applications legacy. Le LDAP provider d'Authentik est là pour ça. Ne laissez pas vos vieilles applications hors du périmètre SSO sous prétexte qu'elles ne parlent pas OIDC.

Ne pas tester le flow de récupération d'accès. Que se passe-t-il si Authentik est indisponible ? Avez-vous un moyen de vous connecter en direct à vos applications ? Ayez toujours un plan B pour les applications critiques, et testez-le régulièrement.

Sécuriser Authentik lui-même

Authentik est la clé de votre royaume — il faut donc le traiter comme tel. Quelques règles de base :

  • Exposez-le uniquement en HTTPS, avec un certificat valide
  • Mettez en place un WAF ou des règles de rate-limiting en amont
  • Activez le MFA sur le compte admin (évidemment)
  • Sauvegardez régulièrement la base PostgreSQL — c'est critique
  • Suivez les releases : Authentik corrige régulièrement des vulnérabilités

Sur ce dernier point, si vous avez une stratégie de patch management en place, intégrez Authentik dans vos cycles de mise à jour. C'est une application exposée sur internet, ça compte.


Cas d'usage concret : une PME de 40 personnes

Pour rendre ça plus tangible : imaginez une PME de 40 collaborateurs, avec Nextcloud pour les fichiers, GitLab pour les projets techniques, Grafana pour le monitoring, et un wiki Confluence hébergé on-prem.

Avant Authentik : 40 × 4 comptes = 160 couples login/mot de passe à gérer. Chaque départ de salarié nécessite 4 désactivations manuelles (quand on pense à les faire toutes).

Après Authentik : un seul annuaire, un seul login. Le départ d'un collaborateur prend trente secondes — désactivation du compte Authentik, et c'est réglé pour toutes les applications d'un coup. Les accès sont tracés centralement. Le MFA s'applique partout avec une seule configuration.

Du coup, le ROI n'est pas juste technique — c'est aussi du temps gagné pour l'équipe IT, et une réduction réelle du risque lié aux comptes orphelins.


Pour aller plus loin

Authentik est un beau projet, activement maintenu, avec une communauté qui grandit vite. La documentation officielle (goauthentik.io) est bien faite, le Discord communautaire est réactif, et les releases sont régulières.

Si vous cherchez à aller plus loin sur la sécurisation de votre infrastructure globale, notre article sur le Zero Trust donne un cadre utile pour comprendre comment l'identité s'inscrit dans une stratégie de sécurité plus large. Authentik est souvent une brique fondamentale de ce type d'architecture.


Vous voulez centraliser l'authentification de votre PME à Lyon ?

Déployer Authentik correctement, c'est une chose. Le configurer de façon sécurisée, l'intégrer à votre AD existant, et l'adapter à vos applications métier, c'en est une autre. On accompagne les PME lyonnaises sur ce type de déploiement — de l'audit de l'existant jusqu'à la mise en production.

Parlons de votre projet

Partager cet article :
VaultAura - Solutions Informatiques Professionnelles | Infogérance, Cloud, Sécurité