ORY Hydra & ORY Kratos, une alternative à Keycloak ?

ORY est une équipe qui propose des services d’authentification pensés Cloud Native, optimisés pour une faible latence, un débit élevé et une faible consommation de ressources :

• Hydra se définit comme étant un serveur OAuth 2.0 / OpenID et un fournisseur OpenID Connect.
• Kratos, quant à lui, se positionne comme un Identity et User Management System.

À eux deux, sont-ils de véritables challengers face à notre champion en titre Keycloak ?

Hydra n’est pas un IAM

ORY Hydra n’est pas un fournisseur d’identité (le I de IAM) et ne propose donc pas les fonctionnalités suivantes :

• Gestion des authentifications
• Gestion des utilisateurs

Néanmoins, il permet de se connecter à un fournisseur d’identité existant.

C’est là qu’intervient Kratos ; qui lui, propose les fonctionnalités d’authentification traditionnelles et de la gestion d’utilisateurs.

Adoption par la communauté

L’un est maintenu par RedHat et développé sur un socle Java ; l’autre est issu d’une startup de quelques employés et s’appuie sur GOLang.

• Keycloak totalise 8000 ★, ORY Hydra et ORY Kratos 12000 ★ au cumulés
• Keycloak possède 461 contributeurs contre 200 pour ORY
• Les deux proposent des portails d’entraide (Discourse / Github Discussions) avec une communauté active
• Du côté des pulls Docker, 50M+ pour Keycloak contre 17M pour ORY.

Pas facile de les départager sur ce point, mais je l’accorde à Keycloak, qui l’emporte sur le nombre de contributeurs et de téléchargements Docker.

Implémentations OAuth et OpenID Connect

Les deux outils implémentent les standards OAuth et OpenID Connect. Ils sont d’ailleurs tout deux certifiés OpenID Provider.

Pas de points marqués pour cette manche.

Performance

Contrairement à la version actuelle de Keycloak, Hydra et Kratos sont peu consommateurs en ressources (CPU & mémoire), avec un temps de démarrage rapide, ce qui fait d’eux des candidats de choix dans une architecture Cloud Native.

La nouvelle mouture Keycloak en Quarkus pourrait changer la donne.

Si vous souhaitez essayer, vous trouverez les informations nécessaires sur le blog Keycloak.

Installation et configuration

Les trois produits proposent des binaires d’installation ainsi que des images Docker.

Chez ORY, vous ne pourrez pas démarrer les produits sans en passer par la définition de fichiers yaml en suivant cette documentation difficilement exploitable (ou celle-ci pour Kratos)

Rappelons que Keycloak propose un socle prêt à l’emploi (avec une base de données mémoire par défaut).

La configuration des produits ORY s’effectue ensuite intégralement en lignes de commande ou via une API HTTP.

Bon point pour Keycloak, qui lui, permet une configuration complète du produit via une UI d’administration poussée.

Documentation

Les documentations d’Hydra et de Kratos sont séduisantes, toutes en couleurs et proposent même un mode sombre.

Elles embarquent une recherche propulsée par Algolia ainsi que la possibilité de naviguer entre les versions des produits, ce qui est fortement appréciable.

Celle de Keycloak, quant à elle, mériterai une remise au goût du jour.

Sur la forme donc, ORY l’emporte !

Sur le fond, les documentations fournissent à mon sens l’information attendue par un développeur.

Intégrations

Coté SDKs, Hydra et Kratos proposent, comme Keycloak, des librairies dans la plupart des langages du marché.

Ces SDKs sont générés depuis OpenAPI Generator à partir de l’API des produits, ce qui apporte son lot de déconvenues.

Si vous utilisez, comme nous, le tooling OpenAPI Generator, vous n’êtes pas sans savoir que la génération produite est perfectible et changeante au fil des versions d’OpenAPI Generator. ORY ne supporte pas les breaking changes engendrés par ces montées de version, ce qui peut devenir problématique sur vos projets.

Keycloak, quant à lui, propose non seulement des SDKs développés sur mesure, mais également des intégrations avec des frameworks du marché comme Spring Boot.

Extensibilité / Personnalisation

Les documentations d’ORY ne font pas mention de la possibilité d’étendre les fonctionnalités des produits.

Toutefois, et pour l’avoir vécu pour des besoins client chez Ineat, il est parfois nécessaire de devoir étendre ou personnaliser des aspects de l’IAM.

Si on s’en tient au périmètre fonctionnel d’Hydra par exemple, qui consiste à gérer les clients et token d’accès ; l’API ne permet pas, aujourd’hui, de pouvoir agir sur les caractéristiques des tokens comme l’ajout de claims publiques, ou propose une configuration minimale pour l’expiration des tokens.

Coté Kratos, idem, pas d’extensions possibles.

Difficile, de toute façon, de rivaliser avec Keycloak sur ce point, qui va vraiment loin dans les aspects d’extensions/personnalisations au travers de l’interface d’administration ou de l’implémentation des nombreux SPIs.

La force d’ORY réside toutefois sur le fait que ses produits laissent la possibilité aux équipes de tailler leur besoin en IAM comme elles le souhaitent (avec bien plus d’efforts à fournir) en se basant sur les fonctionnalités du socle.

Gestion des utilisateurs

La gestion des identités est essentielle si vous avez besoin de gérer des utilisateurs.

Chez Keycloak, l’ensemble de ce périmètre est exploitable depuis l’interface d’administration en WYSIWYG (ou depuis l’API). Les fonctionnalités sont nombreuses (CRUD utilisateur, Imitation, logs des événements de connexion, etc) et il est même possible de définir votre propre gestion des identités.

Rappelons également que Keycloak fournit des pages prêtes à l’emploi pour les scenarii d’authentification.

Le parti pris de Kratos est de ne pas fournir de rendu HTML de ces scenarii (en mode API First, mais fournit un exemple d’implémentations).

L’API de gestion des identités de Kratos n’est pas triviale et demandera du temps pour construire votre propre modèle et l’exploiter (par API, toujours)

J’accorde ce point à Keycloak qui fournit le 80/20 et saura vous faire économiser de précieuses heures de développement

Qui gagne le match ?

Sur le papier, Keycloak sort victorieux, mais pour dire vrai, les solutions n’ont pas la même approche.

ORY Hydra et ORY Kratos couvrent à eux deux, à la louche, 70% du périmètre de Keycloak avec de grosses configurations à produire, des développements applicatifs et des intégrations à prévoir.

ORY dresse un constat des limites des IAM “full-stack” dans sa documentation.

Pour quelles raisons utiliser ORY ?

• Vous aimez les architectures / solutions modulaires
• Vous avez du temps, de bons ingénieurs et du budget
• Vos administrateurs I/AM sont des OPS
• Hydra
  • Vous avez besoin de sécuriser vos applications (API, PWA, apps mobile) au travers des standards Oauth2 / OpenID Connect.
  • Vous souhaitez agir comme Identity Provider (comme Google, Facebook et autre).
  • Vos besoins en sécurisation ne sont pas spécifiques.
• Kratos
  • Vous avez besoin de gérer des identités
  • et développer les tunnels d’authentification n’est pas un sujet

Et que

• Vous évoluez dans un contexte Cloud ; votre infrastructure est gérée par des orchestrateurs de conteneurs.
  • Vous avez donc besoin d’applications à faible empreinte.
• Vous avez dans votre équipe des Ops qui seront en capacité de gérer ce produit (déploiement, administration en ligne de commande, etc).

Pour tout le reste, Keycloak saura vous séduire et répondre à l’ensemble de vos besoins.

Retrouvez nos articles sur Keycloak en suivant ce lien.