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 :
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.
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
etlocalStorage
sont lĂ pour ça.ProblĂšme đ±
L'
IndexedDB
et lelocalStorage
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
DerniĂšre mise Ă jour