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

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

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

¿Por qué ambos? ¿Por qué no simplemente hacer que access_token dure lo mismo que refresh_token y no tenga refresh_token ?

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

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

Habiendo dicho eso , 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 de las implementaciones en las que no se controlan tanto la autorización como los servidores de recursos.

Aquí hay un buen hilo de conversación sobre los usos de los tokens de actualización: Archivos OAuth .

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 (param de consulta en un archivo de registro en un servidor de recursos inseguros, beta o una aplicación de servidor de recursos pobremente codificada, cliente JS SDK en un sitio no https que coloca el access_token en un galleta, etc.)

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

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

revocación: si el token de acceso es independiente, la autorización puede revocarse 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 de token de acceso y facilita la escala y el soporte de múltiples servidores de autorización. Hay un intervalo de tiempo en el que un token de acceso es válido, pero la autorización se revoca.

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

Aunque, como se menciona en la cita, otro rol 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 .

Generalmente, 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, por ejemplo con MAC ).

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 emitiendo un token. Como queremos mantener el token revocable, debemos almacenar en la base de datos el token junto con la bandera “revocada” que se establece o desarma (de lo contrario, ¿cómo lo haría con un token autónomo?) La base de datos puede contener tanto como len(users) x len(registered clients) x len(scopes combination) . Cada solicitud de API debe golpear la base de datos. Aunque es bastante trivial realizar 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 vida

Aquí emitimos dos claves: token de actualización aleatoria con el registro correspondiente en la base de datos y token de acceso autónomo firmado, que contiene entre otros el campo de indicación de la fecha de caducidad.

Como el token de acceso es autónomo, no es necesario que accedamos a la base de datos para verificar su validez. Todo lo que tenemos que hacer es descodificar 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 duración del token de acceso (cuanto más larga es la vida útil, menor es la tasa de acceso).

Para revocar el acceso del Cliente de un Usuario en particular, debemos marcar el token de actualización correspondiente como “revocado” (o eliminarlo por completo) y dejar de emitir tokens de acceso nuevos. 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 (Single Point of Failure) de la base de datos Access Token, pero tienen algunos inconvenientes obvios.

  1. La ventana”. Un intervalo de tiempo entre los eventos “el usuario revoca el acceso” y “se garantiza que el acceso se revocará”.

  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, falla y pide al usuario que se vuelva a autenticar

    con token de actualización

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

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 felices con eso.

A pesar de todas las excelentes respuestas anteriores, como estudiante de seguridad y progtwigdor que trabajé anteriormente en eBay cuando eché un vistazo a la protección del comprador y el fraude, puedo decir que el token de acceso y token de actualización tiene su mejor equilibrio entre hostigar al usuario de nombre de usuario frecuente / contraseña y manteniendo la autoridad a mano para revocar el acceso a un posible abuso de su servicio.

Piensa en un escenario como este. Usted emite un token de acceso de 3600 segundos y actualiza el token por más tiempo como un día.

  1. El usuario es un buen usuario, se encuentra en casa y se conecta / desconecta de su sitio web comprando y buscando en su iPhone. Su dirección IP no cambia y tiene una carga muy baja en su servidor. Como 3-5 páginas solicitan cada minuto. Cuando sus 3600 segundos en el token de acceso se terminan, 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 comporta solo. 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 el lapso de vida de un día del token de actualización.

  2. El usuario es un usuario descuidado . Vive en Nueva York, EE. UU. Y su progtwig de virus se cerró 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 usar nuestro servicio. Pero después de que el token de acceso corto expira, cuando el hacker intenta actualizar el token de acceso, nosotros, en el servidor, notamos 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 3600s ???). Terminamos el proceso de actualización, invalidamos el token de actualización y le pedimos que ingrese nuevamente el nombre de usuario / contraseña.

  3. El usuario es un usuario malicioso . Su intención es abusar de nuestro servicio llamando 1000 veces nuestra API cada minuto usando un robot. Puede hacerlo hasta 3600 segundos más tarde, cuando trata de actualizar el token de acceso, notamos su comportamiento y creemos que podría no ser humano. Rechazamos y terminamos el proceso de actualización y le pedimos que ingrese nuevamente el nombre de usuario / contraseña. Esto podría potencialmente romper el flujo automático de su robot. Al menos lo hace sentir incómodo.

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

