1

Let's say that my Rest api is secured using OAuth 2. Let's say my client is a mobile App. Let's say that i have an Api call:

@Post /increasePoints host:https://www.example.com/increasePoints  amout=10

Now Using this api call, one should have a valid Access Token. from my app i have control when to call this function so there is no problem. but Let's say the authenticated user get a hold of the access token. how can i stop him from posting to this api using his access token?

Few options that i thought of:

  1. sign each call with a special header.
  2. use client_authentication with scope points - i've just read about this type of authentication but the user can get the access token with same ease for what i understand.
royB
  • 227
  • 1
  • 9
  • If the user can get the access token s/he can get the special header too, no? – James McLeod Feb 16 '15 at 13:33
  • well, he can get the special header, but what if the signature is a one time? he should also find a way to calculate the header which is harder. i also prefer other means...will be happy to hear one (-: – royB Feb 16 '15 at 13:35
  • 1
    Don't offer such endpoints. For a game you could have a 'CreateGameInstance' endpoint that gives you a random seed and a 'RateGameInstance' that computes the score given the game instance and the List of player inputs. – Patrick Feb 16 '15 at 14:54
  • care to elaborate with an example? also what stops the user to call those api endpoints? – royB Feb 16 '15 at 15:08
  • REST is not RPC it binds the operations to the methods and not to the URIs. REST clients does not use access tokens, because the communication is stateless, they send username and password with every request in the Authorization header, or by 3rd party clients they send a signature with the request, which is generated by the service. – inf3rno Feb 18 '15 at 14:27
  • @inf3rno i think you should refresh your knowledge about Rest api. have a look at Facebook REST API and Google REST API to see that each call has an Authorization header with access token. beside the fact that your are wrong i didn't really understand what is the connection to my question – royB Feb 18 '15 at 14:32
  • The connection, that you tagged your question as REST, and your API is an RPC, which is not REST. (I guess I misunderstood what you called as an access token. It is probably the same as the signature I was talking about.) – inf3rno Feb 18 '15 at 14:37
  • Did you ever land on a solution? It seems most solves are basically: play on the server, it decides when to award points not the API call which seems the most complex. You could also sign each request with a shared secret and a timestamp. Send the signed payload to the server, it verifies the timestamp is not older than some threshold. This relies on having both device and server securely storing the shared secret. If the user has their access token they still would have the shared secret. Curious though if you found anything better? – AJ Venturella Jul 12 '16 at 10:46

2 Answers2

1

You simply don't give the user access to that API. For example, we have several web apps which uses access tokens and bill the user for certain actions. The billing system is centralised, and there's an app used by our customer services to add credits to the bills.

But there's no reason why the access token the end user gets to perform the actions on the app they are using should give access to the billing system, as that would mean they could add credits whenever they liked. The user's id is checked against a database of actions they can perform, and trying to add credits isn't one that's allowed. It seems you're in a similar situation, but haven't separated administrator actions from the end user's actions.

e.g. if you checkout in a online shop, then the action exposed is to checkout. There aren't separate 'send these items to me' and 'charge my paypal' in the api, though both happen on the server; the user can't do one without the other. The actions are located in the user's frame of reference.

Don't rely on your app to be the gatekeeper and increase points. Implement whatever action the user does to increase the points on the server instead, and it doesn't have to expose the sensitive action in the API. If you have some reason to expose the action for admin use then check that the user the token belongs to is an admin.

Pete Kirkham
  • 1,798
  • 14
  • 15
  • thanks for your answer. well the relevant part in your answer is to do implement the points increase on the server side, which already been done (-:. thanks. but it still don't answer how can i prevent a user from making REST calls that i do not want him to make – royB Apr 08 '15 at 15:08
  • @royB You can't stop users making calls. You check the token and get the user, and check whether that user has the access rights to make perform the action, then the response to the request is a non-authorized error. Also, design the API so the actions the user takes are at least power - there's no 'increase points' API, there's a 'charge my account $5 and increase points' API or 'perform this move in the game' API. – Pete Kirkham Apr 08 '15 at 15:27
0

You need to store the API token in your sever and need to validate it in database for each API call , So when u need to revoke access , remove the API token from the database , so it will invalid during next call

Ramesh
  • 146
  • 4
  • thanks for your answer ramesh. don't really understand how is it relevant... of course i have a validated oauth server as i've mentioned in the question – royB Mar 09 '15 at 13:24
  • you requirement is to stop accepting request from that api token? or stop the user requesting that specific api? – Ramesh Mar 09 '15 at 14:05