security - funciona - ¿Por qué OAuth v2 tiene tanto acceso como actualización de tokens?
oauth2 php (13)
¿Por qué no hacer que el access_token dure tanto como el refresh_token y no tenga un refresh_token?
Además de las grandes respuestas que otras personas han proporcionado, hay otra razón por la que usarían tokens de actualización y su relación con las reclamaciones.
Cada token contiene notificaciones que pueden incluir cualquier cosa, desde el nombre del usuario, sus funciones o el proveedor que creó la reclamación. A medida que se actualiza un token, estas notificaciones se actualizan.
Si actualizamos los tokens con más frecuencia, obviamente estamos poniendo más presión en nuestros servicios de identidad, sin embargo, estamos obteniendo reclamos más precisos y actualizados.
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é tienen ambos? ¿Por qué no hacer que el access_token dure tanto como el refresh_token y no tenga un refresh_token ?
Primero, el cliente se autentica con el servidor de autorización 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 otorgando el token de acceso, donde el servidor de recursos lo valida y atiende la solicitud, si es válida. Este paso se sigue repitiendo 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 el 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 mediante la autenticación del cliente y emite un nuevo token de acceso, si es válido.
A pesar de todas las excelentes respuestas anteriores, yo, como maestro de seguridad y programador que trabajé anteriormente en eBay cuando examiné la protección y el fraude del comprador, puedo decir que el token de acceso separado y el token de actualización tienen su mejor equilibrio entre el usuario acosador del nombre de usuario frecuente / ingrese la contraseña y mantenga la autoridad a mano para revocar el acceso a posibles abusos de su servicio.
Piense en un escenario como este. Se emite al usuario un token de acceso de 3600 segundos y se actualiza el token durante un día.
El usuario es un buen usuario, está en casa y enciende / apaga su 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 3-5 páginas solicitan cada minuto. Cuando finalizan 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 actividades y su dirección IP, pensamos que es un ser humano y se comporta a sí mismo. Le otorgamos un nuevo token de acceso para continuar usando nuestro servicio. El usuario no tendrá que volver a ingresar el nombre de usuario / contraseña hasta que haya alcanzado el token de actualización de un día.
El usuario es un usuario descuidado . Vive en Nueva York, EE. UU., Cerró su programa de virus y fue hackeado por un hacker en Polonia . Cuando el hacker obtiene el token de acceso y el token de actualización, intenta hacerse pasar por el usuario y utilizar nuestro servicio. Pero una vez que el token de acceso de corta duración expira, cuando el pirata informático 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 sólo 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.
El usuario es un usuario malicioso . Está destinado a abusar de nuestro servicio llamando 1000 veces 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 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.
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 a la 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 de token robado / abuso de servicio implementando en cada api, el perro 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 del servidor.
Consideremos un sistema donde cada usuario está vinculado a una o más 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 usuario y rol (por ejemplo, se puede otorgar un nuevo acceso o se puede revocar el acceso actual) y estos deberían reflejarse en el caché.
Podemos usar el acceso y actualizar tokens para tal fin. Cuando se invoca una API con el token de acceso, el servidor de recursos comprueba los derechos de acceso en la memoria caché. Si hay nuevas subvenciones de acceso, no se refleja de inmediato. Una vez que el token de acceso caduque (por ejemplo, en 30 minutos) y el cliente use el token de actualización para generar un nuevo token de acceso, la memoria caché se puede actualizar con la información actualizada de los derechos de acceso del usuario desde la base de datos.
En otras palabras, podemos mover las operaciones costosas de cada llamada de API usando tokens de acceso al evento de generación de token de acceso usando token de actualización.
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 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 al servidor de autorización para ver si el token de acceso es válido. Esto simplifica la validación del token de acceso y facilita la escala y la compatibilidad con 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 donde Resource Server y Authorization Server son la misma entidad, y donde la conexión entre el usuario y cualquiera de ellos es (generalmente) igual de 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 usuario pueda revocar el token de acceso en cualquier momento (a través de la interfaz web en sus perfiles) al mismo tiempo que mantiene el sistema escalable. .
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, con MAC , por ejemplo).
Cómo debería funcionar el sistema con tokens de acceso de larga duración
El servidor le 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 la marca "revocada" que está activada o desactivada (de lo contrario, ¿cómo haría eso con el 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. Si bien es bastante trivial realizar consultas a la 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 el token de actualización de larga duración y el token de acceso de corta duración
Aquí emitimos dos claves: el token de actualización al azar con el registro correspondiente en la base de datos y el token de acceso autónomo firmado, que contiene, entre otros, el campo de marca de tiempo de caducidad.
Como el token de acceso es autónomo, no tenemos que golpear la base de datos para verificar su validez. Todo lo que tenemos que hacer es descifrar el token y validar la firma y la marca de tiempo.
No obstante, 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 más larga 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 la SPoF (punto único de falla) de la base de datos del token de acceso, sin embargo, tienen algunos inconvenientes obvios.
La ventana". Un intervalo de tiempo entre los eventos "el usuario revoca el acceso" y "se garantiza que el acceso se revocará".
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 pídele 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 usando el token de actualización
- Si la solicitud de actualización se aprueba, actualice el token de acceso y vuelva a enviar la solicitud de API inicial.
- Si la solicitud de actualización falla, pídale al usuario que vuelva a autenticarse
Espero que esta respuesta tenga sentido y ayude a alguien a tomar una decisión más reflexiva. También me gustaría tener en cuenta que algunos proveedores OAuth2 conocidos, incluidos github y foursquare adoptan el protocolo sin tokens de actualización, y parecen estar contentos con eso.
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 regresa al servidor de autorización. el token de acceso va al servidor de recursos (RS).
Además, solo 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í, lo 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 proporciona información de usuario desde un token de acceso, sino que también le da un token de ID. Este es un dato separado que se dirige al cliente en sí, no al AS o al RS. En OIDC, solo debe considerar a alguien realmente "registrado" por el protocolo si puede obtener un token de ID nuevo. Refrescante no es probable que sea suficiente.
Para obtener más información, lea http://oauth.net/articles/authentication/
La idea de actualizar tokens 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 están comprometidos, son inútiles porque el atacante requiere el ID y el secreto del cliente además del token de actualización para obtener un token de acceso.
Dicho esto , porque todas las llamadas tanto al servidor de autorización como al servidor de recursos se realizan a través de SSL, incluido el ID del cliente original y el secreto cuando solicitan los tokens de acceso / actualización. No estoy seguro de cómo será el token de acceso " comprometible "que el token de actualización de larga duración y la combinación clientid / secret.
Por supuesto, esto es diferente a las implementaciones donde no controla los servidores de recursos y de autorización.
Aquí hay un buen hilo que habla sobre los usos de los tokens de actualización: Archivos de OAuth .
Una cita de lo anterior, que habla de los propósitos de seguridad del token de actualización:
Los tokens de actualización ... mitigan el riesgo de una pérdida de access_token de larga duración (parametrización 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 pone el access_token en un cookie, etc)
Los clientes pueden ser comprometidos de muchas maneras. Por ejemplo, un teléfono celular puede ser clonado. Tener un token de acceso caducado 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 verificar otras características (IOW realiza la administración de acceso adaptable).
Los tokens de actualización permiten que un cliente vuelva a autenticarse, mientras que la nueva autorización 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 pueden optar por volver a autenticar a los usuarios periódicamente después de aproximadamente una hora (por ejemplo, el sitio bancario). Actualmente 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?
Mientras que 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 la discusión es de rfc6749 # page-55
"Por ejemplo, el servidor de autorización podría emplear una 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 se invalida pero el servidor de autorización lo retiene. Si un token de actualización se compromete y luego lo utiliza "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 todo el punto de usar el token de actualización es que incluso si el atacante logra 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.
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 / actualizar-token enviando sus credenciales de cliente al servidor de autenticación, que es la forma en que 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 deberán usarse las credenciales del cliente para obtener un nuevo token de acceso y, por lo tanto, las oportunidades que tienen los atacantes para comprometer las credenciales del cliente (aunque esto puede ser muy difícil de todos modos) se utiliza el cifrado asimétrico 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.
Para aclarar algunas confusiones, 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 de usuario
- La contraseña de 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 la autorización para actualizar 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 de la ID de usuario + contraseña. Esto evita efectivamente 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 la identificación del cliente y el secreto del cliente es vital .
Para simplificar aún más la respuesta de BT: use tokens de actualización cuando normalmente no quiere que el usuario tenga que escribir las credenciales de nuevo, pero aún así desea que la potencia pueda revocar los permisos (revocando el token de actualización)
No puede revocar un token de acceso, solo un token de actualización.
Suponga que hace que el access_token dure mucho tiempo, y no tenga refresh_token, por lo que en un día, el hacker obtiene este access_token y puede acceder a todos los recursos protegidos.
Pero si tiene refresh_token, el tiempo de acceso de access_token es corto, por lo que el hacker es difícil de hackear su access_token porque no será válido después de un corto período de tiempo. Access_token solo puede recuperarse usando no solo refresh_token sino también client_id y client_secret, que el hacker no tiene.