Consultez nos archives

OAuth 2 VS JSON Web Tokens:

Comment sécuriser un API

Un billet invité de Simon, développeur chez Seedbox
(Voyez l’original en anglais sur son blog).

Dans ce billet j’examinerai deux approches populaires pour sécuriser un API, OAuth2 et les Web Tokens JSON (appelés ci-après JWT).

Il y a plusieurs autres solutions que j’aurais pu examiner, mais par soucis de concision je me concentrerai sur ces dernières. Aussi, j’assumerai que:

  • Vous avez déjà construit, ou êtes en train de construire, un API.
  • Vous êtes en train de choisir une manière de sécuriser cet API.

Encadrer le champ

La sécurité est quelque chose que vous voulez faire correctement. Si vous avez besoin de sécuriser un API immédiatement, j’imagine que vous êtes aussi en train de vous demander comment le faire, exactement.

Premièrement, s’inquiéter des informations personnelles de vos utilisateurs est un bon signe que vous faites votre travail correctement. Être sceptique et examiner les différentes solutions avec soin est le nerfs de la guerre, ici.

Deuxièmement, si vous avez déjà entendu parler un expert de sécurité, vous savez qu’il n’existe pas de « système parfaitement sécurisé ». Nous devons penser de manière plus subtile. La sécurité est un monde de plusieurs facettes, il y a tout autant de compromis, et c’est à propos de la gestion du risque, et non de son éradication.

Des pommes et des oranges

La chose la plus importante à comprendre, en comparant JWT et OAuth2, c’est qu’ils ne sont pas pareils. Ou même incompatibles.

JWT est un protocole d’authentification

Ça veut dire que c’est un ensemble strict d’instructions pour créer et valider des jetons signés. Les jetons contiennent des affirmations qui sont utilisées par l’application pour limiter l’accès d’un utilisateur.

OAuth2 est un framework d’authentification

OAuth2 quant à lui est un framework, imaginez une ligne directrice très détaillée, pour authentifier plusieurs applications différentes, à la fois dans des contextes publics et privés.

Alors pourquoi « VS » dans le titre?

Je dois être clair avec vous. La seule raison pour laquelle j’ai mis « vs » dans le titre est parce que je sais que plein de gens vont chercher une comparaison utile, et vont probablement chercher quelque chose comme ça.

Le « vs » dans le titre est trompeur, car tel que mentionné, les deux ne sont pas incompatibles entre eux. Il est possible d’avoir une implémentation d’OAuth2 qui fournit des jetons JSON comme mécanisme d’authentification.

Alors, avant de pouvoir prendre une décision à savoir quoi implémenter, nous devons comprendre exactement ce que ces solutions peuvent nous fournir.

Qu’est-ce que les Web Tokens JSON?

Un Web Token JSON (JWT) est une manière compacte et sécurisée pour les URLs de représenter des affirmations à être transférées entre deux parties. Les affirmations dans un JWT sont encodées en tant qu’objet JSON qui est signé numériquement avec une Signature Web JSON (JWS). IETF

JWT est un standard de sécurité qui a gagné beaucoup de support récemment. Il est présentement rendu aux dernières étapes en vue de devenir un standard officiel de l’IETF.

L’idée, en simple, est qu’un utilisateur fournira une combinaison de nom d’utilisateur et de mot de passe à notre serveur d’authentification. Le serveur essaiera de trouver l’utilisateur, et si l’identité peut être vérifiée, on rendra un jeton que l’utilisateur renverra pour accéder aux ressources de serveurs protégés par l’authentification JWT.

Voici un exemple de jeton :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Le jeton consiste en trois parties :

en-tête.affirmations.signature

Chacune de ces parties est encodée en base64 pour les rendre sécuritaires dans un URL.

En-tête

L’en-tête déclare simplement que ceci est un Web Token JSON, ainsi que l’algorithme utilisé pour générer la signature (plus de détails à ce propos un peu plus loin).

Un exemple:

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

Affirmations

