¿Por qué OAuth v2 tener tanto acceso y actualización de fichas?

StackOverflow https://stackoverflow.com/questions/3487991

Pregunta

Sección 4.2 del proyecto de OAuth 2.0 protocolo indica que un servidor de autorización puede volver tanto un access_token (que se utiliza para autenticar a sí mismo con un recurso), así como un refresh_token, que se utiliza exclusivamente para crear un nuevo access_token:

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

¿Por qué tienen tanto? ¿Por qué no acaba de hacer el access_token duran tanto como el refresh_token y no tener una refresh_token?

¿Fue útil?

Solución

La idea de tokens de actualización es que si se ve comprometida un token de acceso, ya que es de corta duración, el atacante tiene una ventana limitado para abusar de ella.

Actualizar fichas, si es comprometida, son inútiles ya que el atacante requiere el ID de cliente y secreto, además de la actualización de ficha en el fin de obtener un token de acceso.

Una vez dicho esto , ya que cada llamada a tanto el servidor de autorización y el servidor de recursos se realiza a través de SSL - incluyendo el ID de cliente original y secreta cuando solicitan los de acceso / tokens de actualización - no estoy seguro en cuanto a cómo el token de acceso es más "compromisable" que el símbolo de actualización combinación vivido largo y ClientID / secreto.

Por supuesto, esto es diferente a las implementaciones en las que no controlan tanto los servidores de autorización y de recursos.

Aquí es un buen hilo hablando de usos de tokens de actualización: OAuth Archivos .

Una cita de lo anterior, hablando de las cuestiones de seguridad de la actualización de fichas:

  

Actualizar fichas ... mitiga el riesgo de una duración larga señal_acceso fugas (parámetro de consulta en un archivo de registro en un servidor de recursos insegura, beta o aplicación servidor de recursos mal codificado, JS cliente SDK en un sitio que no https que pone el señal_acceso en una cookie, etc)

Otros consejos

El enlace a la discusión, proporcionado por Catchdave, tiene otro punto válido (, vínculo roto originales) hecho por Dick Hardt, que creo que es digno de ser mencionado aquí, además de lo que se ha escrito anteriormente:

  

Mi recuerdo de tokens de actualización era para la seguridad y la revocación.   <...>

     

revocación: si el token de acceso es independiente, la autorización puede ser revocada por no emitir nuevos tokens de acceso. Un recurso no tiene que consultar al servidor de autorización para ver si el token de acceso es valid.This simplifica el acceso de validación de token y hace que sea más fácil de escalar y soportar múltiples servidores de autorización. Hay una ventana de tiempo cuando una señal de acceso es válida, pero la autorización sea revocada.

De hecho, en la situación en recursos del servidor y el servidor de autorización es la misma entidad, y donde la conexión entre el usuario y cualquiera de ellos es (generalmente) igualmente asegurar, no hay mucho sentido mantener refresco símbolo separar del token de acceso .

A pesar de que, como se menciona en la cita, otro papel de tokens de actualización es asegurar el token de acceso puede ser revocado en cualquier momento por el usuario (a través de la interfaz web en sus perfiles, por ejemplo) mientras se mantiene la escalabilidad del sistema en al mismo tiempo.

En general, las fichas 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 (por cierto, esta información tiene que ser firmado, con MAC, por ejemplo).

¿Cómo el sistema con tokens de acceso de larga vida debe trabajar

El servidor permite al cliente para obtener acceso a los datos del usuario dentro de un conjunto predefinido de ámbitos mediante la emisión de una ficha. Como queremos mantener la revocable modo, hay que almacenar en la base de datos de la ficha junto con la bandera "revocada" ser conectado o desconectado (de lo contrario, ¿cómo hacer eso con auto-contenida ficha?) De base de datos puede contener tanto como len(users) x len(registered clients) x len(scopes combination) registros. Cada solicitud de API a continuación, debe golpear la base de datos. Aunque es bastante trivial para hacer consultas a dicha base de datos que realizan O (1), el punto único de fallo en sí mismo puede tener un impacto negativo en la escalabilidad y el rendimiento del sistema.

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

A continuación, emitimos dos claves: refresco al azar de token con el registro correspondiente en la base de datos, y el token de acceso autónomo firmado, que contiene entre otros el campo de caducidad marca de tiempo

