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
IdĂ©alement, il nous faudrait un mĂ©canisme dâauthentification mĂȘme si les donnĂ©es de lâAPI sont publiques.
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Ă©.
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
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 :
Le service dâauthentification fournit un token unique au client.
Le client transmet ce token aux APIs ReST du fournisseur de service.
Le fournisseur de service dĂ©duit les autorisations dâaccĂšs en fonction de ce token.
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,
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