Authentification, autorisation et gestion de Session dans les applications Web traditionnelles et les API

protocole HTTP est apatride par conception, chaque requête est faite séparément et est exécutée dans un contexte séparé.

l'idée derrière la gestion de session est de mettre les requêtes du même client dans le même contexte. Ceci est fait en émettant un identifiant par le serveur et en l'envoyant au client, alors le client enregistrera cet identifiant et le renverra dans les requêtes suivantes afin que le serveur puisse l'identifier.

Cookies

dans un cas typique de navigateur-serveur; le navigateur gère une liste de combinaisons clé/valeur, connues sous le nom de cookies, pour chaque domaine:

• les Cookies peuvent être gérés par le serveur (créé/modifié/supprimé) en utilisant L'en-tête de réponse HTTP Set-Cookie .
Les Cookies
• peuvent être consultés par le serveur (en lecture) en utilisant l'en-tête de requête HTTP Cookie .

Web ciblé des langages de programmation/cadres de fournir fonctions pour traiter les cookies à un niveau plus élevé, par exemple, PHP fournit setcookie / $_COOKIE pour écrire / lire des cookies.

Sessions

retour aux sessions, dans un cas typique de navigateur-Serveur (encore), la gestion de session côté serveur profite de la gestion des cookies côté client. gestion de session de PHP définit un cookie d'id de session et l'utilise pour identifier les demandes ultérieures.

API applications Web?

maintenant retour à votre question; comme vous seriez celui responsable de la conception de L'API et de la Documentation, la mise en œuvre serait votre décision. Vous avez essentiellement à

1. donner au client un identifiant, que ce soit via un en-tête de réponse HTTP Set-Cookie , à l'intérieur du corps de réponse (réponse XML/JSON auth).
2. ont un mécanisme pour maintenir identification / association client. par exemple, une table de base de données qui associe l'identificateur 00112233445566778899aabbccddeeff au numéro de client/utilisateur 1337 .
3. demander au client de lui renvoyer le document d'identification à (1.) dans toutes les requêtes suivantes, que ce soit dans un en-tête de requête HTTP Cookie , un param ?sid=00112233445566778899aabbccddeeff (*).
4. recherche l'identificateur reçu, en utilisant le mécanisme à (2.), de vérifier si une authentification valide, et il est autorisé à faire l'opération demandée, puis procéder à l'opération au nom de l'utilisateur autorisé.

bien sûr, vous pouvez construire sur l'infrastructure existante, vous pouvez utiliser la gestion de session de PHP (qui prendrait soin de 1./2. et la partie authentification de 4.) dans votre application, et exiger que la mise en œuvre côté client Faire la gestion des cookies(qui prendrait soin de 3.), et puis vous avez le reste de votre application logique à cela.

(*) chaque approche a des inconvénients et les pros, par exemple, l'utilisation d'une requête GET param est plus facile à mettre en œuvre, mais peut avoir des implications de sécurité, puisque les requêtes GET sont enregistrées. Vous devez utiliser https pour Critique (tous?) application.

la gestion de session relève de la responsabilité du serveur. Lorsqu'une session est créée, un jeton de session est généré et envoyé au client (et stocké dans un cookie). Après cela, dans les requêtes suivantes entre le client et le serveur, le client envoie le token (généralement) sous forme de cookie HTTP. Toutes les données de session sont stockées sur le serveur, le client ne stocke que le token. Par exemple, pour démarrer une session en PHP vous avez juste besoin de:

session_start();  // Will create a cookie named PHPSESSID with the session token

après la création de la session, vous pouvez sauvegarder les données sur elle. Par exemple, si vous voulez garder un utilisateur connecté:

// If username and password match, you can just save the user id on the session
$_SESSION['userID'] = 123;

Maintenant vous pouvez vérifier si un utilisateur est authentifié ou non:

if ($_SESSION['userID'])
    echo 'user is authenticated';
else
    echo 'user isn't authenticated';       

si vous voulez, vous pouvez créer une session uniquement pour un utilisateur authentifié:

if (verifyAccountInformation($user,$pass)){ // Check user credentials
    // Will create a cookie named PHPSESSID with the session token
    session_start();
    $_SESSION['userID'] = 123;
}

Il ya de nombreuses façons pour les utilisateurs authentiques, à la fois pour les applications Web et les API. Il ya quelques normes, ou vous pouvez écrire votre propre autorisation / et / ou authentification personnalisée. Je tiens à souligner la différence entre l'autorisation et l'authentification. Premièrement, l'application doit authentifier l'utilisateur (ou le client api) d'où provient la requête. Une fois que l'Utilisateur a été authentifié, sur la base de l'identité de l'application doit déterminer ce que l'utilisateur authentifié a la permission effectuer certaines applications (autorisation). Pour la plupart des applications web traditionnelles, il n'y a pas de granularité fine dans le modèle de sécurité, donc une fois que l'utilisateur est authentifié, il est dans la plupart des cas aussi et autorisé à effectuer certaines actions. Toutefois, ces deux concepts (authentification et autorisation) devraient être considérés comme deux opérations logiques différentes.

