web-dev-qa-db-fra.com

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

Corrigez-moi si je me trompe: dans une application Web traditionnelle, le navigateur ajoute automatiquement les informations de session dans une demande adressée au serveur, afin que celui-ci puisse savoir de qui provient cette demande. Qu'est-ce qui est ajouté exactement?

Cependant, dans une application basée sur une API, ces informations ne sont pas envoyées automatiquement. Par conséquent, lors du développement d'une API, je dois vérifier moi-même si la demande provient d'un utilisateur authentifié, par exemple. Comment cela se fait-il normalement?

apisessionauthenticationauthorization
73
Jiew Meng

Le protocole HTTP est sans état par conception, chaque demande est effectuée séparément et est exécutée dans un contexte séparé.

L'idée derrière la gestion de session est de placer les requêtes du même client dans le même contexte. Pour ce faire, le serveur envoie un identifiant et l'envoie au client. Le client sauvegardera cet identifiant et le renverra dans les requêtes suivantes afin que le serveur puisse l'identifier.

Biscuits

Dans un cas typique navigateur-serveur; le navigateur gère une liste de paires clé/valeur, appelées cookies, pour chaque domaine:

  • Les cookies peuvent être gérés par le serveur (créé/modifié/supprimé) à l’aide du fichier Set-Cookie En-tête de réponse HTTP.
  • Le serveur (lu) peut accéder aux cookies en analysant l’en-tête de la requête HTTP Cookie.

Les langages de programmation/frameworks ciblés par le Web fournissent des fonctions permettant de traiter les cookies à un niveau supérieur, par exemple, PHP fournit _ setcookie / $_COOKIE pour écrire/lire les cookies.

Sessions

Retour aux sessions, Dans un cas typique de navigateur-serveur (encore), la gestion de session côté serveur tire parti de la gestion des cookies côté client. La gestion de session de PHP définit un cookie d'identification de session et l'utilise pour identifier les requêtes suivantes.

API d'applications Web?

Revenons maintenant à votre question. étant donné que vous seriez responsable de la conception de l’API et de sa documentation, l’implémentation relèverait de votre décision. Vous devez essentiellement

  1. donnez au client un identifiant, que ce soit via un Set-Cookie En-tête de réponse HTTP, à l'intérieur du corps de la réponse (réponse d'autorisation XML/JSON).
  2. disposer d'un mécanisme pour maintenir l'association identifiant/client. par exemple une table de base de données associant l'identifiant 00112233445566778899aabbccddeeff avec le client/utilisateur #1337.
  3. demandez au client de renvoyer l'identifiant qui lui est envoyé en (1.) dans toutes les requêtes suivantes, que ce soit dans un en-tête HTTP Cookie, un ?sid=00112233445566778899aabbccddeeff param (*).
  4. recherchez l'identifiant reçu, en utilisant le mécanisme de (2.), vérifiez si une authentification valide est autorisée et est autorisée à effectuer l'opération demandée, puis procédez à l'opération pour le compte de l'utilisateur autorisé.

Bien sûr, vous pouvez utiliser l'infrastructure existante, vous pouvez utiliser la gestion de session de PHP (qui prend en charge 1./2. Et la partie authentification de 4.) dans votre application, et demander à la mise en œuvre côté client de gérer les cookies (qui prendrait soin de 3.), et ensuite vous ferez le reste de la logique de votre application à ce sujet.

(*) Chaque approche a ses inconvénients et ses inconvénients. Par exemple, l’utilisation d’un paramètre de requête GET est plus facile à mettre en œuvre, mais peut avoir des implications en matière de sécurité, car les demandes GET sont journalisées. Vous devez utiliser https pour les applications critiques (toutes?).

120
aularon

La gestion de la session est la responsabilité du serveur. Lorsque la 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 jeton (généralement) sous la forme d'un cookie HTTP. Toutes les données de session sont stockées sur le serveur, le client ne stocke que le jeton. Par exemple, pour démarrer une session dans PHP, il vous suffit de:

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

Une fois la session créée, vous pouvez enregistrer des données dessus. Par exemple, si vous souhaitez conserver un utilisateur connecté:

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

Vous pouvez maintenant vérifier si un utilisateur est authentifié ou non:

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

Si vous le souhaitez, 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;
}
45
Guilherme Torres Castro

