¿Por qué OAuth v2 tiene tokens de acceso y actualización?


654

La sección 4.2 del borrador del protocolo OAuth 2.0 indica que un servidor de autorización puede devolver tanto un access_token(que se utiliza para autenticarse con un recurso) como un refresh_token, que se utiliza únicamente para crear un nuevo access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

¿Por qué tener ambos? ¿Por qué no simplemente hacer el access_tokenúltimo tanto tiempo como el refresh_tokeny no tener un refresh_token?

Respuestas:


463

La idea de los tokens de actualización es que si un token de acceso se ve comprometido, ya que es de corta duración, el atacante tiene una ventana limitada para abusar de él.

Los tokens de actualización, si se ven comprometidos, son inútiles porque el atacante requiere la identificación y el secreto del cliente además del token de actualización para obtener un token de acceso.

Dicho esto , debido a que cada llamada al servidor de autorización y al servidor de recursos se realiza a través de SSL, incluida la identificación del cliente original y el secreto cuando solicitan los tokens de acceso / actualización, no estoy seguro de cómo es el token de acceso ". comprometible "que el token de actualización de larga duración y la combinación clientid / secret

Esto, por supuesto, es diferente a las implementaciones en las que no controlas tanto la autorización como los servidores de recursos.

Aquí hay un buen hilo que habla sobre los usos de los tokens de actualización: OAuth Archives .

Una cita de lo anterior, que habla sobre los propósitos de seguridad del token de actualización:

Actualizar tokens ... mitiga el riesgo de una fuga de access_token de larga duración (parámetro de consulta en un archivo de registro en un servidor de recursos inseguro, beta o aplicación de servidor de recursos mal codificada, cliente JS SDK en un sitio no https que coloca el access_token en un galleta, etc.)


14
Catchdave tiene razón, pero pensé que agregaría que las cosas han evolucionado desde su respuesta inicial. El uso de SSL ahora es opcional (esto probablemente todavía se estaba debatiendo cuando catchdave respondió). Por ejemplo, los tokens MAC (actualmente en desarrollo) proporcionan la capacidad de firmar la solicitud con una clave privada para que no se requiera SSL. Los tokens de actualización se vuelven muy importantes, ya que desea tener tokens mac de corta duración.
AlexGad

54
"Los tokens de actualización, si se ven comprometidos, son inútiles porque el atacante requiere la identificación y el secreto del cliente además del token de actualización para obtener un token de acceso". Pero la identificación y el secreto del cliente también se almacenan en el dispositivo, ¿no? Entonces, un atacante con acceso al dispositivo puede obtenerlos. ¿Entonces por qué? Aquí, github.com/auth0/lock/wiki/Using-a-Refresh-Token , está escrito que perder un token de actualización significa que puede solicitar tantos tokens de autenticación como quiera, puede que no esté en el escenario de Google, pero ¿Qué pasa si estoy implementando mi propio servidor oauth2?
Jamsheed Kamarudeen

42
"El atacante requiere la identificación y el secreto del cliente además del token de actualización para obtener un token de acceso" : entonces, ¿cuál es la diferencia entre usar un token de actualización y simplemente renunciar?
sp00m

34
El token de actualización puede ser utilizado por un tercero que puede renovar el token de acceso sin ningún conocimiento de las credenciales del usuario.
Marek Dic

27
@KevinWheeler No, el ID de cliente y el secreto son credenciales para el cliente OAuth, no para el usuario. Cuando se habla de OAuth, el "cliente" suele ser un servidor (por ejemplo, el servidor web stackoverflow) que interactúa con un servidor de autorización o API de recursos (por ejemplo, el proveedor de autenticación de Facebook). Las credenciales del usuario solo se pasan entre el usuario y el servidor API de OAuth, y el cliente nunca las conoce. El secreto del cliente solo se pasa del cliente al servidor API de OAuth, y el usuario nunca lo conoce.
máquina anhelando

551

El enlace a la discusión, proporcionado por Catchdave, tiene otro punto válido (original, enlace muerto) hecho por Dick Hardt, que creo que vale la pena mencionar aquí además de lo que se ha escrito anteriormente:

Mi recuerdo de tokens de actualización fue por seguridad y revocación. <...>

revocación: si el token de acceso es autónomo, la autorización se puede revocar al no emitir nuevos tokens de acceso. Un recurso no necesita consultar el servidor de autorización para ver si el token de acceso es válido. Esto simplifica la validación del token de acceso y hace que sea más fácil escalar y admitir múltiples servidores de autorización. Hay una ventana de tiempo cuando un token de acceso es válido, pero se revoca la autorización.

