I have an API communicating with my client, now I want to secure that API so that onlyu my client can use it. I am planning to do the following, since I have no experience in this I have gathered all this from reading up on the subject and I need advice, here is my flow:
- When a user signs in/registers, generate a token (ex: token = userId + date + radomvalue), save this token (hashed) in a DBtable together with userId.
- Send token (hashed) to client, save in preferences for later use.
- When calling API this token must be sent with the request, on server, we look through our token-table and see if we find the combination of userId+hashedToken, if we do, access is granted.
All communication is over SSL, here are my questions:
- What should I do about the TTL on my tokens? And what If I end up getting 3 000 000 users, that means that every call I make to the API it has to look through a table with 3 000 000 rows, is that ok?
- I obviously can't make my login/register endpoints require a token passed in the request to be accessed (since the client has not gotten it yet), is it okay to leave these "open"?
- Is it okay to send plain-text salt+password to api since it is SSL-protected, then hash it on server-side?
EDIT: 4. Thinking more on this, wouldn't someone just be able to grab their access token from the preference-file and make calls to my API from their own app, as long as they have the endpoint, and edit whatever they want on their own user?
Threat model: I am building a game. I have a database where I save ranking, experience, as well as what version of my game you have (free, no-ads, premium). After someone makes a purchase I call
endpointService.setVersion("userId", "PREMIUM");. This is the only real high value asset for me, since I don't want people to edit that themselves. I just want to protect my endpoints, but especially that one.