0

I'm in the process of developing a system which is heavily dependent on a web service which is designed according to REST principles. The connection is over HTTPS, and my issue is finding a good way to identify clients. There are several users from several different companies with several different access levels.

The backend/middleware is written in PHP, and up until now, I have used the $_SESSION to identify users.

After reading more about REST services, I learned that REST services should be stateless and every call should provide all information necessary to handle that call. I interpreted this in the direction that the server should not maintain any states related to specific clients.

Questions:

  1. Does this mean that using $_SESSION[some_identifier] to preserve state between calls is not aligning with the REST style?

  2. I'm now considering using a "short-lived token" logic instead. This token is exchanged with the server on each request, and the server provides a new token in the reply of each request. Is this approach more RESTful?

matfax
  • 634
  • 11
  • 17
martinethyl
  • 184
  • 1
  • 12
  • There are many ways to do that, which depend on your application, how secure you need it to be, your threat model... What you describe is not great because it forces the client to constantly save tokens from previous requests. It's also not safe against replay attacks. Have a look at the method described there, which is a bit similar to OAuth: http://stackoverflow.com/a/11028528/561309 – laurent Mar 13 '17 at 13:52
  • ok...this seems to be what i'm looking for...but then i need to generate a private/public key pair for each client? the API key mentioned can be constant for all users i guess....but maybe also be provided based on user access levels? – martinethyl Mar 13 '17 at 14:11
  • You would generate an API key *and* a Secret for each client. The API key tells you which client is issuing the request. From this your can retrieve their associated secret key and authentify the request. – laurent Mar 13 '17 at 14:36
  • ok,yes,i understand. the client will then keep the API key and the secret for the duration of one session and the API keys can be connected to a given "access level" on the server. i will try this! thanks! – martinethyl Mar 13 '17 at 16:01
  • a concern i have is that the API key and the secret would be in clear text on the client after being fetched from the network. But this is probably not considered a problem? – martinethyl Mar 13 '17 at 16:15

1 Answers1

0

You should be using the Authorization HTTP header, used by various HTTP authentication systems such as Basic, OAuth2, or your own proprietary extensions.

Evert
  • 93,428
  • 18
  • 118
  • 189