De hecho, en la situación en la que el Servidor de recursos y el Servidor de autorización son la misma entidad, y donde la conexión entre el usuario y cualquiera de ellos es (generalmente) igualmente segura, no tiene mucho sentido mantener el token de actualización separado del token de acceso.

Aunque, como se menciona en la cita, otra función de los tokens de actualización es garantizar que el token de acceso pueda ser revocado en cualquier momento por el usuario (a través de la interfaz web en sus perfiles, por ejemplo) mientras mantiene el sistema escalable al mismo tiempo .

En general, los tokens pueden ser identificadores aleatorios que apuntan al registro específico en la base de datos del Servidor, o pueden contener toda la información en sí mismos (ciertamente, esta información debe estar firmada, con MAC , por ejemplo).

Cómo debería funcionar el sistema con tokens de acceso de larga duración

El servidor permite al Cliente obtener acceso a los datos del Usuario dentro de un conjunto predefinido de ámbitos mediante la emisión de un token. Como queremos mantener el token revocable, debemos almacenar en la base de datos el token junto con el indicador "revocado" establecido o no (de lo contrario, ¿cómo haría eso con un token autónomo?) La base de datos puede contener tanto como len(users) x len(registered clients) x len(scopes combination)registros . Cada solicitud de API debe llegar a la base de datos. Aunque es bastante trivial hacer consultas a dicha base de datos que realiza O (1), el único punto de falla en sí mismo puede tener un impacto negativo en la escalabilidad y el rendimiento del sistema.

Cómo debería funcionar el sistema con token de actualización de larga duración y token de acceso de corta duración

Aquí emitimos dos claves: token de actualización aleatorio con el registro correspondiente en la base de datos y token de acceso autónomo firmado, que contiene entre otros el campo de marca de tiempo de vencimiento.

Como el token de acceso es autónomo, no tenemos que acceder a la base de datos para verificar su validez. Todo lo que tenemos que hacer es decodificar el token y validar la firma y la marca de tiempo.

Sin embargo, todavía tenemos que mantener la base de datos de tokens de actualización, pero el número de solicitudes a esta base de datos generalmente se define por la vida útil del token de acceso (cuanto mayor es la vida útil, menor es la tasa de acceso).

Para revocar el acceso del Cliente a un Usuario en particular, debemos marcar el token de actualización correspondiente como "revocado" (o eliminarlo por completo) y dejar de emitir nuevos tokens de acceso. Sin embargo, es obvio que hay una ventana durante la cual se ha revocado el token de actualización, pero su token de acceso aún puede ser válido.

Compensaciones

Los tokens de actualización eliminan parcialmente el SPoF (punto único de falla) de la base de datos de tokens de acceso, aunque tienen algunos inconvenientes obvios.

  1. La ventana". Un período de tiempo entre los eventos "el usuario revoca el acceso" y "se garantiza la revocación del acceso".

  2. La complicación de la lógica del cliente.

    sin token de actualización

    • enviar solicitud de API con token de acceso
    • Si el token de acceso no es válido, falle y solicite al usuario que vuelva a autenticarse

    con token de actualización

    • enviar solicitud de API con token de acceso
    • Si el token de acceso no es válido, intente actualizarlo utilizando el token de actualización
    • si se pasa la solicitud de actualización, actualice el token de acceso y vuelva a enviar la solicitud inicial de la API
    • Si la solicitud de actualización falla, solicite al usuario que vuelva a autenticarse

Espero que esta respuesta tenga sentido y ayude a alguien a tomar una decisión más reflexiva. Me gustaría señalar también que algunos proveedores conocidos de OAuth2, incluidos github y foursquare adoptan el protocolo sin tokens de actualización, y parecen contentos con eso.


44
@RomannImankulov Si entiendo correctamente actualizar el token, podemos guardarlo en db y eliminarlo cada vez que queramos revocar el acceso, entonces ¿por qué no guardar los tokens de acceso?
kosnkov

30
@kosnkov la versión corta de mi publicación es que, si guarda el token de acceso en la base de datos, acierta la base de datos en cada solicitud a su API (lo que puede o no ser un problema en su caso particular). Si guarda los tokens de actualización y mantiene los tokens de acceso "autocontenidos", solo accede a la base de datos cuando el cliente decide actualizar el token de acceso.
Roman Imankulov

