Authentik : un IdP moderne pour remplacer Okta ou Keycloak

Keycloak reste la référence open source pour le SSO d'entreprise, mais sa configuration peut décourager : interface Java old-school, themes Freemarker, modèle realm/client parfois rigide. Quand on cherche un IdP self-hosted qui modernise l'expérience administrateur tout en restant ouvert et complet, Authentik s'impose comme l'alternative la plus crédible.

Cet article présente Authentik (architecture, protocoles supportés, déploiement type), le compare à Keycloak sur les points qui comptent en pratique, et détaille deux scénarios concrets : SSO d'applications internes via OIDC et fédération LDAP pour de la migration progressive.

• Qu'est-ce qu'Authentik
• Protocoles supportés
• Architecture et déploiement
• Comparaison Authentik vs Keycloak
• Scénario : SSO OIDC pour applications internes
• Scénario : LDAP outpost pour applications legacy
• Limites et points d'attention

Authentik est un fournisseur d'identité (IdP) open source développé par goauthentik.io. La dernière version stable au moment de la rédaction est la 2026.2.2, publiée le 7 avril 2026. Le code cœur est distribué sous licence MIT ; une édition Enterprise propriétaire propose des fonctionnalités avancées (authentification mobile push, audit avancé, support commercial).

Le projet vise à remplacer les IdP commerciaux (Okta, Auth0, Microsoft Entra ID, Ping Identity) par une solution self-hosted. La promesse : un IdP unifié qui couvre l'authentification, l'autorisation, l'application des politiques (MFA, conditional access) et la fédération avec des annuaires existants, le tout pilotable via une API REST complète et une interface moderne.

Trois éléments le distinguent :

1. Un seul produit pour quatre protocoles : SAML, OAuth2/OIDC, LDAP (en sortie), RADIUS. Pas besoin d'empiler plusieurs services pour couvrir des applications hétérogènes.
2. Le concept de "flow" : chaque parcours utilisateur (authentification, enrôlement, récupération, invitation) est un flow composé de stages enchaînés. Permet de construire des parcours métier précis sans coder.
3. Une UI moderne : React/TypeScript côté front, branding configurable, expérience admin et utilisateur cohérente.

Authentik joue le rôle d'IdP fournisseur pour les applications consommatrices, et de client pour les annuaires sources. Concrètement :

Les outposts sont des composants déployables séparément qui exposent les protocoles non-HTTP (LDAP, RADIUS) ou qui agissent comme reverse proxy d'authentification (forward auth) pour des applications sans support natif OIDC/SAML.

Le stack technique d'Authentik :

• Backend : Python/Django, communication interne via Celery + Redis.
• Frontend : TypeScript/Lit/React.
• Base de données : PostgreSQL.
• Cache et files : Redis.
• Reverse proxy embarqué : Go (pour les outposts proxy).

Le déploiement de référence est un docker-compose ou un chart Helm. Voici le squelette docker-compose minimal :

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik
    volumes:
      - ./db:/var/lib/postgresql/data

  redis:
    image: docker.io/library/redis:alpine
    restart: unless-stopped
    command: --save 60 1 --loglevel warning

  server:
    image: ghcr.io/goauthentik/server:2026.2.2
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    ports:
      - '9000:9000'
      - '9443:9443'
    depends_on:
      - postgresql
      - redis

  worker:
    image: ghcr.io/goauthentik/server:2026.2.2
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - postgresql
      - redis

Le port 9000 expose l'interface admin et utilisateur en HTTP, 9443 en HTTPS direct (ou derrière un reverse proxy Nginx).

À la première connexion, on crée le compte administrateur initial via l'URL /if/flow/initial-setup/.

Les deux projets couvrent un périmètre comparable. Voici les différences concrètes qui pèsent dans la décision.

Pour une organisation déjà investie dans Keycloak, la migration vers Authentik n'a pas un ROI évident. Pour un nouveau déploiement, Authentik offre une expérience plus moderne et une empreinte plus légère, au prix d'une communauté un peu plus jeune. Le choix se joue souvent sur la familiarité de l'équipe et la richesse de l'écosystème de connecteurs.

Cas d'usage type : une organisation qui déploie Grafana, Gitea, Nextcloud, et veut un SSO unique pour ses utilisateurs.

