REST API Login Pattern

je crée une api REST, en suivant de près les suggestions d'apigee, en utilisant des noms Pas de verbes, une version api intégrée dans l'url, deux chemins api Par collection, GET POST PUT DELETE usage, etc.

je travaille sur le système de connexion, mais je ne suis pas sûr de la façon correcte de se reposer pour se connecter utilisateurs. Je ne travaille pas sur la sécurité à ce point, juste le modèle de connexion ou le flux. (Plus tard, nous allons ajouter 2 étape oAuth, avec un HMAC, etc)

Options Possibles

  • , UN POSTE à quelque chose comme https://api...com/v1/login.json
  • METTRE à quelque chose comme https://api...com/v1/users.json
  • quelque chose que je n'ai pas pensé...

Quel est le style de repos approprié pour se connecter aux utilisateurs?

162
demandé sur Scott Roepnack 2012-12-17 19:05:14

3 réponses

Principled Design of the Modern Web Architecture by Roy T. Fielding and Richard N. Taylor , i.e. sequence of works from all REST terminology came from, contains definition of client-server interaction:

Tout le RESTE interactions sont apatrides . C'est-à-dire que chaque requête contient toutes les informations nécessaires pour un connecteur à comprendre le demande, indépendamment de toute demande qui peut avoir précédé .

cette restriction remplit quatre fonctions, la première et la troisième est importante dans ce cas particulier:

  • 1st : il supprime tout besoin pour les connecteurs de conserver l'état d'application entre les demandes , réduisant ainsi la consommation de ressources physiques et l'amélioration de l'évolutivité;
  • 3rd : il permet à un intermédiaire de voir et comprendre une demande en isolation ,

et maintenant, revenons à votre sécurité. Chaque demande doit contenir tous les renseignements requis, et l'autorisation ou l'authentification ne constitue pas une exception. Comment atteindre cet objectif? Littéralement envoyer tout le nécessaire informations sur les fils avec chaque demande.

L'un des exemples comment archiver ceci est code d'authentification de message basé sur le hachage ou HMAC . En pratique, cela signifie ajouter un code de hachage de message courant à chaque requête. Code de hachage calculé par fonction de hachage cryptographique en combinaison avec une clé cryptographique secrète . cryptographique fonction de hachage est prédéfini ou partie de code-sur-demande RESTE la conception (par exemple JavaScript). clé cryptographique secrète doit être fourni par le serveur au client comme ressource, et le client l'utilise pour calculer le code de hachage pour chaque demande.

il y a beaucoup d'exemples de HMAC implémentations, mais je voudrais que vous prêtiez attention aux trois suivants:

Comment cela fonctionne dans la pratique

si le client connaît la clé secrète, alors elle est prête à fonctionner avec des ressources. Sinon, il sera temporairement redirigé (code de statut 307 redirection temporaire) pour autoriser et obtenir la clé secrète, puis redirigé vers la ressource originale. Dans ce cas il y a pas besoin de savoir à l'avance (i.e. hardcode somewhere) Quelle est L'URL pour autoriser le client est , et il est possible d'ajuster ce schéma avec le temps.

J'espère que cela vous aidera pour trouver la bonne solution!

119
répondu Akim 2017-05-23 12:02:48

TL;DR Login pour chaque demande n'est pas un élément requis pour mettre en œuvre l'API de sécurité, l'authentification est.

Il est difficile de répondre à votre question sur la connexion sans parler de la sécurité en général. Avec certains systèmes d'authentification, il n'y a pas de tradition de connexion.

REST ne dicte aucune règle de sécurité, mais l'implémentation la plus courante dans la pratique est L'authentification à 3 voies (comme vous l'avez mentionné dans votre question). Il n'y a pas de connexion en soi, du moins pas avec chaque requête API. Avec 3-way auth, vous n'utilisez que des tokens.

  1. l'utilisateur approuve le client API et accorde la permission de faire des demandes sous la forme d'un token de longue durée
  2. Le client Api
  3. obtient un token de courte durée en utilisant le token de longue durée.
  4. Le client Api
  5. envoie le token de courte durée avec chaque requête.

ce régime donne l'utilisateur la possibilité de révoquer à tout moment l'accès. Pratiquement tous les APIs RESTful accessibles au public que j'ai vu utiliser OAuth pour mettre en œuvre ceci.

Je ne pense pas que vous devriez encadrer votre problème (et question) en termes de login, mais plutôt penser à sécuriser l'API en général.

pour plus d'informations sur l'authentification des APIs REST en général, vous pouvez consulter les ressources suivantes:

39
répondu Slavo 2017-05-23 11:54:57

une grande partie de la philosophie REST est d'exploiter autant de fonctionnalités standard du protocole HTTP que possible lors de la conception de votre API. En appliquant cette philosophie à l'authentification, le client et le serveur utiliseraient les fonctionnalités D'authentification HTTP standard de l'API.

Les écrans de connexion

sont parfaits pour les cas d'utilisation par l'utilisateur humain: visiter un écran de connexion, fournir un utilisateur/mot de passe, définir un cookie, le client fournit ce cookie dans toutes les demandes futures. Les humains utilisant les navigateurs web ne peuvent pas être on s'attend à fournir un nom d'utilisateur et un mot de passe pour chaque requête HTTP.

mais pour une API REST, un écran de connexion et des cookies de session ne sont pas strictement nécessaires, puisque chaque demande peut inclure des informations d'identification sans impact sur un utilisateur humain; et si le client ne coopère pas à tout moment, une réponse 401 " non autorisée " peut être donnée. RFC 2617 décrit en charge de l'authentification HTTP.

TLS (HTTPS) serait également une option, et permettrait l'authentification du client vers le serveur (et vice versa) dans chaque requête en vérifiant la clé publique de l'autre partie. En outre, cela sécurise le canal pour un bonus. Bien sûr, un échange de touches avant la communication est nécessaire pour le faire. (Note: il s'agit spécifiquement d'identifier/authentifier l'utilisateur avec TLS. Sécuriser le canal en utilisant TLS / Diffie-Hellman est toujours une bonne idée, même si vous n'identifiez pas l'utilisateur par sa clé publique.)

un exemple: supposons qu'un token OAuth soit votre identifiant de connexion complet. Une fois que le client a le token OAuth, il peut être fourni comme id utilisateur dans l'authentification HTTP standard avec chaque requête. Le serveur peut vérifier le token lors de la première utilisation et mettre en cache le résultat de la vérification avec un time-to-live qui est renouvelé avec chaque requête. Toute requête nécessitant une authentification renvoie 401 si elle n'est pas fournie.

22
répondu wberry 2012-12-19 17:51:26