55
Personalmente, no me gusta este enfoque de no golpear la base de datos para aumentar el rendimiento si va a comprometer la seguridad (aunque solo sea por el intervalo de tiempo de la ventana). Uno debería poder revocar un acceso_token inmediatamente si es necesario, ya que casi siempre estamos tratando con información confidencial del usuario (de lo contrario, probablemente no estaríamos usando OAuth en primer lugar). Me pregunto qué enfoque utilizan empresas más grandes como Facebook y Google.
Tiago

1
No entiendo completamente por qué tenemos que tener la "ventana abierta" por algún tiempo. ¿Por qué no podemos simplemente enviar una solicitud al servidor de recursos para que no acepte tokens de acceso para este usuario? ¿También estoy en lo cierto al decir que no puede tener un comportamiento de token de actualización cuando no tiene secreto de cliente para firmar tokkens? Así que, básicamente, no puede usar tokens de actualización de software en dispositivos cliemts js, aplicaciones de escritorio móviles, etc.
Igor Čordaš

1
@PSIXO el servidor de recursos no tiene ningún almacén persistente además de la base de datos y tal vez un caché local. Por lo tanto, la única forma en que puede verificar si se revoca un token es presionando la base de datos, que es lo que todo este proceso intenta evitar. En cuanto a tu segunda pregunta, no estás en lo correcto. Si tiene un token de actualización, puede solicitar nuevos tokens de acceso.
bernie

199

A pesar de todas las excelentes respuestas anteriores, yo, como estudiante de maestría de seguridad y programador que trabajó anteriormente en eBay cuando examiné la protección del comprador y el fraude, puedo decir que separar el token de acceso y el token de actualización tiene su mejor equilibrio entre acosar al usuario de un nombre de usuario frecuente / ingreso de contraseña y mantener la autoridad en la mano para revocar el acceso a posibles abusos de su servicio.

Piensa en un escenario como este. Emite al usuario un token de acceso de 3600 segundos y actualiza el token mucho más tiempo como un día.

  1. El usuario es un buen usuario, está en casa y activa / desactiva el sitio web comprando y buscando en su iPhone. Su dirección IP no cambia y tiene una carga muy baja en su servidor. Al igual que las solicitudes de 3-5 páginas cada minuto. Cuando terminan sus 3600 segundos en el token de acceso, necesita uno nuevo con el token de actualización. Nosotros, en el lado del servidor, verificamos su historial de actividad y su dirección IP, creemos que es un ser humano y se porta bien. Le otorgamos un nuevo token de acceso para continuar utilizando nuestro servicio. El usuario no necesitará ingresar nuevamente el nombre de usuario / contraseña hasta que haya alcanzado un día de duración del token de actualización.

  2. El usuario es un usuario descuidado . Vive en Nueva York, EE. UU., Cerró su programa de virus y fue pirateado por un pirata informático en Polonia . Cuando el hacker obtuvo el token de acceso y el token de actualización, intenta hacerse pasar por el usuario y utilizar nuestro servicio. Pero después de que caduca el token de acceso de corta duración, cuando el hacker intenta actualizar el token de acceso, nosotros, en el servidor, hemos notado un cambio dramático de IP en el historial de comportamiento del usuario (hey, este tipo inicia sesión en EE. UU. Y ahora actualiza el acceso en Polonia después de solo 3600 s ???). Terminamos el proceso de actualización, invalidamos el token de actualización y le pedimos que ingrese el nombre de usuario / contraseña nuevamente.

  3. El usuario es un usuario malintencionado . Tiene la intención de abusar de nuestro servicio llamando 1000 veces a nuestra API cada minuto usando un robot. Puede hacerlo hasta 3600 segundos después, cuando intenta actualizar el token de acceso, notamos su comportamiento y pensamos que podría no ser un humano. Rechazamos y finalizamos el proceso de actualización y le pedimos que ingrese el nombre de usuario / contraseña nuevamente. Esto podría potencialmente romper el flujo automático de su robot. Al menos lo incomoda.

Puede ver que el token de actualización ha actuado perfectamente cuando intentamos equilibrar nuestro trabajo, la experiencia del usuario y el riesgo potencial de un token robado. Su perro guardián en el lado del servidor puede verificar más que el cambio de IP, la frecuencia de las llamadas API para determinar si el usuario será un buen usuario o no.

