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?
security
oauth
access-token
refresh-token
Dave Mankoff
fuente
fuente
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:
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.
La ventana". Un período de tiempo entre los eventos "el usuario revoca el acceso" y "se garantiza la revocación del acceso".
La complicación de la lógica del cliente.
sin token de actualización
con token de actualización
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.
fuente
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.
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.
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.
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.
fuente
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.
fuente
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:
Sin embargo, para obtener un token de acceso actualizado, el cliente utiliza la siguiente informació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 .
fuente
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/
fuente
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?
fuente
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.
fuente
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.
fuente
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
fuente
Suponga que hace que el
access_tokenúltimo sea muy largo y que no lo haya hechorefresh_token, así que en un día, ¡el pirata informático obtendrá estoaccess_tokeny podrá acceder a todos los recursos protegidos!Pero si lo ha hecho
refresh_token, elaccess_tokentiempo de vida es corto, por lo que es difícil piratear al pirata informáticoaccess_tokenporque no será válido después de un corto período de tiempo.Access_tokensolo se puede recuperar usando no solorefresh_tokensino también conclient_idyclient_secret, que el hacker no tiene.fuente
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
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.
fuente
A 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.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.
fuente
fuente
access token + refresh token?