3

I have a website with an already-established authentication system. Once a user logs on to it, one of the features is a statistics application based on AngularJS.

The app communicates with an external REST API (built on Spring) that basically just provides 3 functions:

  1. Receive a GET request, prompting it to retrieve the requested statistics from a database and send them back to the front-end application
  2. Receive a POST request, allowing users to save a few configurable options into the same database. So the options table in the DB would hold the user ID of the requester and several optional values
  3. Receive a GET request to retrieve those options at a later date

Security-wise, the website and application front-end are covered, but I now need to secure the web service and, due to lack of knowledge of the subject, I cannot figure out the best method.

I basically need to make sure that any requests to the web service come from an authorised source (i.e. an authenticated user of the website) and also that any requests involving user-specific info (points 2 and 3 above) actually came from that user.

Note that it doesn't have to authenticate against some configured list of users on the the web service side, but if a request arrives saying "give me user1's options", it has to be user1 who is requesting that.

Options I've investigated so far:

  1. SAML - Which seemed like a good fit initially but doesn't really seem applicable to REST web services after all
  2. HMAC - Could I make the application send a key based on some combination of the user id and web application id that could only be decrypted with a salt at the web service end? So when it is decrypted, the application id can be confirmed and also it can be verified that the user id in the encrypted key matches whatever was passed in the "userid" parameter of the request?
  3. SSL - Am I just overthinking this whole thing? Could I simply use a certificate in the web application that is trusted by the API and therefore confirms that the request came from the application and could not have been manipulated in any way?
1
  • I am curious, which solution did you use sir?
    – Malky.Kid
    Commented Jun 19, 2017 at 2:03

1 Answer 1

1

This is a very old question, but I thought of giving it a bit of attention, since there are a couple of solutions for this problem and one of the simplest ones is to use a JWT or other kind of signed token, which can be easily verified for tampering at the service level, provided it has the necessary key.

You can read more on JWTs at https://jwt.io

The idea is similar to your suggestion #2: generating a token with the user ID and other needed fields, which is signed with a private key. If the token is manipulated in any way, the signature will not match when validating the token, so you know that tokens can be trusted if they pass validation.

You can also make those tokens temporary (say, for a reasonable amount of time that users usually need to access the service), which would prevent leaked tokens from being exploited for a long time. The solution also allows to rotate the signing key, in case it gets compromised, invalidating all existing tokens.

There are many libraries available out there for every popular language. Don't try to roll your own implementation or you may end up missing some details that battle tested solutions already got solved and open up your system for exploitation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.