¿Por qué oAuth y oAuth 2 tienen tokens de acceso?

4

Estoy intentando implementar un sistema para que aplicaciones de terceros accedan a los datos que un usuario almacena en un proveedor. Tenemos un sistema de control de acceso robusto, con lectura / escritura / etc. niveles para cada "flujo" de datos publicados por un usuario. Dentro de nuestro sitio web, estos niveles de acceso ya se aplican según el usuario que intente realizar qué acción con la transmisión de otro usuario.

Ahora llega el momento de permitir que las aplicaciones de terceros hagan lo mismo, de una manera compatible con oAuth2. Actualmente representamos aplicaciones de terceros dentro de la base de datos de la aplicación del proveedor como usuarios regulares con un ID de usuario, URL canónica, etc. Por lo tanto, este ID de usuario sería el ID de cliente de la aplicación.

Mi pregunta es, ¿por qué oAuth tiene tokens, que son esencialmente cadenas opacas que se asignan a registros (user_id, client_id) que tienen (alcance, etc.)?

¿No puede la aplicación simplemente identificarse con el client_id como su clave api y firmar sus solicitudes con un secreto simétrico, para las solicitudes de servidor a servidor? Estas solicitudes y respuestas firmadas pueden transmitirse a través de un agente de usuario si es necesario, si existe un requisito adicional de que un usuario esté en línea cuando se conceda la solicitud.

El proveedor ya almacena los registros de acceso para (user_id, client_id), por lo que sabe si aprobar o rechazar una solicitud de la aplicación cliente. ¿Por qué la aplicación cliente necesita almacenar y escupir fichas extra?

Lo único que se me ha ocurrido hasta ahora es que esto es aumentar la seguridad en caso de que alguien obtenga acceso no autorizado al secreto simétrico de la aplicación del cliente. Y de esta manera, el ataque se limitaría a cualquier token que pudieran obtener (ya que los tokens se requieren como una credencial adicional). Parece que en el lado del servidor, si alguien obtiene el secreto simétrico, probablemente también obtenga las credenciales de la base de datos. Así que esto no es una gran ventaja.

¿Hay alguna otra razón? ¿O fue solo teatro de seguridad?

    
pregunta Gregory Magarshak 11.06.2017 - 18:58
fuente

1 respuesta

5
  

quizás esto es para aumentar la seguridad en caso de que alguien obtenga acceso no autorizado al secreto simétrico de la aplicación del cliente.

Esa es una razón válida, sí. El envío de tokens de acceso de corta duración en lugar de secretos compartidos de larga duración reduce la superficie de ataque.

  

¿Hay alguna otra razón?

OAuth define varios roles. A menudo, un recurso no reside en el mismo servidor que maneja la autenticación y / o la autorización. Un token puede generar un token de acceso y otro puede consumirlo, que en realidad no sabe quién tiene autorización para qué. Es posible que un servidor de recursos no sepa qué usuarios tienen acceso a qué recursos, pero al recibir un token de acceso válido por parte de un servidor de autorización, puede tomar una decisión sobre la concesión de acceso.

Piense en el control de acceso en un edificio (o en la frontera de un país): es posible que el guardia de la entrada no tenga una lista de todas las personas permitidas en el interior y que nunca lo haya visto antes; pero si le muestra una tarjeta de acceso válida para el área restringida (o el pasaporte en el ejemplo del país), sabrá que debe dejarlo entrar.

Esto también tiene algunas desventajas. Si se revoca el acceso, pero puede conservar su tarjeta de acceso, es probable que aún pueda ingresar, incluso si no se supone que lo haga más. Esto se puede contrarrestar al poner una fecha de vencimiento en la tarjeta de acceso, y es por eso que los tokens de acceso suelen ser de corta duración, por lo que incluso si son robados, no se pueden usar por mucho tiempo.

    
respondido por el Pascal 11.06.2017 - 21:33
fuente

Lea otras preguntas en las etiquetas