0

I am new to building API's and I am having trouble understanding how to perform the following task reasonably.

There is an endpoint:

/user/{user_id}

which retrieves the details of the user. The frontend code will request this endpoint to get details about the user to display on the dashboard. I have to protect this endpoint so that a user who doesn't represent this user_id, emulates the request to get information about other users.

Since REST based API's are sessionless, I cannot store session keys. So how do I make sure that the server sends the user information only if the owner of the user id has requested it?

conquester
  • 816
  • 1
  • 12
  • 35
  • Use [token authentication](https://stormpath.com/blog/token-authentication-scalable-user-mgmt). – James Oct 18 '17 at 07:39
  • More generalized answer will be here https://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service?rq=1. You can consider JWT (Json Web Tokens).https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3 – Kalpa Gunarathna Oct 18 '17 at 07:41

1 Answers1

1

You are right. HTTP is a stateless protocol, therefore REST inherits that quality too.

Here is the deal in simple words.

[REST client] -------> [API endpoint]

You have many REST clients, and you need to make sure that only authorized users will grant the access to your API endpoint. One solution as @James suggested is use a token mechanism such as JWT https://tools.ietf.org/html/rfc7519.

If you consider JWT authentication, the process flow will be as follows.

[REST client] -------> [AA service]-------> [API endpoint]

  • You will need an AA(Authorization, Authentication) service in the middle. For example in a microservices approach, this can be performed from a API gateway which is a gateway to all of your services.

  • Client will give AA service their username and password. In exchange AA service will give the client a JSON token signed only by the server so that the confidentiality is protected. This token contains 3 things.

  • Header which specifies the type of token and algorithms used to sign it

  • Payload which includes claims like to whom the token is issued, when should the token expire, what is issued user's role should be etc. (see https://tools.ietf.org/html/rfc7519#section-4)

  • Signature which a product of unsigned token signed by the server key

Then you encode each header, payload, signature with base64 and concatanate with a ".". You now have a JWT.

  • AA service returns this JWT in exchange for credentials.
  • Client should store this token securely (ex: local storage) and the communication medium should be encrypted(ex: TLS). See https://stormpath.com/blog/jwt-the-right-way#how-to-secure-jwt , https://tools.ietf.org/html/rfc7519#section-6

  • After that for every subsequent REST call, client should include the received token, preferably in the Authorization header although it is technically possible to send the token in the message payload as well.

  • Then it is AA service's responsibility to decrypt the token using its signing key evaluate claims in the JWT and act upon whether to authorize the API call send him HTTP 401,403 responses.

Kalpa Gunarathna
  • 824
  • 7
  • 16
  • If you use jwt tokens then user_id is not required to pass in API because token can identify user itself.You may have to change API. – Girdhar Sojitra Oct 18 '17 at 10:53
  • Not necessarily. User id is still needed to pass on to other services for querying purposes. For example a forum service needs a particular user id to list his answered/commented posts or comments. A notification service may need user id to send notifications to a particular user. But it is not necessary to send user id in the form of a JWT. – Kalpa Gunarathna Oct 23 '17 at 03:36