.

A medida que el token de acceso es autónomo, no disponemos de golpear la base de datos en absoluto para comprobar su validez. Todo lo que tenemos que hacer es decodificar la señal y para validar la firma y el sello 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 se define generalmente por la vida útil del token de acceso (el más largo es el tiempo de vida, menor será la tasa de acceso).

Para revocar el acceso de cliente de un usuario particular, se debe marcar la actualización correspondiente de contadores como "revocado" (o eliminar por completo) y la parada de la emisión de nuevas fichas de acceso. Es evidente sin embargo que hay una ventana durante el cual el token de actualización ha sido revocado, pero su token de acceso todavía puede ser válida.

Tradeoffs

Actualizar fichas de eliminar parcialmente el SPOF (único punto de fallo) de la base de datos Access de emergencia, sin embargo, tienen algunas desventajas obvias.

  1. La "ventana". Un período de tiempo entre eventos "usuario revoca el acceso" y "acceso está garantizado para ser revocada".

  2. El complicatión de la lógica del cliente.

    sin actualización símbolo

    • solicitud de la API de envío con token de acceso
    • Si el token de acceso no es válido, fallar y pedir al usuario que vuelva a autenticarse

    actualización símbolo

    • solicitud de la API de envío con token de acceso
    • Si el token de acceso no es válido, tratar de actualizarlo usando refresco símbolo
    • si pasa a petición de actualización, actualizar el token de acceso y volver a enviar la solicitud inicial de la API
    • Si petición de actualización falla, pida al usuario que vuelva a autenticarse

Espero que esta respuesta no tiene sentido y ayuda a alguien para tomar la decisión más reflexivo. Me gustaría señalar también que algunos proveedores OAuth2 bien conocidos, incluyendo github y en cuadro sin adoptar protocolo de tokens de actualización, y parecen contentos con eso.

A pesar de todas las grandes respuestas arriba, como un estudiante de maestría seguridad y programador que trabajó anteriormente en eBay cuando tomé una mirada en la protección del comprador y el fraude, puede decir a acceso independiente token y refresco símbolo tiene su mejor equilibrio entre el acoso de usuario de frecuentes nombre de usuario de entrada / contraseña y mantener la autoridad en la mano para revocar el acceso al potencial abuso de su servicio.

Piense en un escenario como este. Se emite usuario de un token de acceso de 3600 segundos y actualiza símbolo mucho más tiempo como un día.

  1. El usuario es un buena usuario, que está en casa y se pone de encendido / apagado sus compras sitio web y buscar en su iPhone. Su dirección IP no cambia y tienen una carga muy baja en su servidor. Como 3-5 solicitudes de páginas por minuto. Cuando sus 3.600 segundos sobre el token de acceso es más, se requiere una nueva con el token de actualización. Nosotros, por el lado del servidor, comprobar su historial de actividades y la dirección IP, pensamos que es un ser humano y se comporta él mismo. Nosotros le conceda un nuevo token de acceso para seguir utilizando nuestro servicio. no será necesario que el usuario introduzca de nuevo el nombre de usuario / contraseña hasta que se ha alcanzado vida un día útil de refresco símbolo en sí.

  2. El usuario es un descuidado usuario. Vive en Nueva York, EE.UU. y consiguió su apagado programa de virus y fue hackeado por un hacker en Polonia . Cuando el hacker consiguió el token de acceso y refrescar modo, trata de hacerse pasar por el usuario y el uso de nuestro servicio. Pero después de la corta vida token de acceso expira, cuando a los intentos de hackers refrescar el token de acceso, que, en el servidor, se ha notado un cambio de propiedad intelectual dramático de la historia del comportamiento del usuario (hey, este tipo inicios de sesión en EE.UU. y el acceso ahora refresco en Polonia después de 3600 sólo ???). Damos por terminado el proceso de actualización, invalidar la actualización token de sí mismo y solicita que introduzca nombre de usuario / contraseña de nuevo.

  3. El usuario es un malicioso usuario. Él tiene la intención de abusar de nuestro servicio llamando al 1000 veces nuestra API por minuto utilizando un robot. Él también puede hacerlo hasta 3600 segundos después, cuando se intenta actualizar el token de acceso, nos dimos cuenta de su comportamiento y pensamos que podría no ser un ser humano. Rechazamos y terminar el proceso de actualización y le pedimos que ingrese nombre de usuario / contraseña de nuevo. Esto podría potencialmente romper flujo automático de su robot. Al menos le hace incómodo.

