OAuth2 Flujo implícito. Protección adicional para access_token de intercepción

Tenemos una aplicación de JavaScript de una página que autentica al usuario en nuestro servidor mediante el protocolo OAuth 2.0 (y el complemento AddId-Connect). Después de la autenticación, el servidor emite un access_token a la aplicación. Suponemos que access_token puede ser interceptado usando escenarios de ataque que no tomamos en cuenta al organizar nuestro sistema de seguridad.

Todos nuestros servidores utilizan TLS , y tenemos 2 escenarios de autenticación:

1. Usuario de Internet:

1.1. El usuario hace clic en el botón Iniciar sesión en la aplicación JS.

1.2 La aplicación abre una ventana emergente Js-Applicion con la URL generada "/ authorize" para el servidor de autenticación.

1.3. El servidor de autenticación verifica los parámetros en la solicitud de acuerdo con las especificaciones y redirige al usuario a la página de inicio de sesión.

1.4 (se puede omitir si el usuario se ha autenticado en el servidor de autenticación). El usuario proporciona credenciales y hace clic en "iniciar sesión".

1.5 Después de iniciar sesión correctamente, el usuario será redirigido a "redirect_uri" desde el parámetro de consulta, el token de acceso se configurará en el parámetro Obtener solicitud después de #.

1.6. Después de la redirección, la aplicación lee el access_token de los parámetros y lo coloca en el almacén de la sesión.

1.7. La aplicación JS pasará este token en el encabezado de autenticación con cada solicitud al servidor de recursos.

1.8 El servidor de recursos valida el token sin solicitudes adicionales al servidor de autenticación.

2. Usuario de la intranet:

1.1. El usuario hace clic en el botón Iniciar sesión en la aplicación JS.

1.2 La aplicación abre un i-frame oculto y carga el servidor de autenticación de punto final para la autenticación de Windows.

1.3 El servidor de autenticación verifica los parámetros de solicitud de acuerdo con las especificaciones.

1.4 * algo de magia aquí con windows auth y redirecciones locales **

1.5 En caso de una autenticación exitosa, el servidor de autenticación redirige al usuario a la dirección especificada en la solicitud de Obtener y especifica en los parámetros de la solicitud de access_token.

1.6. Después de la redirección, la aplicación lee el access_token de los parámetros y lo coloca en el almacén de la sesión.

1.7. La aplicación JS enviará este token en el encabezado de autenticación con cada solicitud al servidor de recursos.

1.8 El servidor de recursos valida el token sin solicitudes adicionales al servidor de autenticación.

Ejemplo de redireccionamiento de uri: https://localhost:44300/popup-callback.html#id_token=NWrvGKVPTnw_shorted&access_token=eyJhbGciOiJSUzI_shorted&token_type=Bearer&expires_in=3600&scope=openid%20profile%20api1&state=46c8484e5e1b4a1f8bd182891efd7180

Preguntas :

1. ¿Hay una manera de enlazar un token a un usuario específico para que esté protegido contra la intercepción?

2. Si agregamos el enlace de access_token a la dirección IP del usuario, esto complicará el problema al atacante y ¿cómo afectará esto a la seguridad del sistema?