Haz todo lo posible por comprender el código bien previamente a usarlo a tu proyecto y si ttienes algo que aportar puedes comentarlo.
Solución:
Estaba leyendo un artículo el otro día de Taiseer Joudeh y lo encuentro muy útil, dijo:
En mi opinión, hay tres beneficios principales de usar tokens de actualización, que son:
-
Actualización del contenido del token de acceso: como sabe, los tokens de acceso son tokens autónomos, contienen todas las reclamaciones (información) sobre el usuario autenticado una vez que se generan, ahora si emitimos un token de larga duración (1 mes por ejemplo) para un usuario llamado “Alex” y lo inscribió en el rol “Usuarios”, entonces esta información se incluye en el token que generó el servidor de autorización. Si decidió más tarde (2 días después de que obtuvo el token) agregarlo al rol de “Administrador”, entonces no hay forma de actualizar esta información contenida en el token generado, debe pedirle que se vuelva a autenticar. por lo que el servidor de autorización agrega esta información a este token de acceso recién generado, y esto no es factible en la mayoría de los casos. Es posible que no pueda llegar a los usuarios que obtuvieron tokens de acceso de larga duración. Entonces, para superar este problema, necesitamos emitir tokens de acceso de corta duración (30 minutos por ejemplo) y usar el token de actualización para obtener un nuevo token de acceso, una vez que obtenga el nuevo token de acceso, el servidor de autorización podrá agregar un nuevo reclamo para el usuario. “Alex”, que le asigna el rol de “Administrador” una vez que se genera el nuevo token de acceso.
-
Revocación del acceso de usuarios autenticados: una vez que el usuario obtiene token de acceso Podrá acceder a los recursos del servidor siempre que su token de acceso no esté vencido, no hay una forma estándar de revocar los tokens de acceso a menos que el servidor de autorización implemente una lógica personalizada que lo obligue a almacenar el token de acceso generado en la base de datos y realizar comprobaciones en la base de datos. con cada solicitud. Pero con los tokens de actualización, un administrador del sistema puede revocar el acceso simplemente eliminando el identificador del token de actualización de la base de datos, por lo que una vez que el sistema solicita un nuevo token de acceso utilizando el token de actualización eliminado, el servidor de autorización rechazará esta solicitud porque el token de actualización ya no está disponible. (Entraremos en esto con más detalles).
-
No es necesario almacenar o solicitar nombre de usuario y contraseña: el uso de tokens de actualización le permite solicitar al usuario su nombre de usuario y contraseña solo una vez una vez que se autentica por primera vez, luego el servidor de autorización puede emitir un token de actualización de larga duración (1 año para ejemplo) y el usuario permanecerá conectado durante todo este período a menos que el administrador del sistema intente revocar el token de actualización. Puede pensar en esto como una forma de acceder sin conexión a los recursos del servidor, esto puede ser útil si está creando una API que será consumida por la aplicación frontal donde no es factible seguir pidiendo nombre de usuario / contraseña con frecuencia.
Me gustaría agregar a esto otra perspectiva.
Autenticación sin estado sin golpear la base de datos en cada solicitud
Supongamos que desea crear un mecanismo de seguridad sin estado (sin sesión) que pueda realizar la autenticación de millones de usuarios, sin tener que realizar una llamada a la base de datos para realizar la autenticación. Con todo el tráfico que recibe su aplicación, ¡vale la pena guardar una llamada DB en cada solicitud! Y debe ser sin estado para que pueda agruparse fácilmente y escalar a cientos o incluso miles de servidores.
Con sesiones pasadas de moda, el usuario inicia sesión, momento en el que leemos su información de usuario de la base de datos. Para evitar tener que leerlo una y otra vez lo almacenamos en una sesión (generalmente en la memoria o en algún caché agrupado). Enviamos el ID de sesión al cliente en una cookie, que se adjunta a todas las solicitudes posteriores. En solicitudes posteriores, usamos el ID de sesión para buscar la sesión, que a su vez contiene la información del usuario.
Ponga la información del usuario directamente en el token de acceso
Pero no queremos sesiones. Entonces, en lugar de almacenar la información del usuario en la sesión, simplemente pongámosla en un token de acceso. Firmamos el token para que nadie pueda manipularlo y listo. Podemos autenticar solicitudes sin una sesión y sin tener que buscar la información del usuario en la base de datos para cada solicitud.
Sin sesión … ¿No hay forma de prohibir a los usuarios?
Pero no tener una sesión tiene una gran desventaja. ¿Qué pasa si este usuario está baneado, por ejemplo? En el escenario anterior, simplemente eliminamos su sesión. Luego tiene que iniciar sesión nuevamente, lo que no podrá hacer. Prohibición completada. Pero en el nuevo escenario no hay sesión. Entonces, ¿cómo podemos prohibirlo? Tendríamos que pedirle (muy amablemente) que retire su token de acceso. ¿Comprueba cada solicitud entrante con una lista de prohibiciones? Sí, funcionaría, pero ahora nuevamente tenemos que hacer esa llamada DB que no queremos.
Compromiso con tokens de corta duración
Si creemos que es aceptable que un usuario aún pueda usar su cuenta durante, digamos, 10 minutos después de haber sido baneado, podemos crear una situación que sea un compromiso entre verificar la base de datos en cada solicitud y solo al iniciar sesión. Y ahí es donde entran los tokens de actualización. Nos permiten usar un mecanismo sin estado con tokens de acceso de corta duración. No podemos revocar estos tokens ya que no se realiza ninguna verificación de la base de datos para ellos. Solo verificamos su fecha de vencimiento con la hora actual. Pero una vez que expiren, el usuario deberá proporcionar el token de actualización para obtener un nuevo token de acceso. En este punto, verificamos la base de datos y vemos que el usuario ha sido baneado. Por lo tanto, denegamos la solicitud de un token de acceso y la prohibición entra en vigencia.
La respuesta a la que se hace referencia (a través de @Anders) es útil, dice:
En caso de compromiso, la ventana de tiempo para la que es válido es limitada, pero los tokens se utilizan a través de SSL, por lo que es poco probable que se vean comprometidos.
Creo que la parte importante es que los tokens de acceso a menudo se registran (especialmente cuando se usan como un parámetro de consulta, lo cual es útil para JSONP), por lo que es mejor que sean de corta duración.
Hay algunas razones adicionales, con implementaciones a gran escala de OAuth 2.0 por parte de los proveedores de servicios:
-
Los servidores API pueden validar de forma segura los tokens de acceso sin búsquedas de bases de datos o llamadas RPC si está bien no preocuparse por la revocación. Esto puede tener grandes beneficios de rendimiento y reducir la complejidad de los servidores API. Mejor si está de acuerdo con una revocación de token de 30 a 60 m (o cualquiera que sea la longitud del token de acceso). Por supuesto, los servidores API también podrían mantener una lista en memoria de tokens revocados en la última hora.
-
Dado que los tokens pueden tener múltiples alcances con acceso a múltiples servicios API diferentes, tener tokens de acceso de corta duración evita que un desarrollador del servicio API obtenga un acceso de por vida a los datos de un usuario en el servicio API B. La compartimentación es buena para la seguridad.
Puntuaciones y comentarios
Eres capaz de defender nuestro estudio escribiendo un comentario y dejando una puntuación te damos las gracias.