Se puede ver el símbolo de actualización ha actuado 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 servidor puede marcar más de cambio de IP, frecuencia de llamadas a la API para determinar si el usuario deberá ser un buen usuario o no.

Otra palabra es que también puede tratar de limitar el control de daños del / abuso símbolo robada del servicio mediante la implementación en cada llamada a la API el perro reloj básica IP o cualquier otra medida. Pero esto es caro, ya que tiene que leer y grabar discos de escritura sobre el usuario y se ralentizará su respuesta del servidor.

Ninguna de estas respuestas a llegar a la razón de la base existen tokens de actualización. Obviamente, siempre se puede obtener un nuevo token de acceso / par de refresco en token mediante el envío de sus credenciales de cliente al servidor de autenticación -. Eso es cómo los obtiene en primer lugar

Así que el único propósito de la actualización token es para limitar el uso de las credenciales del cliente se envía a través del cable para el servicio de autenticación. Cuanto más corto sea el TTL del acceso en token, más a menudo las credenciales del cliente tendrá que ser utilizado para obtener un nuevo acceso en token, y por lo tanto más oportunidades atacantes tienen que comprometer las credenciales del cliente (aunque esto puede ser muy difícil de todos modos si el cifrado asimétrico se utiliza para enviarlos). Así que si usted tiene una actualización en token de un solo uso, puede hacer que el TTL de acceso-tokens arbitrariamente pequeño sin comprometer las credenciales del cliente.

Para aclarar cierta confusión que tiene que entender el papel de la el secreto de cliente y contraseña de usuario , que son muy diferentes.

El cliente es un / web / programa de aplicación / ..., respaldado por un servidor, que quiere autenticar a usuario por utilizando un servicio de autenticación de terceros. El secreto del cliente es una cadena (al azar) que se sabe que tanto el cliente y el servidor de autenticación. El uso de este secreto que el cliente puede identificarse con el servidor de autenticación, recibiendo autorización a las fichas de solicitud de acceso.

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

  • El ID de usuario
  • La contraseña de usuario
  • El ID de cliente
  • El secreto de cliente

Para obtener un acceso renovado de token sin embargo, el cliente utiliza la siguiente información:

  • El ID de cliente
  • El secreto de cliente
  • La actualización símbolo

Esto muestra claramente la diferencia: al actualizar, el cliente recibe autorización para tokens de acceso de actualización mediante el uso de su clave secreta de cliente, y puede por lo tanto volver a autenticar al usuario mediante la actualización símbolo en lugar de la ID de usuario + contraseña. Esto evita efectivamente que el usuario tenga que volver a introducir su / su contraseña.

Esto también muestra que la pérdida de un token de actualización no es ningún problema porque el ID de cliente y el secreto no se conocen. También muestra que el mantenimiento de la ID de cliente y el secreto de cliente secreto es importante .

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

La vida útil de una actualización de fichas es hasta el (AS) servidor de autorización - que pueden expirar, ser revocado, etc. La diferencia entre una actualización de fichas y un token de acceso es el público: la actualización token únicamente se remonta a la servidor de autorización, el token de acceso va a la (RS) servidor de recursos.

Además, sólo conseguir un token de acceso no significa que el usuario se ha conectado. De hecho, el usuario no podría ser incluso más allí, que es en realidad el caso de uso previsto del token de actualización. La actualización de la señal de acceso le dará acceso a una API en nombre del usuario, que no le dirá si el usuario existe.

OpenID Connect no sólo le dan información de usuario de un token de acceso, sino que también le da una ficha de identificación. Se trata de una hoja de datos que están dirigidas al propio cliente, no el AS o el RS. En PeDIP, sólo se debe tener en cuenta que alguien realmente “conectado” por el protocolo si se puede obtener un token de ID fresco. Refrescante que no es probable que sea suficiente.

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

