2

We have a one-page JavaScript application that authenticates the user on our server using the OAuth 2.0 protocol (and the AddId-Connect add-in). After authentication, the server issues an access_token to the application. We assume that access_token can be intercepted using attack scenarios that we did not take into account when organizing our security system.

All our servers use TLS, and we have 2 authentication scenarios:

1. Internet user:

1.1. The user clicks the Login button in the JS application.

1.2 The application opens a Js-Applicion pop-up window with the generated URL "/ authorize" for the authentication server.

1.3. The authentication server checks the parameters in the request according to the specifications and redirects the user to the login page.

1.4 (can be skipped if the user has been authenticated on the auth server.) The user provides credentials and clicks "login".

1.5 After successful login, the user will be redirected to "redirect_uri" from the query parameter, the access token will be set in the Get request parameter after #.

1.6. After redirection, application read the access_token from params and place it in the session store.

1.7. The JS application will pass this token in the Authenticate header with every request to the resource server.

1.8 Resource server validate token without additional requests to authentication server.

2. Intranet user:

1.1. The user clicks the Login button in the JS application.

1.2 The application opens a hidden i-frame and loads the end-point authentication server for Windows authentication.

1.3 The authentication server verifies the request parameters in accordance with the specifications.

1.4 * some magic here with windows auth and local redirects **

1.5 In case of successful authentication, the authentication server redirects the user to the address specified in the Get request and specifies in the parameters of the access_token request.

1.6. After redirection, application read the access_token from params and place it in the session store.

1.7. The JS application will send this token in the Authenticate header with every request to the resource server.

1.8 Resource server validate token without additional requests to authentication server.

Redirect uri example: 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

Questions:

  1. Is there a way to bind a token to a specific user so that it is protected from interception?

  2. If we add the binding of the access_token to the user's ip-address, this will complicate the problem to the attacker and how will this affect the security of the system?

  • 2
    You will need to provide more details about your scenario for any meaningful answer on your first question. However, binding a user to an IP is bound to cause problems; IP addresses can (and do) change, even during a session, for a whole bunch of reasons. – Jacco Mar 14 '18 at 9:31
  • 1
    @Jacco, I edit my question. Sorry for the bad english. – V. Dmitriy Mar 14 '18 at 10:12

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.