Nouveau système d'authentification : 2FA, jetons d'accès et plus

Aujourd'hui, nous passons à un tout nouveau système d'authentification basé sur une architecture moderne. Ce nouveau système est accompagné de quelques bonus comme l'authentification à 2 facteurs également connue sous le nom de 2FA. La migration est transparente et l'ancien système d'authentification sera maintenu compatible jusqu'au 31 août, date à laquelle il sera arrêté. Si vous avez écrit des clients API personnalisés, vous devrez les adapter.

L'ancienne version

Jusqu'à présent, l'authentification a été entièrement gérée par notre API qui agissait comme un proxy intelligent pour d'autres services (par exemple, les métriques et les journaux sont des services indépendants). L'authentification se faisait par un jeton API qui était unique au compte de l'utilisateur et avait une durée de vie infinie.

C'est un peu tautologique, mais parce que le jeton était unique, il n'y avait qu'un seul jeton partagé par tous vos clients API : le tableau de bord, mais aussi le CLI et peut-être vos propres clients API personnalisés. Cela augmentait le risque qu'un jeton soit divulgué. Et si par hasard ce jeton devait être révoqué (regénéré en fait), tous vos clients API seraient incapables de s'authentifier contre nos services jusqu'à ce que vous remplaciez l'ancien jeton par le nouveau.

Bien sûr, utiliser des jetons à longue durée de vie, même si ce n'est pas un problème en soi, augmente considérablement l'impact des jetons divulgués.

La nouvelle version

Ce nouveau système d'authentification a été conçu pour atteindre plusieurs objectifs : il doit être prêt pour plusieurs centres de données, évolutif horizontalement, pratique pour les développeurs, il doit permettre l'authentification d'applications tierces, il doit atténuer les deux problèmes mentionnés ci-dessus et il doit être… sécurisé (évidemment).

Avec la nouvelle version, l'authentification est totalement découplée de l'API, pour ce faire, un nouveau service a été déployé dans notre infrastructure : le service d'authentification. Ce service est disponible publiquement à https://auth.scalingo.com et sera responsable de l'ensemble de l'authentification sur l'infrastructure de Scalingo. Son rôle est simple : échanger les informations d'authentification des utilisateurs contre des jetons qui peuvent être utilisés universellement sur la plateforme. L'API de Scalingo n'acceptera désormais que des jetons à courte durée de vie délivrés par le service d'authentification. Le service est techniquement basé sur deux normes web bien connues : OAuth et JWT.

Pour le moment, si une application a besoin de lister les applications d'un utilisateur spécifique, elle devra d'abord obtenir un jeton du service d'authentification. Cela se fait via le protocole OAuth qui redirigera l'utilisateur vers le service d'authentification et utilisera ensuite ce jeton contre cette API. Une fois ce jeton expiré, la danse OAuth devra recommencer pour obtenir un jeton rafraîchi.

En découplant le processus d'authentification de l'accès aux ressources, il est beaucoup plus facile de construire de nouvelles fonctionnalités d'authentification et de sécurité. C'est pourquoi ce nouveau service est livré avec deux nouvelles fonctionnalités pratiques : les jetons d'accès et la 2FA.

Jetons d'accès

Un nombre quelconque de jetons API associés à votre compte peut maintenant être généré et vous pouvez attribuer chacun d'eux à n'importe lequel de vos scripts, outils ou intégrations personnalisés. Le tableau de bord vous permettra de voir la dernière utilisation de votre compte Scalingo par ce service, et plus important encore de le révoquer sans impacter d'autres outils utilisant votre compte Scalingo.

Une fois générés, ces jetons auront un accès complet à votre compte et aux ressources auxquelles il peut accéder (les ACL viendront plus tard, voir le paragraphe Quelles sont les prochaines étapes ci-dessous). Cependant, ce jeton ne peut pas être utilisé pour interroger directement l'API, vous devrez d'abord l'échanger contre un jeton à courte durée de vie via le service d'authentification.

Authentification à deux facteurs