Otra palabra es que también puede intentar limitar el control de daños del token / abuso de servicio robado implementando en cada llamada api el reloj de vigilancia 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.

Ninguna de estas respuestas llega al motivo principal por el que existen tokens de actualización. Obviamente, siempre puede obtener un nuevo par de tokens de acceso / refrescar-token enviando sus credenciales de cliente al servidor de autenticación: así es como los 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 a través del cable al servicio de autenticación. Cuanto más corto sea el ttl del token de acceso, más a menudo se deberán usar las credenciales del cliente para obtener un nuevo token de acceso, y por lo tanto, más oportunidades tendrán los atacantes de comprometer las credenciales del cliente (aunque esto puede ser súper difícil de todos modos si cifrado asimétrico se está utilizando para enviarlos). Por lo tanto, si tiene un token de actualización de un solo uso, puede hacer que el ttl de tokens de acceso sea arbitrariamente pequeño sin comprometer las credenciales del cliente.

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 duración de un token de actualización depende del servidor de autorización (AS): pueden caducar, revocarse, 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 autorizaciones, 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 del usuario de un token de acceso, sino que también le proporciona un token de identificación. Esta es una pieza de datos separada que está dirigida al cliente en sí, no al AS o al RS. En OIDC, solo debe considerar a alguien realmente “conectado” por el protocolo si puede obtener un token de ID nuevo. Refrescarlo no es suficiente.

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

Para aclarar algo de 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 / progtwig / …, respaldado por un servidor, que desea autenticar a un usuario mediante el uso de un servicio de autenticación de terceros. El secreto del cliente es una cadena (aleatoria) que es conocida tanto por este cliente como por el servidor de autenticación. Al usar 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:

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

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 mediante el uso de 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 conoce el ID del cliente y el secreto. También muestra que mantener el secreto del cliente y la ID del cliente es vital .

Los clientes pueden verse comprometidos de muchas maneras. Por ejemplo, un teléfono celular puede ser clonado. 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 nueva autenticación, el servidor de autorizaciones puede verificar otras características (IOW realiza una gestión de acceso adaptable).

Los tokens de actualización permiten una nueva autenticación del cliente, mientras que la reautorización obliga a un diálogo con el usuario que muchos han indicado que preferirían no hacer.

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

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

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

¿Por qué no simplemente hacer que access_token dure lo mismo que refresh_token y no tenga refresh_token?

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

Cada token contiene reclamos que pueden incluir cualquier cosa del nombre del usuario, sus roles o el proveedor que creó el reclamo. A medida que se actualiza una ficha, estas reclamaciones se actualizan.

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

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

Luego, el cliente solicita el servidor de recursos para el recurso protegido dando el token de acceso.

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

El cliente realiza la solicitud de recurso protegido al servidor de recursos al otorgar el token de acceso, donde el servidor de recursos lo valida y sirve la solicitud, si es válido. Este paso continúa repitiéndose hasta que el token de acceso caduque.

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 autorizaciones al otorgar el token de actualización.

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

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 acceso nuevo o se puede revocar el acceso actual) y estos deben reflejarse en el 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 comprueba los derechos de acceso de la caché. 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 correcta de acceso de usuario del DB.

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

Mientras que el token de actualización es retenido por el servidor de autorización. Los tokens de acceso son independientes, por lo que el servidor de recursos puede verificarlos sin almacenarlos, lo que ahorra el esfuerzo de recuperación en caso de validación. Otro punto que falta en la discusión es de rfc6749 # page-55

“Por ejemplo, el servidor de autorizaciones podría emplear rotación de token de actualización en la que se emite un nuevo token de actualización con cada respuesta de actualización de token de acceso. El token de actualización anterior es invalidado pero retenido por el servidor de autorizaciones. 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 objective de usar el token de actualización es que incluso si el atacante logra de alguna forma obtener el token de actualización, el ID del cliente y la combinación secreta. Con las llamadas subsiguientes para obtener un nuevo token de acceso del atacante, se puede realizar un seguimiento en caso de que cada solicitud de actualización dé como resultado un nuevo token de acceso y un token de actualización.