I have a ServiceCallContext object that must be passed in as the first parameter of any service call. I would like to put a User object on the context object but I know I can't force the caller to send back the User object they received from the service and I can't prevent them from filling that in with any information they like.

So as I understand it, I would need to use a security token (via something like OAuth) to authenticate them and would always need to look up any User information I need on the service side after authentication rather than putting it on the context object.

However, I know it's common to make a hash for a data file in order to verify that its contents haven't been tampered with. Would it be reasonable to do this for user information I put on a context object so that I don't have to make a call to the persistence layer for every service call? What are the risks of doing it that way?

2 Answers 2


A hash of the user's login information would essentially be a badly implemented security token. Since you still have to authenticate every single request, I don't see what you'd gain from rolling your own authentication. Use a well-tested solution like OAuth or XAuth.

You can easily and securely stop "middle men" from tampering or eavesdropping by using HTTPS.

  • 1
    I would probably still use a security token from something like OAuth to authenticate them. The real idea here though is to prevent having to make a call to the database for user information that you could put on the object. Or more generally, to be able to give someone any kind of data and be able to verify they haven't tampered with it when they send it back to you.
    – BVernon
    Jan 24, 2015 at 22:33
  • 1
    By the way, Information Security StackExchange has loads of excellent questions and answers on stuff like this (such as this one about what SSL protects against). You can probably find far more thorough answers over there, but they'll definitely tell you never to roll your own implementation of something that's meant to be secure.
    – Ixrec
    Jan 24, 2015 at 22:35
  • @BVernon I was trying to imply he should use OAuth instead of no authentication or rolling his own authentication. Editing to clarify.
    – Ixrec
    Jan 24, 2015 at 22:36

Once you perform the expensive function (authenticating a user) you would setup a token that is stored in a much faster, and less expensive place (ie- Memcache).

That way you always re-authenticate the user on every request and you're able to automatically force a full re-authentication by flushing the memory for any users with a current session.

You could also store all the user's data that you will require on every service call in Memcache (or similar) for a fast retrieval.

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.