Los clientes pueden estar en peligro de muchas maneras. Por ejemplo, un teléfono celular puede ser clonado. Tener un token de acceso caduca significa que el cliente está obligado a volver a autenticarse en el servidor de autorización. Durante la re-autenticación, el servidor de autorización puede comprobar otras características (OIA realizar la gestión de acceso adaptativo).

tokens de actualización permiten un cliente sólo re-autenticación, en tanto que las fuerzas de volver a autorizar un diálogo con el usuario que muchos han indicado que prefieren no hacerlo.

Actualizar fichas de ajuste esencialmente en el mismo lugar donde los sitios web normales podrían optar por volver a autenticar usuarios periódicamente después de una hora o así (por ejemplo, sitio de banca). No es muy utilizado en la actualidad ya que la mayoría de los sitios web sociales no volver a autenticar los usuarios de Internet, por lo que por qué iban a volver a autenticar un cliente?

Para simplificar aún más la respuesta de BT: Uso de actualización de fichas cuando por lo general no desea que el usuario tenga que escribir las credenciales de nuevo, pero todavía quiere el poder de ser capaz de revocar los permisos (revocando el token de actualización)

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

  

¿Por qué no hacer que el señal_acceso duran tanto como el refresh_token   y no tener una refresh_token?

Además de grandes respuestas que otras personas han proporcionadas hay otra razón por la cual sería utilizar tokens de actualización y su que ver con las reclamaciones.

Cada ficha contiene afirmaciones que pueden incluir cualquier cosa, desde el nombre de los usuarios, sus roles o el proveedor que creó la reclamación. A medida que se actualiza una ficha estas afirmaciones se actualizan.

Si refrescamos las fichas más a menudo obviamente estamos poniendo más presión sobre nuestros servicios de identidad sin embargo, son cada vez más precisos y reclamaciones en marcha hasta la fecha.

Suponga que usted hace la access_token durar mucho tiempo, y no tienen refresh_token, por lo que en un solo día, hackers conseguir este access_token y se puede acceder a todos los recursos protegidos!

Sin embargo, si usted tiene refresh_token, el tiempo en vivo de la access_token es corto, por lo que el hacker es difícil de piratear su access_token porque no será válida después de un periodo corto de tiempo. Access_token sólo puede ser recuperada mediante el uso de la espalda no sólo refresh_token sino también por client_id y client_secret, que hacker no tiene.

Mientras token de actualización es retenido por el servidor de autorización. Token de acceso son autónomos 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 de los puntos que faltan en la discusión es de rfc6749 # page-55

  

"Por ejemplo, el servidor de autorización podría emplear refresco símbolo   la rotación en la que un nuevo token de actualización se emite con cada acceso   token de actualización respuesta.El token de actualización anterior se invalida, pero   retenido por el servidor de autorización. Si un token de actualización es   comprometida y, posteriormente, utilizado tanto por el atacante y el   cliente legítimo, uno de ellos presentará una actualización invalidado   token, que informará al servidor de autorización de la violación ".

creo que todo el punto de utilizar token de actualización es que incluso si el atacante de alguna manera se las arregla para conseguir token de actualización, ID de cliente y la combinación secreta. Con las llamadas posteriores para conseguir nuevos token de acceso del atacante se puede seguir en el caso si todas las solicitudes de actualización en consecuencia nuevo token de acceso y actualización de fichas.