C’est le cœur du jeton. Les affirmations sont sensées contenir des détails à propos de l’utilisateur que nous voulons transférer entre les parties. Peut-être que nous voulons être authentifié sur un serveur et accéder à des ressources sur un autre. Ou alors peut-être que notre API envoie le jeton et nous le stockons côté client, dans le navigateur, par exemple.

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

Signature

Attends, est-ce que je ne pourrais pas simplement décoder le jeton en base64 et altérer les affirmations? Oui, mais la signature deviendrait invalide. La signature est générée en utilisant une clé privée pour hacher l’en-tête et les affirmations. Comme ça, seul le jeton original correspondra à la signature. Ouf!

Cela soulève un détail d’implémentation important. Seules les applications ayant une clé privée, i.e. des applications côté serveur, peuvent faire confiance aux affirmations du jeton. Il est mal avisé de mettre une clé privée directement dans une application côté navigateur ;).

Qu’est-ce qu’OAuth2?

OAuth2, alternativement, n’est pas un protocole, c’est un framework de sécurité. Il détaille comment plusieurs rôles différents, comme les applications côté serveurs tels que des API, et les applications côté client telles que des sites web ou des applications mobiles, peuvent s’authentifier entre elles.

Malheureusement, ça me prendrait une quantité de billets de blog pour proprement expliquer OAuth2, mais voici les concepts fondamentaux.

Rôles

À la fois les applications et les utilisateurs peuvent être l’une des choses suivantes :

  • Propriétaire d’une Ressource
  • Serveur d’une Ressource
  • Application Cliente
  • Serveur d’autorisation

Types de Clients

Un client est quelque chose qui consomme votre API. Il peut être l’un des deux types suivants:

  • Confidentiel
  • Public

Profils de Clients

Il y a aussi des profils de clients spécifiés par le framework, qui décrivent la sorte de l’application. Ils peuvent êtres:

  • Application Web
  • Agent d’Utilisateur
  • Natif

Permission d’Authorization

Une permission d’authorization est un ensemble de permissions données par le propriétaire d’une resource à une application client. Elles peuvent prendre les formes suivantes:

  • Code d’authorization
  • Implicite
  • Mot de passe de propriétaire de ressource
  • Identifiants client

Point de connexion

Afin que tout fonctionne, les points de connexions suivants sont requis:

  • Point d’authorization
  • Point de connexion de jetons
  • Point de redirection

Un cheval dessiné par un comité?

Comme vous l’avez peut-être déjà deviné, OAuth2 est une spécification assez massive.

Le comité auteur d’OAuth2 avait initialement pour intention de créer un standard de protocol stricte. Toutefois, le comité n’a pu atteindre le consensus sur d’importantes parties du brouillon alors il n’est jamais même devenu un standard.

Protéger le mot de passe de vos utilisateurs: Vous avez besoin d’HTTPS!

Avant de discuter d’implémenter OAuth2 et JWT, il vaut la peine de souligner que ces deux solutions requièrent la sécurité SSL (https). Cette protection encrypte les données qui sont envoyées en ligne, entre le client et le serveur.

Cela est crucial car ni l’une ni l’autre des solutions ne fournit une manière de garder secret les identifiants de vos utilisateurs en transit. Ça veut dire que quiconque serait connecté au même wifi pourrait potentiellement voler le nom d’utilisateur et le mot de passe lors de la connexion initiale!

Quelques considérations d’implémentation importantes

Temps requis pour l’implémentation

OAuth2 est un framework de sécurité. C’est une collection de manières détaillées d’authentifier de multiples types d’applications pour divers scénarios différents. À cause de cela, il y a beaucoup de matériel à apprendre. Ce n’est pas un processus rapide.

Un développeur très habile avec qui je travaille a pris un mois entier pour comprendre OAuth2 en profondeur.

De ne pas complètement comprendre les implémentations de sécurité n’est PAS une option, et par conséquent représente un investissement de temps significatif.

JWT, d’un autre côté, est relativement plus léger d’un point de vue compréhension conceptuelle. Après une journée à lire les spécifications, je me sentais confortable de commencer une implémentation.

Risque d’erreurs d’implémentations