La deuxième nouvelle fonctionnalité est l'authentification à deux facteurs (2FA en abrégé). Elle fournit une couche de sécurité supplémentaire pour l'authentification de votre compte en combinant deux facteurs différents : quelque chose que vous savez (un nom d'utilisateur/mot de passe) et quelque chose que vous avez (un téléphone ou un matériel spécifique). La 2FA peut être activée sur votre page de profil. Une fois activée, chaque fois que vous essayerez de vous connecter à Scalingo, votre identité devra être prouvée en fournissant le code donné par le dispositif choisi.

Pour le moment, TOTP (mot de passe à usage unique basé sur le temps) est la seule authentification à deux facteurs implémentée. Google Authenticator ou Authy sont construits pour ce protocole. D'autres normes comme U2F seront implémentées plus tard. Comme toujours, faites part de vos préoccupations concernant U2F sur le canal de support si vous souhaitez que nous accélérions cet élément dans notre feuille de route interne.

Une perspective technique

OAuth

L'architecture logicielle de Scalingo est basée sur Ruby on Rails (API orientées utilisateur) et une flotte de microservices écrits en Go. Notre choix par défaut lors de l'implémentation d'un nouveau microservice est généralement d'utiliser Go.

C'est pourquoi nous avons initialement commencé à écrire le nouveau système d'authentification avec Go. Il existe de très bonnes bibliothèques Go pour créer des clients OAuth2, gérer l'authentification ou créer des serveurs OAuth2. Cependant, le manque d'intégration entre ces bibliothèques et l'infrastructure de code encore immature pour soutenir le développement web (dans le sens des formulaires, HTML/CSS, JS, etc.) aurait considérablement affecté le temps de développement nécessaire pour créer ce service. Nous avons dû changer notre approche.

En regardant ce que le monde Ruby/Rails a à offrir, il existe (évidemment) une implémentation mature d'OAuth : Doorkeeper. Avec les capacités naturelles de Rails (construire des formulaires et l'intégration de webpack est un jeu d'enfant) et notre connaissance actuelle de Devise et Warden, c'était un match parfait. Cela s'est avéré être un très bon choix à long terme en raison de la maturité de ces gems, de leur communauté et de leur interopérabilité.

JWT

Les jetons à courte durée de vie délivrés par le service d'authentification sont des JSON Web Tokens (JWT).

Une de nos exigences techniques était de pouvoir accéder aux informations suivantes concernant un jeton sans interroger le service d'authentification :

1. Validité du jeton (est-ce que c'est un jeton valide sur Scalingo ?)

2. Expiration du jeton (combien de temps ce jeton est-il valide ?)

3. Utilisateur associé à ce jeton

Comme l'API publique et le service d'authentification sont maintenant deux entités différentes, cela est obligatoire. Sans cela, chaque requête adressée à l'API publique nécessiterait une autre requête de l'API vers le service d'authentification, entraînant un surcoût indésirable et une évolutivité limitée.

Pour résoudre ces problèmes, la solution choisie est JWT. JWT est une norme qui définit un moyen compact et autonome de transmettre des informations de manière sécurisée entre plusieurs applications. Son fonctionnement interne est assez simple.

Un jeton JWT est composé de trois parties différentes : en-tête, charge utile et signature.

L'idée principale derrière un JWT est de stocker des données dans le jeton qui peuvent être dignes de confiance. Les JWT y parviennent en signant cryptographiquement le jeton : la troisième partie du jeton est la signature et elle est calculée avec la méthode suivante :

HMACSHA512(base64(header) + "." + base64(payload), secret)

HMACSHA512(base64(header) + "." + base64(payload), secret)

HMACSHA512(base64(header) + "." + base64(payload), secret)

HMACSHA512(base64(header) + "." + base64(payload), secret)

Si le service d'authentification et l'API partagent le même secret, l'API peut vérifier que le jeton provient du service d'authentification sans besoin de communiquer avec le service d'authentification. Cela nous permet également d'ajouter des informations dans la partie charge utile du jeton et de garantir qu'un attaquant n'a pas altéré les données.

Veuillez noter qu'il y a certaines considérations de sécurité lors de l'utilisation de JWT. Dans l'exemple de signature donné ci-dessus, l'algorithme de signature utilisé est HS512. La norme autorise l'utilisation de plusieurs algorithmes. Ils sont définis dans la partie en-tête du jeton lui-même dans :

{
  "typ": "JWT",
  "alg": "HS512"
}

{
  "typ": "JWT",
  "alg": "HS512"
}

{
  "typ": "JWT",
  "alg": "HS512"
}

{
  "typ": "JWT",
  "alg": "HS512"
}

Cela peut entraîner plusieurs vulnérabilités comme l'algorithme none ou certains problèmes liés à une mauvaise implémentation. C'est pourquoi sur Scalingo, le seul algorithm pris en charge est HS512.

Quelles sont les prochaines étapes ?

Maintenant que nous avons une base saine et moderne en place, l'ajout de nouvelles fonctionnalités de sécurité sera plus facile. La refonte de la couche authentification était le premier pas. Nous allons maintenant pouvoir travailler sur la couche autorisation. Cela conduira à d'autres fonctionnalités excitantes comme les ACL et les Organisations.

Enfin, ces fondations étaient nécessaires pour commencer à avoir plusieurs zones de disponibilité disponibles à travers le monde (bonjour Amérique du Nord et Asie).

Nos connaissances sur tous ces sujets ont été partagées par notre CTO lors du Paris API Meetup de janvier 2018 : "Modern API Authentication 101". Vous pouvez lire les diapositives sur Speakerdeck.