Jetons et sessions OAuth dans REST

Question

L'autre minute, j'ai lu un article sur OAuth. Il décrivait notamment les jetons échangés entre le client et le fournisseur de services lors d'une série de requêtes.

L'article mentionne également que OAuth gagne en popularité dans les API RESTful en tant que couche d'autorisation. D'après ce que j'ai compris, REST doit rester complètement sans état.

La question : Cet échange répété de jetons ne torpille-t-il pas le principe d'apatridie de REST ? À mon avis, les jetons peuvent être considérés comme une sorte d'identifiant de session, n'est-ce pas ?

Answer 1

Les jetons OAuth sont explicitement un identifiant de session, l'interaction n'est pas sans état entre les requêtes dans le protocole de négociation des jetons OAuth car les requêtes doivent être effectuées dans une séquence spécifique, et ils nécessitent un stockage par client sur le serveur car vous devez suivre des choses comme le moment où ils ont été émis. Donc oui, OAuth viole les principes stricts d'une architecture RESTful.

Malheureusement, il y a le monde réel TM Nous avons besoin de faire des choses comme permettre aux applications de s'authentifier au nom des individus sans leur demander leur mot de passe, ce que OAuth fait assez bien. Il serait impossible de mettre en œuvre un schéma d'authentification aussi sûr sans ce type d'état. En effet, l'un des changements requis par OAuth (1.0a) était d'ajouter plus au protocole de négociation de jetons pour atténuer un risque de sécurité.

Alors, est-ce que cela torpille le principe de stateless de REST ? Oui. Est-ce important ? Non, sauf si vous vivez dans une tour d'ivoire :-)

Answer 2

L'authentification est un état qui doit être suivi d'une manière ou d'une autre lorsqu'il s'agit d'interactions web. En fin de compte, que votre application soit restful ou non, le serveur doit être en mesure de suivre l'"état d'authentification" de chaque utilisateur et, malheureusement, cela nécessite une sorte de contournement de la nature sans état sous-jacente de HTTP et de tout transport/technique supplémentaire (comme REST) par-dessus.

Par conséquent, pour développer n'importe quel type d'application authentifiée, un principe d'état doit être introduit quelque part, et si cela se trouve être OAuth au-dessus de REST, c'est ainsi que cela doit être !