Authentification et Session Management

De quoi avons-nous besoin ?

Session management ?

Nope ! L’API ReST doit être Stateless !

Si des informations liées à la session doivent être maintenues, celles-ci doivent être gérées par le client.

Les données persistées par l’API ReST sont associées à des ressources.

Rien n’interdit l’expiration d’une ressource : GET /carts/1234 => 404 Not Found

Ne schtroumpfez pas !SMURF /smurf-api/sessions/current

Authentification

Idéalement, il nous faudrait un mécanisme d’authentification même si les données de l’API sont publiques.

Identification

L'identification n'est implémentée que si réellement nécessaire.

L’authentification et l’identification sont des notions distinctes. Il est possible d’authentifier un utilisateur sans l’identifier. Il est également possible d’identifier un utilisateur sans l’authentifier mais nous n’aurions aucune garantie de l’identité.

Logout et révocation

Le logout peut provenir d’une autre source que l’utilisateur final.

Les "tokens" d’authentification ne doivent pas être transmis dans l’URL. GET /users/123?token=asdf....

L’authentification "basic-auth" ne doit pas être utilisée.

Les tokens doivent être transmis dans le header Authorization

Authorization: Bearer xxxxxx, Extra yyyyy

Mécanismes d’authentification

Nous parcourerons plus tard les différents mécanismes d’authentification envisageables.

Globalement (modulo quelques étapes), la plupart des mécanismes d’authentification fonctionnent ainsi :

1. Le service d’authentification fournit un token unique au client.

2. Le client transmet ce token aux APIs ReST du fournisseur de service.

3. Le fournisseur de service déduit les autorisations d’accès en fonction de ce token.

Session Management côté client

Le cas le plus complexe est celui où le client est un browser.

Si vous souhaitez persister des données dans le browser afin que l’utilisateur puisse retrouver le même contexte en changeant de fenêtre ou après un refresh :

• Evitez absolument l’utilisation des cookies ne serait-ce que pour les raisons suivantes :

  • Ce n’est pas leur rôle.

  • Vous ne voulez pas envoyer toutes ces données au backend à chaque requête.

  • Cookies are EVIL !

• IndexedDB et localStorage sont là pour ça.

• Problème 😱

  • L'IndexedDB et le localStorage n’ont pas de notion d’expiration sauf sur Firefox : https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open.
  • Jetez un coup d’oeil au contenu de vos storages après logout ou fermeture du browser, vous serez surpris de découvrir ce qu’on y retrouve.

• Secure Storage

  • en attendant une solution in-the-browser, il est recommandé de chiffrer les données stockées localement avec une clé temporaire et unique pour chaque client transmise par l’API ReST,

  • https://github.com/jas-/crypt.io,
  • ou encore mieux, en stockant la clé via l'API browser webauthn quand celle-ci sera globalement disponible. https://developers.google.com/web/updates/2018/05/webauthn