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
DerniĂšre mise Ă  jour 2yr ago