Otra palabra es que también puede intentar limitar el control de daños de la ficha robada / abuso de servicio implementando en cada llamada API el perro guardián de IP básico o cualquier otra medida. Pero esto es costoso ya que tiene que leer y escribir registros sobre el usuario y ralentizará la respuesta de su servidor.


@laalaguer ¿Tiene algunas políticas más específicas como, por ejemplo: no revocar el token cuando se cambia la dirección IP del usuario (cuando el teléfono móvil se desconecta de WiFi y se conecta a la red 3G / 4G)?
svlada

65
Estas son algunas buenas políticas e ideas, pero no veo nada en su respuesta que inherentemente requiera el uso de tokens de actualización. Todas estas características se pueden implementar solo con el token de acceso.
Evert

12
@Evert, uno de los beneficios de usar tokens de acceso y actualización es que los tokens de acceso pueden ser de corta duración y, por lo tanto, no es un gran compromiso de seguridad confiar incondicionalmente en ellos sin consultar con el servidor que los emitió originalmente. Esto puede permitirle escalar su infraestructura para que partes no críticas de ella puedan confiar en la información almacenada en el token (firmado) sin acceso directo a la información de la cuenta del usuario.
Avi Cherry

77
@Avi Cherry: sí, un token de acceso puede ser de corta duración y también puede actualizarse si el usuario aún se considera válido. No requiere un token de actualización para hacer eso.
Rick Jolly

10
Creo que esta respuesta supone que nunca queremos que los servidores de recursos realicen un control de acceso avanzado por sí mismos (p. Ej., Verifiquen la actividad de IP en varias bases de datos, etc.) y, en cambio, solo pueden confiar en verificar el token de acceso en completo aislamiento. Si bien esto puede ser obvio a escala (por razones de rendimiento), claramente no es obvio para todos aquí dada la confusión en otras publicaciones y comentarios. Es una buena publicación con buena información, pero creo que pierde mucho el punto de la pregunta original. Recomiendo al menos hacer explícito el supuesto antes mencionado.
TNE

72

Ninguna de estas respuestas llega a la razón principal por la que existen tokens de actualización. Obviamente, siempre puede obtener un nuevo par de token de acceso / token de actualización enviando sus credenciales de cliente al servidor de autenticación; así es como las obtiene en primer lugar.

Por lo tanto, el único propósito del token de actualización es limitar el uso de las credenciales del cliente que se envían por cable al servicio de autenticación. Cuanto más corto sea el ttl del token de acceso, más a menudo tendrán que usarse las credenciales del cliente para obtener un nuevo token de acceso y, por lo tanto, más oportunidades tendrán los atacantes para comprometer las credenciales del cliente (aunque esto puede ser súper difícil de todos modos si se utiliza cifrado asimétrico para enviarlos). Entonces, si tiene un token de actualización de un solo uso, puede hacer que el ttl de los tokens de acceso sea arbitrariamente pequeño sin comprometer las credenciales del cliente.


16
Esto es interesante, ya que en el caso de Google cuando solicita un token de actualización, también envía la identificación del cliente y el secreto del cliente. Así que estás comprometiendo cada hora de todos modos.
pudre el

1
Alexander, en realidad cuanto más corto es el ttl, más a menudo el cliente tendrá que obtener un nuevo token de acceso (que requiere el uso de las credenciales del cliente). Entonces, de hecho, quiero decir 'más corto' allí. Agregaré una nota para aclarar.
BT

2
"único propósito" - no se lava. Hacer el TTL del token de acceso siempre que el del token de actualización imaginado logre lo mismo.
Ruibarbo

8
Dado que el estándar requiere que se envíen las credenciales del cliente junto con el token de actualización, la premisa de esta respuesta es simplemente falsa. "Debido a que los tokens de actualización suelen ser credenciales duraderas que se utilizan para solicitar tokens de acceso adicionales ... el cliente DEBE autenticarse con el servidor de autorización". También vea el comentario de @Rots.
Kevin Christopher Henry

8
A) Creo que estás mezclando secretos de clientes y secretos de usuarios. El secreto del cliente nunca se envía desde el dispositivo del usuario, solo desde la aplicación backend de acceso a la aplicación backend que proporciona los datos. B) El servidor oAuth que permite la concesión de contraseña para un Cliente público (un cliente que no puede mantener un secreto de cliente como una aplicación nativa o javascript) también proporcionará una concesión de token de actualización para ese cliente público, por lo que no necesita envía un secreto de cliente al actualizar tu token. C) El token de actualización proporciona al backend un "latido del corazón" cuando se verifica la validez del usuario.
Andreas Lundgren

