For a web app, the client side is javascript in the browser. The server side is ASP.NET with a REST API. At present there is a single server but we plan to scale out with a server each in the US, UK, and AUS (on Azure). We'll have redis (but that does not sync up instantaneously). They will (almost) always be using SSL.

When a user logs in, we authenticate them. It's easy to pass back the primary key of that user record in the DB and on subsequent calls in, pass that PK to identify the user. It's also trivially easy to then impersonate any user.

What's the best way to implement this? The two things I have thought of are:

  1. Return a guid and require that guid on all subsequent calls.
  2. Store the PK in the Session data on the server side and use that to identify the user on all subsequent calls.

Both of the above work if an existing session continues to go to the same server (which I believe it does) for each subsequent request.

So, what's the best way to do this? Either of the above two? Or is there another approach that's better?

thanks - dave

  • Isn't sessionID used for this very thing? You have a table to match the ever-changing sessionID with the user ID.
    – schroeder
    Commented Jan 20, 2015 at 22:01
  • @schroeder - That's what store it in the Session is. The sessionID in ASP.NET is used to tie to a Session dataset you can put stuff in. Commented Jan 20, 2015 at 22:03
  • Why not just use the built in .NET membership sessionID? You don't even have to worry about sending it back. Once they are authenticated .NET manages it for you. And how is it trivially easy to impersonate any user? How would you ever see someone else's key without breaking SSL?
    – TTT
    Commented Jan 20, 2015 at 22:06
  • @TTT That is my option #2 above. Is that a good way to handle this even when scaled out? Commented Jan 20, 2015 at 23:42

1 Answer 1


In ASP.NET you can keep the session in a data store instead of in memory, this is useful for load balanced deployments. The session can be kept in SQL and I have also found an example of using Redis to store it so retrieval is faster.

So in your case I would use ASP.NET authentication and then use the session to keep the primary key you mentioned in order to recognize the user.

Not the answer you're looking for? Browse other questions tagged .