2009-10-20 19 views
367

Quiero entender qué significa autenticación basada en tokens. Busqué en Internet pero no pude encontrar nada comprensible.¿Qué es la autenticación basada en token?

+13

He leído muchas descripciones, pero todas parecían ligeras en detalles concretos. Este artículo finalmente me ayudó: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token –

Respuesta

68

A token es un dato que solo Server X pudo haber creado y que contiene datos suficientes para identificar a un usuario en particular.

Puede presentar su información de inicio de sesión y preguntar Server X por un token; y luego puede presentar su token y solicitar Server X para realizar alguna acción específica del usuario.

Token s se crean utilizando diversas combinaciones de diversas técnicas del campo de la criptografía, así como con la entrada del campo más amplio de la investigación de seguridad. Si decide ir y crear su propio sistema token, será mejor que sea realmente inteligente.

+4

Generalmente, si quieres la autenticación basada en token, debes comenzar con OAuth. –

+4

OAuth es ciertamente viable en una aplicación basada en web.Pero, por ejemplo, las sesiones de inicio de sesión del sistema operativo también usan sistemas token, al igual que muchos otros tipos de programas de software, por lo que esta idea no se limita a la Web. – yfeldblum

+1

Un token probablemente también sea preferible para un sistema de soporte al cliente no público. La empresa controla el nombre de usuario/contraseña y emite y controla el token. – KevinManx

417

creo que es bien explicado here - citar sólo las frases clave del largo artículo:

El concepto general detrás de un sistema de autenticación basada en token es sencilla. Permitir a los usuarios ingresar su nombre de usuario y contraseña para obtener un token que les permita obtener un recurso específico - sin usando su nombre de usuario y contraseña. Una vez que se ha obtenido su token, , el usuario puede ofrecer el token, que ofrece acceso a un recurso específico durante un período de tiempo - al sitio remoto .

En otras palabras: añadir una nivel de indirección para la autenticación - en lugar de tener que autenticarse con nombre de usuario y contraseña para cada recurso protegido, el usuario se autentica de esa manera una vez (dentro de una sesión de duración limitada), se obtiene una token de tiempo limitado a cambio, y utiliza ese token para una mayor autenticación durante la sesión.

Las ventajas son muchas, por ejemplo, el usuario podría pasar el token, una vez que lo haya obtenido, a otro sistema automatizado en el que esté dispuesto a confiar por un tiempo limitado y un conjunto limitado de recursos, pero sería no esté dispuesto a confiar con su nombre de usuario y contraseña (es decir, con cada recurso al que tienen permitido acceder, para siempre o al menos hasta que cambien su contraseña).

Si algo aún no está claro, por favor edite su pregunta para aclarar QUÉ no está 100% claro para usted, y estoy seguro de que podemos ayudarlo más.

+1

¿Estoy en lo cierto al pensar que en una aplicación web, una (o más) cookies del sitio web remoto realiza la función del token? – AJP

+0

Del artículo W3 al que hizo referencia: "La autenticación web típica está basada en cookies ..." – AJP

+0

@Alex Martelli hola, si la conexión ha terminado HTTPS hace una diferencia al enviar el token como parámetro o en el encabezado? – Spring

35

Un token es un dato creado por el servidor y contiene información para identificar un usuario en particular y validez de token. El token contendrá la información del usuario, así como un código de token especial que el usuario puede pasar al servidor con cada método que admita la autenticación, en lugar de pasar un nombre de usuario y contraseña directamente.

La autenticación basada en tokens es una técnica de seguridad que autentica a los usuarios que intentan iniciar sesión en un servidor, una red u otro sistema seguro utilizando un token de seguridad proporcionado por el servidor.

Una autenticación es exitosa si un usuario puede demostrarle a un servidor que es un usuario válido pasando un token de seguridad. El servicio valida el token de seguridad y procesa la solicitud del usuario.

Tras el token es validado por el servicio, que se utiliza para establecer el contexto de seguridad para el cliente, por lo que el servicio puede tomar decisiones de autorización o actividad de auditoría de las peticiones del usuario sucesivos.

visit the source

125

De Auth0.com

basada en token de autenticación, depende de un token firmados que se envía a el servidor en cada solicitud.

¿Cuáles son los beneficios de utilizar un enfoque basado en token?

  • entre dominios/CORS: galletas + CORS no juegan bien a través de diferentes dominios. Un enfoque basado en token le permite hacer llamadas AJAX a cualquier servidor, en cualquier dominio porque utiliza una cabecera HTTP para transmitir la información del usuario.

  • sin estado (también denominado escalabilidad lado del servidor): no hay necesidad de mantener un almacenamiento de sesión, el token es una entidad independiente que transmite toda la información del usuario. El resto del estado vive en cookies o en el almacenamiento local en el lado del cliente.

  • CDN: puede servir a todos los activos de su aplicación desde un CDN (por ejemplo Javascript, HTML, imágenes, etc.), y el lado del servidor es sólo la API.

  • Desacoplamiento: no está vinculado a ningún esquema de autenticación particular. El token se podría generar en cualquier lugar, por lo tanto, su API puede ser llamado desde cualquier lugar con una única manera de autenticar esos llamadas.

  • listo móvil: Cuando comience a trabajar en una plataforma nativa (iOS, Android, Windows 8, etc.) las cookies no son ideales cuando se consume una aproximación basada en token simplifica mucho esto.

  • CSRF: ya que no está confiando en las cookies, no es necesario para proteger contra las peticiones de sitios cruzados (por ejemplo, no sería posible sib su sitio, generar una solicitud POST y volver a utilizar el cookie de autenticación existente porque no habrá ninguna).

  • Rendimiento: no estamos presentando cualquier punto de referencia duro Potencia aquí, pero una ida y vuelta de red (por ejemplo, la búsqueda de una sesión en la base de datos) es probable que tome más tiempo que el cálculo de un HMACSHA256 a validar un token y analizar su contenido.