55

Para aclarar alguna confusión, debe comprender los roles del secreto del cliente y la contraseña del usuario , que son muy diferentes.

El cliente es una aplicación / sitio web / programa / ..., respaldado por un servidor, que desea autenticar a un usuario utilizando un servicio de autenticación de terceros. El secreto del cliente es una cadena (aleatoria) que tanto este cliente como el servidor de autenticación conocen. Usando este secreto, el cliente puede identificarse con el servidor de autenticación, recibiendo autorización para solicitar tokens de acceso.

Para obtener el token de acceso inicial y el token de actualización, lo que se requiere es:

  • La identificación del usuario
  • La contraseña de usuario
  • La identificación del cliente
  • El secreto del cliente

Sin embargo, para obtener un token de acceso actualizado, el cliente utiliza la siguiente información:

  • La identificación del cliente
  • El secreto del cliente
  • El token de actualización

Esto muestra claramente la diferencia: al actualizar, el cliente recibe autorización para actualizar los tokens de acceso utilizando su secreto de cliente y, por lo tanto, puede volver a autenticar al usuario utilizando el token de actualización en lugar del ID de usuario + contraseña. Esto efectivamente evita que el usuario tenga que volver a ingresar su contraseña.

Esto también muestra que perder un token de actualización no es un problema porque no se conocen el ID y el secreto del cliente. También muestra que mantener el ID del cliente y el secreto del cliente en secreto es vital .


1
"Esto también muestra que perder un token de actualización no es un problema porque no se conocen el ID y el secreto del cliente". Pero no los necesito. Si recibí un token de actualización, puedo pasarlo a su servidor de aplicaciones. Agrega client_id y secret y luego pasa los tres al servicio OAuth. ¿Cuál es el punto de?
3DFace

77
El servidor de aplicaciones no proporciona una forma de proporcionar un token de actualización usted mismo, no puede pedirle que genere un nuevo token de autenticación dándole un token de actualización. Renueva el token de autenticación cuando es necesario, "detrás de escena".
Adversus

2
Tenga en cuenta que, de hecho, necesita el secreto del cliente para obtener el token de actualización en primer lugar. Es posible que esté pensando en el flujo de autenticación implícito, donde no necesita un secreto, pero en ese caso no se emiten ni usan tokens de actualización.
Kevin Christopher Henry

@KevinChristopherHenry ¿esto sugiere que para un usuario final que solo inicia sesión en el sitio web de la empresa XYZ.com un token de actualización no tiene sentido obtener un nuevo token de acceso para XYZ.com? Pero un token de actualización puede ser cualquier cadena indescifrable, como un guid, almacenada en una tabla que se puede buscar muy rápidamente. Mientras que un token de acceso puede ser mucho más largo y difícil de indexar en una base de datos. Por lo tanto, el token de actualización PUEDE almacenarse y tener beneficios en el lado del usuario final. [aunque dado que esta pregunta habla sobre oauth2, tal vez cualquier respuesta sin un servicio de terceros que actúe en nombre de una persona no sea relevante de todos modos]
Simon_Weaver

¿por qué no puede simplemente pasar el 'ID del cliente' + 'El secreto del cliente' + 'token de acceso caducado' para obtener un nuevo token de acceso?
Miel

37

Esta respuesta es de Justin Richer a través de la lista de correo electrónico del cuerpo estándar de OAuth 2. Esto se publica con su permiso.


La vida útil de un token de actualización depende del servidor de autorización (AS): pueden caducar, ser revocados, etc. La diferencia entre un token de actualización y un token de acceso es la audiencia: el token de actualización solo vuelve al servidor de autorización, el token de acceso va al servidor de recursos (RS).

Además, el simple hecho de obtener un token de acceso no significa que el usuario haya iniciado sesión. De hecho, es posible que el usuario ya no esté allí, que en realidad es el caso de uso previsto del token de actualización. Actualizar el token de acceso le dará acceso a una API en nombre del usuario, no le dirá si el usuario está allí.

OpenID Connect no solo le brinda información de usuario de un token de acceso, sino que también le brinda un token de identificación. Este es un dato separado que se dirige al cliente en sí, no al AS ni al RS. En OIDC, solo debe considerar a alguien realmente "conectado" por el protocolo si puede obtener un token de identificación nuevo. Actualizarlo no es probable que sea suficiente.