Esta respuesta ha sido elaborado con la ayuda de dos desarrolladores de alto nivel (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 ninguna clave de actualización y vamos a ir a través de este ejemplo:

Un edificio tiene 80 puertas. Todas las puertas se abren con la misma clave. La clave cambia cada 30 minutos.

Si yo soy el hacker y obtener su clave, luego, al final de los 30 minutos, voy a mensajería que a la keymaker y obtener una nueva clave. Voy a ser capaz de abrir todas las puertas de forma continua, independientemente del cambio de clave.

Pregunta: Durante los 30 minutos, ¿cuántas oportunidades piratería tenía yo en contra de la llave? Tenía 80 oportunidades de hackers, cada vez que utilizó la llave (pensar en esto como hacer una solicitud de red y pasar el token de acceso para identificar a sí mismo). Así que por la superficie de ataque 80X.

Ahora vamos a pasar por el mismo ejemplo pero esta vez vamos a suponer que hay una clave de actualización.

Un edificio tiene 80 puertas. Todas las puertas se abren con la misma clave. La clave cambia cada 30 minutos. Si yo soy el hacker y obtener su clave, puedo utilizarlo durante 30 minutos, pero al final de los 30 minutos de enviarlo a la keymaker no tiene ningún valor. Si lo hago, entonces el keymaker simplemente diría que esta clave ha caducado. Para poder extender mi truco tendría que cortar el servicio de mensajería a la keymaker. El correo tiene una clave distinta (pensar en esto como un token de actualización).

Pregunta: Durante los 30 minutos, ¿cuántas oportunidades piratería tenía yo contra el mensajero? 80? No. Yo sólo tenía 1 oportunidad piratería. Durante el tiempo en el servicio de mensajería comunica con el keymaker. Así que por la superficie de ataque 1X. Yo tenía 80 oportunidades contra la piratería la llave, pero no son buenos después de 30 minutos.

Un servidor verificaría un token de acceso basado en las credenciales y la firma de (normalmente) un JWT.

Un token de acceso fugas es mala, pero una vez que caduque ya no es útil para un atacante. Una fuga token de actualización es mucho peor, pero se supone que es menos probable. (Creo que hay espacio para la pregunta de si la probabilidad de una fuga token de actualización es mucho menor que la de un token de acceso fugas, pero esa es la idea.)

El punto es que el token de acceso se añade a todas las peticiones que realice, mientras que un token de actualización sólo se utiliza durante el flujo de refresco Por lo menos posibilidades de una MITM ver el token

Frecuencia ayuda a un atacante. heartbleed -como defectos potenciales de seguridad en SSL, los posibles fallos de seguridad en el cliente, y fallos de seguridad potenciales en el servidor de todos hacen posible fuga.

Además, si el servidor de autorización es independiente del servidor de aplicaciones de procesamiento de otras solicitudes de clientes a continuación, ese servidor de aplicaciones nunca ver tokens de actualización. Sólo se verá tokens de acceso que no vivirá por mucho más tiempo.

La compartimentación es bueno para la seguridad.

¿Qué símbolo de actualización no se trata de?

La capacidad de actualización / nivel de acceso de revocación a través de tokens de actualización es un subproducto de la elección de utilizar tokens de actualización, de lo contrario un token de acceso independiente podría ser revocada o tener su nivel de acceso modificado cuando se vence y los usuarios consigue un nuevo token”

Vayamos consideran un sistema en el que cada usuario está vinculado a una o varias funciones y cada función está vinculada a uno o más privilegios de acceso. Esta información se puede almacenar en caché para un mejor rendimiento de la API. Pero entonces, puede haber cambios en las configuraciones de usuarios y roles (por ejemplo, un nuevo acceso se puede conceder acceso actual o puede ser revocado) y estos se debe reflejar en la memoria caché.

puede utilizar el acceso y actualizar las fichas para tal fin. Cuando una API se invoca con el token de acceso, el servidor de recursos comprueba la caché de derechos de acceso. Si hay algún nuevas concesiones de acceso, no se refleja inmediatamente. Una vez que el token de acceso expira (decir en 30 minutos) y el cliente utiliza la actualización de contadores a generar un nuevo token de acceso, la caché puede ser actualizado con la versión actualizada del acceso de los usuarios información correcta de la base de datos.

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

  

En primer lugar, se autentica el cliente con el servidor de autorización al dar la concesión de autorización.

     

A continuación, el cliente solicita al servidor de recursos para el recurso protegido por dar el testigo de acceso.

     

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

     

El cliente realiza la solicitud de recursos protegidos en el servidor de recursos mediante la concesión de la señal de acceso, en el que el servidor de recursos valida y se atiende la solicitud, si es válido. Este paso mantiene repitiendo hasta que el token de acceso expira.

     

Si el token de acceso expira, se autentica el cliente con el servidor de autorización y solicitud de un nuevo token de acceso, proporcionando token de actualización. Si el token de acceso no es válido, el servidor de recursos envía de vuelta la respuesta de error invalid token al cliente.

     

Los autentica cliente con el servidor de autorización de concesión del token de actualización.

     

El servidor de autorización valida la actualización de token mediante la autenticación del cliente y emite un nuevo token de acceso, si es válido.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top