Il existe de nombreuses méthodes pour les utilisateurs authentiques, à la fois pour les applications Web et les API. Il existe quelques normes, ou vous pouvez écrire votre propre autorisation personnalisée et/ou votre authentification. Je voudrais souligner la différence entre autorisation et authentification. Tout d'abord, l'application doit authentifier l'utilisateur (ou le client api) d'où provient la demande. Une fois l’utilisateur authentifié, en fonction de son identité, l’application doit déterminer quel utilisateur authentifié est autorisé à exécuter certaines applications (autorisation). Pour la plupart des applications Web traditionnelles, le modèle de sécurité n'a pas de granularité fine. Par conséquent, une fois l'utilisateur authentifié, il est également généralement autorisé à effectuer certaines actions. Cependant, ces deux concepts (authentification et autorisation) doivent correspondre à deux opérations logiques différentes.

De plus, dans les applications Web classiques, après authentification et autorisation de l'utilisateur (principalement en recherchant la paire nom d'utilisateur/mot de passe dans la base de données), les informations d'autorisation et d'identité sont écrites dans le stockage de session. Le stockage de session ne doit pas nécessairement être côté serveur, comme le suggèrent la plupart des réponses ci-dessus, il peut également être stocké dans un cookie côté client, crypté dans la plupart des cas. Par exemple, PHP Le cadre CodeIgniter le fait par défaut. Il existe 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 celle stockée. sessionId, qui est ensuite recherché dans le stockage de session côté serveur. De plus, stocker la session côté client est très pratique dans un environnement distribué, car il élimine le besoin de concevoir une solution (ou d'utiliser déjà une solution existante) pour la gestion de session centralisée côté serveur. .

De plus, l'authentification avec une simple paire utilisateur-mot de passe ne doit pas nécessairement se faire dans un code personnalisé qui recherche l'enregistrement correspondant dans la base de données. Il y a par exemple protocole d'authentification de base , ou authentification condensée . Sur les logiciels propriétaires tels que la plate-forme Windows, il existe également des moyens d'authentifier l'abonné utilisateur, par exemple, ActiveDirectory

Fournir une paire nom d'utilisateur/mot de passe n'est pas le seul moyen d'authentifier. Si vous utilisez le protocole HTTPS, vous pouvez également envisager l'authentification à l'aide de certificats numériques .

Dans des cas d'utilisation spécifiques, si vous concevez un service Web, qui utilise SOAP comme protocole, il existe également une extension WS-Security pour SOAP protocole.

Cela étant dit, je dirais que les réponses à la question suivante entrent dans la procédure de décision relative au choix du mécanisme d'autorisation/d'authentification pour WebApi:

1) Quel est le public cible, est-il accessible au public ou réservé aux membres inscrits (payants)?
2) Est-il exécuté ou * NIX, ou la plate-forme MS
3) Quel est le nombre d'utilisateurs attendu
4) Quelle quantité de données sensibles traite avec l'API (mécanismes d'authentification plus forts ou plus faibles)
5) Existe-t-il un service SSO que vous pourriez utiliser?

.. et beaucoup plus.

J'espère que cela efface un peu les choses, car il y a beaucoup de variables dans l'équation.

9
toske

Si l'APP basée sur l'API est un client, cette dernière doit avoir l'option de récupérer/lire les cookies du flux de réponse du serveur et de le stocker. Pour l’ajout automatique de cookies lors de la préparation de l’objet requête pour le même serveur/url. S'il n'est pas disponible, l'identifiant de session ne peut pas être récupéré.

1
Bharath

Je suggérerais que vous envoyiez une sorte de jeton avec chaque demande.

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

1
iga

Vous avez raison, la raison pour laquelle les choses sont "automatiques" dans un environnement standard est que les cookies sont préférables à la propagation d'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 des API, les systèmes simples ne font souvent que transmettre des informations d'authentification à chaque demande (du moins dans mon domaine d'activité). Les auteurs clients sont généralement (encore une fois selon mon expérience) réticents à mettre en œuvre le stockage des cookies et la transmission à chaque demande et généralement plus que le strict minimum ...

Il existe de nombreux autres mécanismes d'authentification pour les API basées sur HTTP, HTTP basique/digest pour en nommer quelques-uns, et bien sûr l'omniprésente o-auth qui est conçu spécifiquement pour ces choses si je ne me trompe pas. Aucun cookie n'est conservé, les identifiants font partie de chaque échange (à peu près sûr).

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 un espace de stockage pour l'utilisateur actuel et stocke généralement de petites quantités de données afin de décharger la base de données de page en page. 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 fait le service.

1
quickshiftin