He leído sobre autenticaciones y me confundo acerca de la clasificación de tipos.

Comencemos con la autenticación basada en cookies. Si lo entiendo bien, el punto clave es que todos los datos, necesarios para la autenticación del usuario, se almacenan en cookies. Y esta es mi primera confusión: en las cookies podemos almacenar

• id de sesión y se convierte en una autenticación basada en sesión?
• reclamaciones, y entonces ¿debería llamarse como una autenticación basada en reclamaciones?
• Descubrí que algunas personas incluso almacenan el token JWT en cookies, pero esto parece una implementación personalizada del propio flujo de autenticación ...

Ahora pasemos a la autenticación basada en notificaciones. El elemento principal es el reclamo y la colección de reclamos podría usarse como contenedor

• cookies (como se discutió anteriormente)
• token (JWT como el ejemplo).

Por otro lado, cuando hablamos del token, puede contener cualquier tipo de información ... ID de sesión, por ejemplo ...

Entonces, ¿qué me he perdido? ¿Por qué las personas no definen algo como Cookie-Session-basedo Token-Claims-basedautenticaciones cuando hablan de tipos de autenticación?

Estoy de acuerdo en que nombrar los diferentes conceptos es confuso. Cuando se habla de autenticación en un contexto web, hay varios aspectos a considerar.

¿Qué información envía el cliente cuando se autentica?

• Una identificación de sesión . Esto significa que el servidor tiene un almacenamiento de sesión que contiene las sesiones activas. Las sesiones tienen estado en el lado del servidor.
• Un conjunto de reclamos . Las reclamaciones contienen información sobre qué operaciones puede realizar el cliente. El servidor no realiza un seguimiento de cada cliente autenticado, pero confía en las reclamaciones. Las reclamaciones generalmente no tienen estado en el lado del servidor.

¿Cómo envía el cliente la información de autenticación?

• Las cookies . Los navegadores envían cookies automáticamente con cada solicitud, después de que se haya configurado la cookie. Las cookies son vulnerables a XSRF.
• Otras cabeceras . Normalmente, el encabezado de autorización se utiliza para esto. El navegador no envía estos encabezados automáticamente, sino que el cliente debe establecerlos. Esto es vulnerable a XSS.
• Solicitar url . La información de autenticación se incluye en la URL. Esto no se usa comúnmente.

¿Cuál es el formato de la información de autenticación?

• Texto sin signo y sin formato . Esto se puede usar para identificadores de sesión. Por lo general, el cliente no puede adivinar un ID de sesión, por lo que el servidor puede confiar en que el cliente no lo ha falsificado.
• Json Web Token . Los JWT están firmados criptográficamente y contienen información de caducidad. El cliente generalmente puede decodificar el token, pero no puede alterarlo sin que el servidor lo note.
• Cualquier otro formato firmado . Igual que los JWT. Lo importante es la firma criptográfica, que evita que el cliente altere los datos.

Bonificación: ¿Cómo almacena el cliente la información localmente?

• Las cookies . Por supuesto, este es el caso cuando se utilizan cookies para transmitir la información. Pero las cookies también se pueden usar como un mecanismo de almacenamiento del lado del cliente. Esto requiere que la cookie sea legible desde scripts para ser útil. Por ejemplo, un cliente podría leer la cookie con JavaScript y enviar la información con un encabezado de autorización.
• Almacenaje local . Este suele ser el único método posible, si las cookies no están disponibles. Requiere gestión con JavaScript.

¿Qué quieren decir las personas cuando dicen ...

• "Autenticación basada en cookies" . Creo que esto generalmente significa "Id. De sesión, enviar por cookie, posible como texto sin formato".
• "Autenticación basada en token" . Por lo general, esto significa "Reclamaciones, envíe utilizando el encabezado de autenticación, codificado como un Json Web Token".
• "Autenticación basada en reclamos" . Podría ser cualquier cosa menos una identificación de sesión.

Simplemente pon,

1. Autenticación basada en cookies

   • El cliente web (por ejemplo: navegador web) almacena la cookie enviada por el servidor web después de una autenticación exitosa.
   • La cookie contiene información sobre el usuario, el cliente, la marca de tiempo de authN y otros datos útiles con una identificación única para determinar la cookie.
   • Típicamente, la cookie es encriptada por el servidor web con el conjunto de atributos de dominio (por ejemplo:) google.comy la envía al cliente web.
   • Cada vez que el cliente web quiera acceder al recurso de dominio (por ejemplo:) mail.google.com, enviará todas las cookies basadas en su dominio (por ejemplo google.com:) al servidor web, que valida / verifica y otorga / niega el acceso según el estado y la marca de tiempo de La galleta.

2. Autenticación basada en sesión

   • Junto con la cookie del cliente web, si un servidor web almacena los datos de autenticación del usuario en su back-end, se llamará autenticación basada en sesión.
   • Esto es muy útil en el caso de que el cliente web tenga acceso al sistema donde no debería tener acceso, luego, desde el back-end, el administrador puede revocar la sesión del cliente web.

3. Autenticación basada en tokens

   • En general, esto se usa en escenarios que no son de cliente web, donde no hay forma de almacenar cookies en el lado del cliente.
   • Por lo tanto, el servidor web envía el token firmado (contiene información sobre el usuario, el cliente, la marca de tiempo de authN y otros datos útiles con identificación única) al cliente después de una autenticación exitosa.
   • Siempre que un cliente quiera acceder a un recurso, debe enviar este token y el servidor web valida / verifica el token antes de permitir el acceso al recurso.

4. Autenticación basada en reclamos

   • Esto es lo mismo que la autenticación basada en tokens, solo que agrega algunos datos más al token sobre el cliente y / o usuario asociado al cliente.
   • Estos datos pertenecen a la autorización, que habla sobre lo que el cliente debe hacer dentro del recurso (por ejemplo: mail.read, mail.delete, calendar.read).