L'authentification, l'Autorisation et de la Session de la Gestion Traditionnelle des Applications Web et des Api

Corrigez-moi si je me trompe: Dans un cadre traditionnel de l'application web, le navigateur ajoute automatiquement les informations de session dans une demande au serveur, le serveur peut savoir de qui provient la demande. Qu'est-ce exactement est ajouté en fait?

Cependant, dans une API basée sur le app, cette information n'est pas envoyée automatiquement, de sorte que lors du développement d'une API, je dois vérifier moi-même si la demande émane d'un utilisateur authentifié par exemple? Comment est-ce fait normalement?

  • J'espère que vous n'avez pas développé votre précédent applications web sur l'hypothèse que le navigateur va gérer la session correctement.
  • Je ne sais pas si je l'ai fait correctement, mais je suis assez sûr que c'est ok. Auparavant, j'utilise le PHP, donc je viens de vérifier $_SESSION, est ce que le droit? Jusqu'à présent, je trouve qu'il fonctionne bien. Il semble que les navigateurs de la poignée de la session/cookies?
InformationsquelleAutor Jiew Meng | 2012-06-09
  1. 116

    Protocole HTTP est sans état par le design, chaque demande est faite séparément et est exécuté dans un autre contexte.

    L'idée derrière la gestion de session est de mettre les demandes à partir du même client dans le même contexte. Ceci est fait par l'émission d'un identifiant par le serveur et l'envoyer au client, le client permettrait de sauver de cet identifiant et de le renvoyer dans les requêtes suivantes pour que le serveur puisse l'identifier.

    Cookies

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

    • Les Cookies peuvent être gérés par le serveur (création/modification/suppression) à l'aide de la Set-Cookie - tête de réponse HTTP.
    • Les Cookies peuvent être accessibles par le serveur (lire) par l'analyse de la Cookie - tête de requête HTTP.

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

    Sessions

    Retour à des séances, Dans un typique d'un navigateur-serveur cas (encore une fois), gestion de session côté serveur prend avantage du côté client de gestion des cookies. La gestion de session de PHP définit un cookie de session et de les utiliser pour identifier les demandes ultérieures.

    Applications Web API?

    Maintenant, revenons à votre question, puisque vous seriez le responsable de la conception de l'API et de la documentation, la mise en œuvre serait votre décision. En gros, vous avez à

    1. donner au client un identifiant, que ce soit par l'intermédiaire d'un Set-Cookie - tête de réponse HTTP, à l'intérieur du corps de la réponse (XML/JSON auth réponse).
    2. avoir un mécanisme pour maintenir l'identificateur du client/de l'association. par exemple une table de base de données qui associe identificateur 00112233445566778899aabbccddeeff avec le client/utilisateur #1337.
    3. demander au client de renvoyer l'identifiant transmis au (1.) dans toutes les demandes ultérieures, que ce soit dans un HTTP Cookie en-tête de requête, un ?sid=00112233445566778899aabbccddeeff param(*).
    4. de recherche de la réception de l'identifiant, en utilisant le mécanisme (2.), vérifier si une authentification valide, et il est autorisé à faire l'opération demandée, puis de procéder à l'opération au nom de l'auth avais utilisateur.

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

    (*) Chaque méthode a des inconvénients et des avantages, par exemple, à l'aide d'une requête GET param est plus facile à mettre en œuvre, mais peut avoir des implications en matière de sécurité, puisque les demandes sont enregistrées. Vous devez utiliser le protocole https pour les critiques (tous?) des applications.

    • Réponse Parfaite! Merci
    • Pour ajouter un peu plus d'informations pour le lecteur, l'un des aspects les plus importants de la gestion de session, c'est la sécurité. Il ya de nombreux aspects de celle-ci: quels types de jetons à utiliser, combien de révocation de travail, un jeton de la longueur et de l'entropie, et la protection contre les diverses attaques. Aussi, dans le cas où les jetons ne se volés (ce qui est théoriquement toujours possible), comment peut-on détecter une telle activité (voir la rotation de l'actualisation des jetons dans la RFC 6819)? Depuis il m'est impossible d'expliquer toutes mes pensées dans cette section des commentaires, vous pouvez en lire plus sur ce sujet ici: medium.com/@supertokens.io/ee5245e6bdad
    InformationsquelleAutor aularon
  2. 45

    La gestion de session du serveur est en responsabilité. 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 que, dans les prochaines demandes entre le client et le serveur, le client envoie le jeton (en général) comme un cookie HTTP. Toutes les données de session est stocké sur le serveur, le client n'enregistre que le jeton. Par exemple, pour démarrer une session en PHP, vous avez juste besoin d':

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

    Après la session est créée, vous pouvez enregistrer des données. 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;

    Maintenant, vous êtes en mesure de 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 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;
}
    InformationsquelleAutor Guilherme Torres Castro
  3. 9

    Il y a de nombreuses façon authentique utilisateurs, à la fois pour les applications Web et des Api. Il y a le couple de normes, ou vous pouvez écrire votre propre autorisation et /ou d'authentification. Je tiens à souligner la différence entre l'autorisation et l'authentification. D'abord, l'application doit authentifier l'utilisateur(ou client api) que la demande vient d'. Une fois que l'utilisateur a été authentifié, basée sur l'identité de l'utilisateur de l'application doit déterminer quelle que soit authentifié l'utilisateur a l'autorisation d'exercer certaines application (autorisation). Pour la plupart, les applications web traditionnelles, il n'y a pas de fine granularité dans le modèle de sécurité, donc une fois que l'utilisateur est authentifié, il est dans la plupart des cas, et autorisé à effectuer une certaine action. Cependant, ces deux concepts (authentification et autorisation) doit être comme deux logiques différentes opérations.

    De plus, dans le cas classique d'applications web, après que l'utilisateur a été authentifié et autorisé
    (surtout par la recherche de nom d'utilisateur/mot de passe dans la base de données), de l'autorisation et de l'identité de l'info est écrit dans le stockage de session. Stockage de Session n'a pas à être côté serveur, comme la plupart des réponses ci-dessus le suggèrent, il pourrait également être stockées dans le cookie sur le côté client, chiffré dans la plupart des cas. Pour un exemple, PHP CodeIgniter framework fait par défaut. Il y a nombre de mécanisme de protection de la session côté client, et je ne vois pas ce mode de stockage des données de session moins en sécurité que de stocker les id de session, qui est alors recherché dans le stockage de session sur le serveur-côté. Aussi, le stockage de session côté client est très pratique en environnement distribué, car il élimine le besoin pour la conception de la solution (ou à l'aide de déjà existant) pour le centre de gestion de session côté serveur.

    De plus, l'authentification avec simple utilisateur-mot de passe ne doit pas être dans tous les cas grâce à un code personnalisé qui regarde la correspondance de l'utilisateur-enregistrement dans la base de données. Il est, par exemple l'authentification de base du protocole , ou l'authentification digest. Sur des logiciels propriétaires comme plate-forme Windows, il existe également des moyens d'authentification d'un utilisateur d'auge, pour un exemple,ActiveDirectory

    Fournir de nom d'utilisateur/mot de passe n'est pas la seule façon de s'authentifier, si vous utilisez le protocole HTTPS, vous pouvez aussi envisager d'authentification à l'aide de certificats numériques.

    En cas d'utilisation spécifiques, si la conception du service web, qui utilise du SAVON, du protocole, il est également WS-Security extension pour le protocole SOAP.

    Avec tous ces dit, je dirais que les réponses à la question suivante entrer procédure de décision pour le choix de l'autorisation/mécanisme d'authentification pour WebApi:

    1) Quel est le public ciblé, est à la disposition du public, ou pour les inscrits(payant) pour les membres seulement?

    2) Est-il courir ou *NIX, ou MME de la plateforme

    3) Quel est le nombre d'utilisateurs devrait

    4) Quelle quantité de données sensibles de l'API traite (plus fort vs faible mécanismes d'authentification)

    5) Est-il un service d'authentification unique que vous pouvez utiliser

    .. et beaucoup plus.

    Espère que cela efface peu de choses, car il ya beaucoup de variables dans l'équation.

    InformationsquelleAutor toske
  4. 1

    Si l'API APPLICATION est un Client, l'API doit avoir la possibilité de récupérer/lire les cookies de réponse du serveur de flux et de les stocker. Pour automatique ajoutant des cookies lors de la préparation de la demande d'objets de même serveur/url. Si elle n'est pas disponible, l'id de session ne peuvent pas être récupérées.

    InformationsquelleAutor Bharath
  5. 1

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

    Dans l'API monde, les systèmes simples souvent juste avoir des informations d'authentification transmis avec chaque demande (au moins dans ma ligne de travail). Client auteurs sont généralement (encore une fois dans mon expérience), réticents à mettre en œuvre cookie de stockage et de transmission de chaque demande et généralement rien de plus que le strict minimum...

    Il ya beaucoup d'autres mécanismes d'authentification pour HTTP Api HTTP de base /digest pour n'en nommer que deux, et bien sûr de l'omniprésent o-auth, qui est conçu spécifiquement pour ces choses, si je ne me trompe pas. Les cookies ne sont pas entretenues, les informations d'identification sont une partie de chaque échange (assez sûrs).

    L'autre chose à considérer est ce que vous allez faire w/la session sur le serveur dans une API. La session sur un site web fournit un espace de stockage pour l'utilisateur actuel, et, généralement, les magasins de petites quantités de données à prendre en charge hors de la db à partir de la page à page. Dans une API contexte c'est de moins en moins besoin que les choses sont plus ou moins apatrides, parlant généralement de cours; cela dépend vraiment de ce que le service est en train de faire.

    InformationsquelleAutor quickshiftin
  6. 1

    Je vous suggère d'envoyer un type de jeton à chaque requête.

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

    InformationsquelleAutor iga