How to prevent Rest web-service Authentication with stolen Token

Hemant Metalia :

As we know Rest services are stateless, General strategies to authenticate is using a token based authentication.

In login service it takes credentials which returns a token.

This token might be set in client cookies, and all subsequent requests uses this token to be validated and process new request if token is valid.

Now my question is how one can validate the token ? If someone has stolen the token and tries to access rest services with stolen token by just editing cookies then how can it be identified and restricted ?

We can never know if the token is fetched by valid user and same user is trying to access subsequent request. but what are the possible ways to make it more hard, like to verify if the request has came from same source ?

One general suggestion is to set aging for token/cookies, but it still not helpful till the age of that token/cookies.

Any suggestions would be appreciated.

Hemant Metalia :

After struggling through various approach We found a solution explained below:

  1. We store token (encrypted) in cookies on login request and for each subsequent request this cookie gets validated.
  2. The problem was if someone replace the token in cookie with another valid token, as cookies are maintained by client browser.

Solution :-> Though token values were encrypted, it was representing only one value, So if one replace whole encrypted value with another valid encrypted value it can be hacked.

So to solve this we have added another cookie which was combination of multiple values.

e.g.

Cookie 1 -> encrypted token

Cookie 2 -> An encrypted object containing information like username+ some other user context details+token

So in case of Cookie 1, it was easy to replace with another encrypted value as it was representing only one token though it was encrypted.

But in case of Cookie 2, it was containing object with multiple values, so only token value can not be modified, encrypted and set back in same cookie.

Before authentication We are doing decryption whole cookie 2, fetch token part from it and validate the token part of it against cookie 1.

That has solved our problem !!

Thanks all for your time and guidance.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=418523&siteId=1