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 đŸ˜±

    ​

  • Secure Storage