Para obtener más información, lea http://oauth.net/articles/authentication/


Esto parece ser sobre OpenID Connect y la autenticación, por lo que no veo cómo esto responde a la pregunta, que es sobre la motivación para actualizar el token.
Sleske

18

Los clientes pueden verse comprometidos de muchas maneras. Por ejemplo, se puede clonar un teléfono celular. Tener un token de acceso caduca significa que el cliente se ve obligado a volver a autenticarse en el servidor de autorización. Durante la reautenticación, el servidor de autorización puede verificar otras características (IOW realiza una gestión de acceso adaptativa).

Los tokens de actualización permiten que el cliente solo se vuelva a autenticar, mientras que al volver a autorizar se fuerza un diálogo con el usuario que muchos han indicado que preferirían no hacer.

Los tokens de actualización encajan esencialmente en el mismo lugar donde los sitios web normales podrían optar por volver a autenticar periódicamente a los usuarios después de una hora más o menos (por ejemplo, sitio bancario). Actualmente no se usa mucho, ya que la mayoría de los sitios web sociales no vuelven a autenticar a los usuarios, ¿por qué volverían a autenticar a un cliente?


2
"Los tokens de actualización permiten que un cliente solo vuelva a autenticarse ..." es un aspecto importante aquí.
James

13

¿Por qué no hacer que el access_token dure tanto como el refresh_token y no tener un refresh_token?

Además de las excelentes respuestas que otras personas han brindado, hay otra razón por la cual usarían tokens de actualización y tiene que ver con los reclamos.

Cada token contiene reclamos que pueden incluir cualquier cosa, desde el nombre del usuario, sus roles o el proveedor que creó el reclamo. A medida que se actualiza un token, estos reclamos se actualizan.

Si actualizamos los tokens con más frecuencia, obviamente estamos ejerciendo más presión sobre nuestros servicios de identidad, sin embargo, estamos recibiendo reclamos más precisos y actualizados.


44
Sería una mala práctica inusual poner tales "reclamos" en el token de acceso. Como se describe en la especificación , el token de acceso "suele ser opaco para el cliente". ¿Tiene ejemplos de proveedores de OAuth que hacen esto?
Kevin Christopher Henry

3
@heymega Cuando la función de usuario se degrada de ADMIN a REGULAR_USER, la expectativa es que la función de usuario debe ser revocada inmediatamente y no cuando expire access_token. Por lo tanto, parece que golpear la base de datos en cada solicitud es inevitable.
svlada

@svlada Imagino que sería un caso en el que la aplicación que rebaja una entidad de ADMIN a REGULAR_USER (en el mismo proceso) también debería revocar el token apropiado. es decir, si sabemos que los reclamos van a cambiar, no esperamos la expiración, lo
revocamos de

13

Para simplificar aún más la respuesta de BT: use tokens de actualización cuando normalmente no desea que el usuario tenga que volver a escribir las credenciales, pero aún así desea que el poder pueda revocar los permisos (revocando el token de actualización)

No puede revocar un token de acceso, solo un token de actualización.


1
Puede revocar un token de acceso, lo que requerirá iniciar sesión nuevamente para otro token de acceso o usar el token de actualización para obtener otro token de acceso. Si el token de actualización no era válido, el usuario tendrá que volver a autenticarse para obtener un nuevo token de acceso junto con un nuevo token de actualización.
Atieh

10
Estoy en desacuerdo. El servidor de autenticación emite un token de acceso, se firma con una fecha de caducidad y se envía al cliente. Cuando el cliente envía ese token al servidor de recursos, el servidor de recursos no se pone en contacto con el servidor de autenticación para verificar el token; solo mira la fecha de vencimiento en el token (firmado y sin manipular). Entonces, no importa lo que haga en el servidor de autenticación para intentar 'revocar', al servidor de recursos no le importa. Algunas personas se refieren al cierre de sesión del cliente como una revocación (es decir, el cliente elimina su token) pero, en mi opinión, esto es una terminología engañosa: queremos 'revocar' un token en el servidor, no en el cliente
bitcoder

1
No digo que no pueda escribir código personalizado para ignorar ciertos tokens (como aquí stackoverflow.com/questions/22708046/… ) pero hacer eso probablemente implique algunos viajes de red desde el servidor de recursos al servidor / db oauth cada vez que el cliente realiza una llamada. Evita esas llamadas utilizando tokens de actualización en su lugar, y creo que está más en línea con lo que pretendían los autores.
bitcoder