plus, dans les applications Web classiques, après que l'Utilisateur a été authentifié et autorisé (surtout par la recherche jusqu' nom d'utilisateur / mot de passe dans la base de données), l'autorisation et l'information d'identité est écrite dans le stockage de session. Le stockage de Session ne doit pas nécessairement être côté serveur, comme la plupart des réponses ci-dessus le suggèrent, il pourrait également être stocké dans un cookie côté client, crypté dans la plupart des cas. Pour un exemple, PHP CodeIgniter framework le fait par défaut. Il y a un certain nombre de mécanismes pour protéger la session côté client, et je ne vois pas cette façon de stocker les données de session moins sécurisée que le stockage de sessionId, qui est alors cherché dans le stockage de session sur le côté du serveur. En outre, stocker la session côté client est très pratique dans un environnement distribué, car cela élimine le besoin de concevoir une solution (ou d'en utiliser une déjà existante) pour la gestion de session centrale côté serveur.

en outre, l'authentification avec une simple paire utilisateur-mot de passe ne doit pas être dans tous les cas fait à l'aide du code personnalisé qui cherche l'utilisateur correspondant-enregistrement dans la base de données. Il y a, par exemple de base protocole d'authentification , ou authentification digest . Sur les logiciels propriétaires comme la plate-forme Windows, il ya aussi des moyens d'authentifier l'utilisateur trough, pour un exemple, ActiveDirectory

fournir une paire nom d'utilisateur/mot de passe n'est pas seulement une façon d'authentifier, si vous utilisez le protocole HTTPS, vous pouvez également considérer l'authentification en utilisant des certificats numériques .

pour une utilisation spécifique cas, si la conception de service web, qui utilise SOAP comme protocole, il ya aussi WS-Security extension pour le protocole SOAP.

avec tout cela dit, je dirais que les réponses à la question suivante entrent la procédure de décision pour le choix du mécanisme d'autorisation / authentification pour WebApi:

1) Quel est le public cible, est-il accessible au public ou est-il réservé aux membres inscrits(payants)?

2) Est-il courir ou * Nix, ou plate-forme MS

3) quel nombre d'utilisateurs est prévu

4) combien de données sensibles L'API traite avec (mécanismes d'authentification plus forts vs plus faibles)

5) y a-t-il un service de SSO que vous pourriez utiliser

.. et beaucoup plus.

espère que cela efface les choses bit, comme il ya beaucoup de variables dans l'équation.

si L'application basée sur L'API est un Client, alors L'API doit avoir la possibilité de récupérer/lire les cookies à partir du flux de réponse du serveur et de les stocker. Pour l'ajout automatique de cookies lors de la préparation d'un objet request pour le même serveur/url. S'il n'est pas disponible, l'id de session ne peut pas être récupéré.

je vous suggère d'envoyer une sorte de jeton avec chaque requête.

dépendant du serveur et du service, ceux-ci peuvent être un paramètre JSESSIONID dans votre requête GET/POST ou quelque chose de mature comme SAML dans SOAP over HTTP dans votre requête de Service Web.

vous avez raison, la raison pour laquelle les choses sont "automatiques" dans un environnement standard est parce que les cookies sont préférés à la propagation URL pour garder les choses jolies pour les utilisateurs. Cela dit, le navigateur (logiciel client) gère le stockage et l'envoi du cookie de session avec chaque demande.

dans le monde de L'API, les systèmes simples ont souvent simplement des justificatifs d'authentification transmis avec chaque demande (au moins dans mon domaine de travail). Les auteurs clients sont généralement (encore une fois dans mon expérience) réticent à mettre en œuvre le stockage de cookie, et la transmission avec chaque demande et généralement rien de plus que le strict minimum...

il y a beaucoup d'autres mécanismes d'authentification pour les API basées sur HTTP, HTTP basic / digest pour n'en nommer que quelques-uns, et bien sûr l'omniprésent o-auth qui est conçu spécifiquement pour ces choses si Je ne me trompe pas. Aucun cookie n'est maintenu, les justificatifs d'identité font partie de chaque échange (assez sûr sur cela).

l'autre chose à considérer est ce que vous allez faire avec la session sur le serveur dans une API. La session sur un site Web fournit le stockage pour l'utilisateur courant, et stocke généralement de petites quantités de données pour enlever la charge de la base de données d'une page à l'autre. Dans un contexte API, cela est moins nécessaire car les choses sont plus ou moins apatrides, en général bien sûr; cela dépend vraiment de ce que le service fait.