+2

@Asik Todos los puntos son válidos salvo "sin estado" cuando se inicia frente a la revocación modo, las listas negras, etc. responder prevención de ataques – svlada

+0

El sitio citado recomienda un artículo reciente sobre el mismo tema: https://auth0.com/blog/ cookies-vs-tokens-definititive-guide/ – ASalazar

+0

'apatridia' y 'rendimiento' se mantiene siempre que no necesite 'inmediatamente' revocar el token. De lo contrario, al menos se necesita un acceso de base de datos por llamada de API. –

2

Es sólo una cadena de número predefinido de caracteres que se asocia con el usuario en la base de datos o de alguna otra manera. Esa ficha se puede utilizar para autorizar a un usuario acceder a otros contenidos relacionados de la aplicación. Para recuperar este token en el lado del cliente, se requiere iniciar sesión.Después de iniciar sesión por primera vez, debe guardar el token recuperado, no cualquier otro dato, como la identificación de la sesión o la sesión, ya que aquí todo es un token para acceder a otros recursos de la aplicación.

Token se utiliza para asegurar la autenticidad del usuario.

13

La cuestión es vieja y la tecnología ha avanzado, aquí es el estado actual:

web JSON Token (JWT) es un estándar abierto basado en JSON (RFC 7519) para pasar notificaciones entre las partes en el entorno de aplicaciones web . Los tokens están diseñados para ser compactos, seguros para URL y utilizables especialmente en el contexto de inicio de sesión único (SSO) del navegador web.

https://en.wikipedia.org/wiki/JSON_Web_Token

0

Al registrarse en una nueva página web, que a menudo reciben un correo electrónico para activar su cuenta. Ese correo electrónico generalmente contiene un enlace para hacer clic en. Parte de ese enlace contiene un token, el servidor conoce este token y puede asociarlo con su cuenta. El token normalmente tiene una fecha de caducidad asociada, por lo que solo tendrá una hora para hacer clic en el vínculo y activar su cuenta. Nada de esto sería posible con cookies o variables de sesión, ya que se desconoce qué dispositivo o navegador utiliza el cliente para revisar los correos electrónicos.

+2

token/link de un solo uso es un concepto diferente a la autenticación basada en token. –

2

simbólico basado en (autenticación/seguridad)

significa que el fin para nosotros demostramos que hemos de acceso, primero tenemos que recibir el token. En un escenario de la vida real, el token podría ser una tarjeta de acceso para la construcción, podría ser la clave del bloqueo de su casa. Para que pueda recuperar una tarjeta llave para su oficina o la llave de su casa, primero debe probar quién es, y que de hecho tiene acceso a esa ficha. Podría ser algo tan simple como mostrarle a alguien su identificación o darles una contraseña secreta. Entonces imagina que necesito tener acceso a mi oficina. Voy a la oficina de seguridad, les muestro mi identificación y me dan esta ficha, lo que me permite entrar al edificio. Ahora tengo acceso irrestricto para hacer lo que quiera dentro del edificio, siempre que tenga mi token conmigo.

¿Cuál es el beneficio de la seguridad basada en token?

Si pensamos en la insegura API, lo que teníamos que hacer en ese caso era que teníamos que proporcionar nuestra contraseña para todo lo que queríamos hacer.

Imagine que cada vez que ingresemos a una puerta en nuestra oficina, tenemos que darles a todos sentados junto a la puerta nuestra contraseña. Ahora eso sería bastante malo, porque eso significa que cualquier persona dentro de nuestra oficina podría tomar nuestra contraseña y hacerse pasar por nosotros, y eso es bastante malo. En cambio, lo que hacemos es recuperar el token, por supuesto junto con la contraseña, pero lo recuperamos de una persona. Y luego podemos usar esta ficha donde queramos dentro del edificio. Por supuesto, si perdemos el token, tenemos el mismo problema que si alguien más conociera nuestra contraseña, pero eso nos lleva a cosas como ¿cómo nos aseguramos de que si perdemos el token, podemos revocar el acceso, y tal vez el token? no debe vivir más de 24 horas, por lo que al día siguiente que vengamos a la oficina, tenemos que mostrar nuestra identificación de nuevo. Pero aún así, solo hay una persona a quien le mostramos la identificación, y ese es el guardia de seguridad sentado donde recuperamos los tokens.

Cuestiones relacionadas