13

Esta respuesta ha sido elaborada con la ayuda de dos desarrolladores senior (John Brayton y David Jennes).

La razón principal para usar un token de actualización es reducir la superficie de ataque.

Supongamos que no hay una clave de actualización y veamos este ejemplo:

Un edificio tiene 80 puertas. Todas las puertas se abren con la misma llave. La clave cambia cada 30 minutos. Al final de los 30 minutos, tengo que darle la vieja llave al creador de llaves y obtener una nueva.

Si soy el hacker y obtengo tu llave, al final de los 30 minutos, se la enviaré al creador de llaves y obtendré una nueva llave. Voy a ser capaz de forma continua abrir todas las puertas sin tener en cuenta el cambio clave.

Pregunta: Durante los 30 minutos, ¿cuántas oportunidades de pirateo tuve contra la clave? Tuve 80 oportunidades de pirateo, cada vez que usaste la clave (piensa en esto como hacer una solicitud de red y pasar el token de acceso para identificarte). Entonces esa es la superficie de ataque 80X.

Ahora veamos el mismo ejemplo, pero esta vez supongamos que hay una clave de actualización.

Un edificio tiene 80 puertas. Todas las puertas se abren con la misma llave. La clave cambia cada 30 minutos. Para obtener una nueva clave, no puedo pasar el token de acceso anterior. Solo debo pasar la clave de actualización.

Si soy el hacker y obtengo tu clave, puedo usarla durante 30 minutos, pero al final de los 30 minutos enviarla al creador de claves no tiene ningún valor. Si lo hago, el creador de claves solo diría este token de actualización incorrecto. Para poder extender mi pirateo, tendría que hackear el servicio de mensajería al creador de llaves. El servicio de mensajería tiene una clave distinta (piense en esto como un token de actualización).

Pregunta: Durante los 30 minutos, ¿cuántas oportunidades de pirateo tuve contra la tecla de actualización? 80? No. Solo tuve 1 oportunidad de hackear. Durante el tiempo, el servicio de mensajería se comunica con el keymaker. Entonces esa es la superficie de ataque 1X. Tuve 80 oportunidades de pirateo contra la clave, pero no son buenas después de 30 minutos.


Un servidor verificaría un token de acceso basado en credenciales y firma (típicamente) de un JWT.

Una fuga de token de acceso es mala, pero una vez que expira ya no es útil para un atacante. Una pérdida de token de actualización es mucho peor, pero presumiblemente es menos probable. (Creo que hay espacio para cuestionar si la probabilidad de una fuga de token de actualización es mucho menor que la de una fuga de token de acceso, pero esa es la idea).

El punto es que el token de acceso se agrega a cada solicitud que realice, mientras que un token de actualización solo se usa durante el flujo de actualización, por lo que hay menos posibilidades de que un MITM vea el token

La frecuencia ayuda a un atacante. Heartbleed posibles fallas de seguridad similares a en SSL, las posibles fallas de seguridad en el cliente y las posibles fallas de seguridad en el servidor hacen posible la filtración.

Además, si el servidor de autorización está separado del servidor de aplicaciones que procesa otras solicitudes de clientes, ese servidor de aplicaciones nunca verá tokens de actualización. Solo verá tokens de acceso que no vivirán por mucho más tiempo.

La compartimentación es buena para la seguridad.

Por último, pero no menos importante, vea esta increíble respuesta


¿De qué NO se trata el token de actualización?

La capacidad de actualizar / revocar el nivel de acceso a través de tokens de actualización es un subproducto de elegir usar tokens de actualización, de lo contrario, un token de acceso independiente podría revocarse o modificarse su nivel de acceso cuando caduque y los usuarios obtengan un nuevo token


2
es difícil seguir esta comparación, ya que las preguntas son diferentes 1. "Durante los 30 minutos, ¿cuántas oportunidades de pirateo tuve contra la clave?" (¿No tenía la clave como hacker primero?) 2. "Durante los 30 minutos, ¿cuántas oportunidades de pirateo tuve contra el servicio de mensajería?". ¿Cuál sería una "oportunidad de piratería"? Como hacker, ¿no tenía la llave en primer lugar?
Cesc

1
Tienes razón. Hice cambios
Miel

4