OAuth2 n’est pas un protocol stricte comme JWT. Par conséquent, les erreurs d’implémentations sont beaucoup plus probables. Bien que plusieurs librairies existent, ce n’est pas une panacée universelle, comme ces librairies sont écrites par des individus qui feront probablement des erreurs. Des vulnérabilités de sécurité sont trouvées très souvent dans plusieurs librairies très utilisées.

Ces risques pourraient être mitigés si vous avez une grosse équipe et pouvez dédier une ressource pour maintenir votre implémentation OAuth2.

Bénéfices d’inscriptions « sociales »

Dans plusieurs situations, il est pratique de laisser les utilisateurs s’authentifier en utilisant un compte préexsitant qu’ils possèdent sur d’autres sites plus gros.

Si vous attendez de vous utilisateurs qu’ils se servent d’un fournisseur d’authentification comme Facebook ou Gmail, OAuth2 peut être une manière plutôt rapide et sans douleur d’ajouter de l’authentification en utilisant une librairie existante.

Conclusion

En conclusion, je pense qu’il serait utile d’énumérer différents cas d’utilisation pour ces solutions.

Cas d’utilisation JWT

API distribué sans état

La plus grande force de JWT c’est qu’il gère la session d’utilisateur de votre application de manière aisément évolutive et sans état. L’utilisation d’affirmations intégrées veut dire que nous pouvons facilement extraire des informations à propos de la session de l’utilisateur sur un serveur qui n’a pas accès à la base de donnée de vos utilisateurs. Pour une architecture distribuée et orientée service, ce peut être incroyablement utile.

Forces

  • Développement rapide
  • Pas besoins témoins de navigateur
  • JSON est un bon format pour les portables
  • Pas de dépendances aux connexions à des réseaux sociaux.
  • Relativement simple à comprendre d’un point de vue conceptuel

Key Limitations

  • Tokens have size limit.
  • Tokens cannot be revoked.
  • This requires tokens to have a short expiration.

Cas d’utilisation OAuth2

Tel que je le conçoit, il y a deux manières qui font du sens pour l’utilisation d’OAuth2:

Externaliser votre serveur d’authentification

Tel que discuté dans les considérations d’implémentation, si vous n’avez pas de problème à ce que votre API ait une dépendance sur un fournisseur d’authentification tierce parti, vous pouvez simplement externaliser votre serveur d’authentification.

Vous enregistrez votre application avec un fournisseur, détaillant de quels accès vous aurez besoin pour vos utilisateurs, tels que leurs courriel, leur nom, etc.

Quand un utilisateur atteris sur votre site, il verra un bouton d’enregistrement sur la page pour qu’il puisse se connecter via le fournisseur de son choix. L’utilisateur sera ensuite redirigé de votre site vers celui du fournisseur, se fera demander d’autoriser l’accès de l’application à leur compte, et redirigés de nouveau vers votre site.

Forces

  • Développement rapide
  • Quantité réduite de code à implémenter
  • Maintenance réduite

Solution pour grande entreprise

Si vous avez plusieurs APIs qui requièrent l’authentification entre divers types d’applications, à la fois dans des contextes publiques ou privés, alors l’implémentation du framework OAuth2 fait probablement du sens.

Cela demandera une petite équipe et une quantité considérable d’heures dédiées, mais résultera d’une sécurité flexible et compréhensive pour vous diverses applications. Soyez averti, c’est un monstre à implémenter!

Si vous ne me croyez pas, voyez un avertissement de l’auteur du OAuth original qui a retiré son nom du standard OAuth2:

Clairement, OAuth 2.0 laissé aux mains d’un dévelopeur qui possède une profonde compréhension de la sécurité sur le web aura probablement pour résultat une implémentation sécure. Cela dit, entre les mains de la plupart des dévelopeurs – tel que vécu ces deux dernières années – 2.0 produira probablement des implémentations non sécures.

Si vous décidez d’implémenter JWT, vous pouvez les utiliser comme jetons-porteurs avec comme affirmations les détails des portées d’authorization dans votre installation OAuth2

Forces:

  • Implémentation flexible
  • Peut fonctionner avec JWT
  • Extensibles à diverses applications

Lectures complémentaires

Simon

(traduit par Olivier T.)

Comments

comments