Configuration côté Authentik (via l'interface admin) :

1. Créer un Provider OAuth2/OIDC par application :

   • Client type : Confidential
   • Redirect URIs : URL de callback de l'application (par exemple https://grafana.example.com/login/generic_oauth)
   • Signing Key : clé RSA générée par Authentik
   • Scopes : openid profile email groups

2. Créer une Application liée au provider :

   • Slug : grafana
   • Provider : celui créé à l'étape 1
   • Policies : optionnel, restrictions d'accès (groupe, condition, geofencing)

3. Récupérer les credentials : Client ID, Client Secret, et URLs OIDC (issuer, authorize, token, userinfo) depuis la fiche provider.

Côté Grafana (grafana.ini) :

[auth.generic_oauth]
enabled = true
name = Authentik
allow_sign_up = true
client_id = <client-id from authentik>
client_secret = <client-secret from authentik>
scopes = openid profile email groups
auth_url = https://auth.example.com/application/o/authorize/
token_url = https://auth.example.com/application/o/token/
api_url = https://auth.example.com/application/o/userinfo/
role_attribute_path = contains(groups[*], 'grafana-admin') && 'Admin' || 'Viewer'

L'utilisateur se connecte sur Grafana, est redirigé vers Authentik, s'authentifie une seule fois. Les autres applications (Gitea, Nextcloud) reconnaissent immédiatement la session via le cookie Authentik.

Toutes les applications n'ont pas de support OIDC/SAML. Pour une application legacy qui ne sait parler qu'à un annuaire LDAP, Authentik expose un outpost LDAP : un service qui se présente comme un serveur LDAP standard et délègue l'authentification au flow Authentik configuré.

Étapes :

1. Créer un Provider LDAP : définir le base DN (dc=example,dc=com), les bind credentials, et le flow de recherche (par défaut default-search-flow).
2. Créer un Application liée au provider.
3. Créer un Outpost de type LDAP : Authentik génère un token et déploie un container ghcr.io/goauthentik/ldap qui se connecte à l'instance principale via l'API.
4. Configurer l'application legacy pour qu'elle pointe vers l'IP/port de l'outpost LDAP (typiquement 389/tcp ou 636/tcp avec TLS).

L'application legacy effectue son BIND standard sur Authentik comme s'il s'agissait d'un serveur OpenLDAP. Authentik valide les credentials selon le flow configuré (mot de passe + MFA si défini), puis retourne un succès ou un échec. Aucune modification de l'application n'est nécessaire.

Ce pattern est particulièrement utile pour migrer progressivement depuis un OpenLDAP existant sans casser les applications qui en dépendent.

Pas de Kerberos en fournisseur. Les environnements Active Directory qui exigent du Kerberos pour l'authentification poste de travail ne peuvent pas remplacer leur DC par Authentik. La fédération AD reste possible côté source.

Édition Enterprise pour certaines fonctionnalités avancées. Push notifications mobiles, audit centralisé, support commercial sont sous Enterprise. Pour la majorité des usages SSO classiques, l'édition open source suffit.

Stack Python. Pour une équipe orientée JVM ou Go, le runtime Python peut être un changement à intégrer. Les opérations courantes (mises à jour, sauvegarde Postgres, scaling worker) restent simples mais nécessitent une familiarité avec l'écosystème.

Modélisation flow puissante mais demandant un apprentissage. Le concept de stages et de policies est très expressif, mais nécessite une lecture initiale de la documentation pour ne pas reproduire des anti-patterns hérités de Keycloak.

• Keycloak SSO et OAuth2
• LDAP, SSSD et sudo : intégration entreprise
• OpenLDAP en serveur d'annuaire
• Architecture zero trust
• Bastion SSH avec MFA

• Authentik (dépôt GitHub) code, releases, version 2026.2.2
• Site officiel goauthentik.io, documentation
• Documentation Providers, OIDC, SAML, LDAP, RADIUS
• Documentation Outposts, déploiement et architecture
• Comparaison Authentik vs alternatives, billets officiels

Authentik n'est pas une révolution conceptuelle face à Keycloak, mais une refonte d'expérience qui modernise l'IdP self-hosted sur les points qui frottent au quotidien : interface, branding, modélisation des parcours, intégration multi-protocoles dans un produit unique. Pour un nouveau déploiement SSO, c'est aujourd'hui l'option la plus crédible aux côtés de Keycloak, avec une empreinte plus légère et une UX plus accessible. Le choix entre les deux se joue surtout sur la stack existante et la familiarité de l'équipe.