Suponga que hace que el access_tokenúltimo sea muy largo y que no lo haya hecho refresh_token, así que en un día, ¡el pirata informático obtendrá esto access_tokeny podrá acceder a todos los recursos protegidos!

Pero si lo ha hecho refresh_token, el access_tokentiempo de vida es corto, por lo que es difícil piratear al pirata informático access_tokenporque no será válido después de un corto período de tiempo. Access_tokensolo se puede recuperar usando no solo refresh_tokensino también con client_idy client_secret, que el hacker no tiene.


2
"al usar no solo refresh_token sino también por client_id y client_secret, que el hacker no tiene". 1. Supongamos que es solo un token de acceso, ¿entonces el hacker todavía no necesita client_id y client_secret? 2. si un hacker es un buen hacker, entonces también puede hackear client_id y client_secret. Independientemente de esa parte, piratear cosas adicionales no debería importar a la comparación, porque si es difícil de hackear, entonces también es difícil de hackear en el caso de usar solo token de acceso ... en resumen, no estás comparando situaciones idénticas. Los estás mezclando
Honey

2

Mientras el token de actualización es retenido por el servidor de Autorización. El token de acceso es autónomo, por lo que el servidor de recursos puede verificarlo sin almacenarlo, lo que ahorra el esfuerzo de recuperación en caso de validación. Otro punto que falta en discusión es de rfc6749 # page-55

"Por ejemplo, el servidor de autorización podría emplear la rotación del token de actualización en el que se emite un nuevo token de actualización con cada respuesta de actualización del token de acceso. El token de actualización anterior se invalida pero el servidor de autorización lo retiene. Si un token de actualización se ve comprometido y posteriormente utilizado por tanto el atacante como el cliente legítimo, uno de ellos presentará un token de actualización invalidado, que informará al servidor de autorización de la violación ".

Creo que el objetivo de usar el token de actualización es que incluso si el atacante de alguna manera logra obtener el token de actualización, la identificación del cliente y la combinación secreta. Con las llamadas posteriores para obtener un nuevo token de acceso del atacante se puede rastrear en caso de que cada solicitud de actualización dé como resultado un nuevo token de acceso y un token de actualización.


Creo que este es un punto muy importante :-) También, hasta cierto punto, invalida el argumento aquí auth0.com/docs/tokens/refresh-token/current#restrictions thatA Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Simon_Weaver

1

Consideremos un sistema donde cada usuario está vinculado a uno o más roles y cada rol está vinculado a uno o más privilegios de acceso. Esta información se puede almacenar en caché para un mejor rendimiento de la API. Pero luego, puede haber cambios en las configuraciones de usuario y rol (por ejemplo, se puede otorgar un nuevo acceso o se puede revocar el acceso actual) y estos deben reflejarse en la memoria caché.

Podemos usar tokens de acceso y actualización para tal fin. Cuando se invoca una API con token de acceso, el servidor de recursos verifica la memoria caché en busca de derechos de acceso. SI hay nuevas concesiones de acceso, no se refleja de inmediato. Una vez que el token de acceso caduca (por ejemplo, en 30 minutos) y el cliente usa el token de actualización para generar un nuevo token de acceso, la memoria caché se puede actualizar con la información de acceso de usuario actualizada de la base de datos.

En otras palabras, podemos mover las costosas operaciones de cada llamada API usando tokens de acceso al evento de generación de tokens de acceso usando token de actualización.


0

Primero, el cliente se autentica con el servidor de autorización al otorgar la autorización.

Luego, el cliente solicita al servidor de recursos el recurso protegido al proporcionar el token de acceso.

El servidor de recursos valida el token de acceso y proporciona el recurso protegido.

El cliente realiza la solicitud de recursos protegidos al servidor de recursos al otorgar el token de acceso, donde el servidor de recursos lo valida y atiende la solicitud, si es válida. Este paso se repite hasta que caduque el token de acceso.

Si el token de acceso caduca, el cliente se autentica con el servidor de autorización y solicita un nuevo token de acceso al proporcionar un token de actualización. Si el token de acceso no es válido, el servidor de recursos devuelve la respuesta de error del token no válido al cliente.

El cliente se autentica con el servidor de autorización otorgando el token de actualización.

El servidor de autorización luego valida el token de actualización autenticando al cliente y emite un nuevo token de acceso, si es válido.


En realidad, esto no menciona de dónde se origina el token de actualización. Supongo que el segundo párrafo debería decir access token + refresh token?
Simon_Weaver
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.