J'ai lu des informations sur les authentifications et je suis devenu déroutant sur la classification des types.

Commençons par l'authentification basée sur les cookies, si je comprends bien, le point clé est que toutes les données, nécessaires à l'authentification des utilisateurs, sont stockées dans des cookies. Et ceci est ma première confusion: dans les cookies, nous pouvons stocker

• identifiant de session et donc il devient une authentification basée sur la session?
• et doit-il donc être appelé en tant qu'authentification basée sur les revendications?
• J'ai constaté que certaines personnes stockent même des jetons JWT dans des cookies, mais cela semble être une implémentation personnalisée de leur propre flux d'authentification ...

Passons maintenant à l'authentification basée sur les revendications. L'élément principal est la revendication et la collection de revendications pourrait servir de conteneur

• cookies (comme discuté ci-dessus)
• jeton (JWT comme exemple).

De l'autre côté, lorsque nous parlons du jeton, il peut contenir tout type d'informations ... ID de session par exemple ...

Alors qu'est-ce que j'ai raté? Pourquoi les gens ne définissent-ils pas quelque chose comme Cookie-Session-basedou des Token-Claims-basedauthentifications lorsqu'ils parlent de types d'authentification?

Je suis d'accord que la dénomination des différents concepts prête à confusion. Lorsque l'on parle d'authentification dans un contexte Web, il y a plusieurs aspects à considérer.

Quelles informations le client envoie-t-il lors de l'authentification?

• Un identifiant de session . Cela signifie que le serveur dispose d'un stockage de session qui contient les sessions actives. Les sessions sont avec état côté serveur.
• Un ensemble de revendications . Les réclamations contiennent des informations sur les opérations que le client peut effectuer. Le serveur ne garde pas trace de chaque client authentifié, mais approuve les revendications. Les revendications sont généralement sans état côté serveur.

Comment le client envoie-t-il les informations d'authentification?

• Cookies . Les navigateurs envoient automatiquement des cookies à chaque demande, une fois le cookie installé. Les cookies sont vulnérables à XSRF.
• Autres en-têtes . En général, l'en-tête d'autorisation est utilisé pour cela. Ces en-têtes ne sont pas envoyés automatiquement par le navigateur, mais doivent être définis par le client. Ceci est vulnérable à XSS.
• Demander l'URL . Les informations d'authentification sont incluses dans l'URL. Ce n'est pas couramment utilisé.

Quel est le format des informations d'authentification?

• Texte clair et non signé . Cela peut être utilisé pour les identifiants de session. Un identifiant de session n'est généralement pas devinable par le client, le serveur peut donc être sûr que le client ne l'a pas falsifié.
• Jeton Web Json . Les JWT sont signés cryptographiquement et contiennent des informations d'expiration. Le client peut généralement décoder le jeton, mais ne peut pas le modifier sans que le serveur ne s'en aperçoive.
• Tout autre format signé . Identique aux JWT. L'important est la signature cryptographique, qui empêche le client de modifier les données.

Bonus: Comment le client stocke-t-il les informations localement

• Cookies . C'est bien sûr le cas lors de l'utilisation de cookies pour transmettre les informations. Mais les cookies peuvent également être utilisés comme un simple mécanisme de stockage côté client. Cela nécessite que le cookie soit lisible à partir des scripts pour être utile. Par exemple, un client pourrait lire le cookie avec JavaScript et envoyer les informations avec un en-tête d'autorisation.
• Stockage local . C'est souvent la seule méthode possible, si les cookies ne sont pas disponibles. Nécessite une gestion avec JavaScript.

Que veulent dire les gens quand ils disent ...

• "Authentification basée sur les cookies" . Je trouve que cela signifie généralement «Identifiant de session, envoyer par cookie, possible en texte brut».
• "Authentification basée sur des jetons" . Habituellement, cela signifie «Revendications, envoyer à l'aide de l'en-tête d'authentification, codé en tant que jeton Web Json».
• "Authentification basée sur les revendications" . Peut être autre chose qu'un identifiant de session.

Tout simplement,

1. Authentification basée sur les cookies

   • Le client Web (par exemple: navigateur Web) stocke les cookies envoyés par le serveur Web après une authentification réussie.
   • Le cookie contient des informations sur l'utilisateur, le client, l'horodatage authN et d'autres données utiles avec un identifiant unique pour déterminer le cookie.
   • En règle générale, le cookie est chiffré par le serveur Web avec un ensemble d'attributs de domaine (par exemple google.com:) et il est envoyé au client Web.
   • Chaque fois que le client Web veut accéder à la ressource de domaine (par exemple:) mail.google.com, il enverra tous les cookies basés sur son domaine (par exemple google.com:) au serveur Web, qui valide / vérifie et accorde / refuse l'accès en fonction de l'état et de l'horodatage de le cookie.

2. Authentification basée sur la session

   • Avec le cookie du client Web, si un serveur Web stocke les données d'authentification de l'utilisateur dans son serveur principal, il sera appelé authentification basée sur la session.
   • Ceci est très utile en cas de violation par laquelle le client Web a accédé au système où il ne devrait pas y avoir accès, puis depuis le back-end, la session du client Web peut être révoquée par l'administrateur.

3. Authentification basée sur les jetons

   • Généralement, cela est utilisé dans des scénarios non client Web, où il n'y a aucun moyen de stocker des cookies côté client.
   • Par conséquent, le serveur Web envoie le jeton signé (contient des informations sur l'utilisateur, le client, l'horodatage authN et d'autres données utiles avec un identifiant unique) au client après une authentification réussie.
   • Chaque fois qu'un client souhaite accéder à une ressource, il doit envoyer ce jeton et le serveur Web valide / vérifie le jeton avant d'autoriser l'accès à la ressource.

4. Authentification basée sur les revendications

   • C'est la même chose que l'authentification basée sur des jetons, mais seulement en ajoutant plus de données dans le jeton sur le client et / ou l'utilisateur associé au client.
   • Ces données sont relatives à l'autorisation, qui décrit ce que le client doit faire au sein de la ressource (par exemple: mail.read, mail.delete, calendar.read).