Suppose we have 2 webapps, appA and appB. They communicate via REST. Say for example, when appA updates let's say, a file, it should inform appB via REST and so on.
I was thinking, how do I make this secure? I mean, what if an ordinary user got the api url and started sending requests? I was looking around the internet and I found out I could secure this through tokens, but how do tokens make it secure? I mean, what if the user got hold of the token and the api url? Wouldn't that be game over?
You must use SSL. If you don't - no matter what other security scheme you select - it will be prone to sniffing and hence the bypass of your security mechanism. For example an attacker by utilizing DNS poisoning will make your AppA think it is talking to AppB and send the token to the attacker... from there your whole security mechanism is broken.
SSL will provide you with both authentication of your application to the API and confidentiality + tamper resistance of your data between the app and the API
In SSL you can configure two way authentication, which means that beyond AppA being sure it is talking to AppB, also AppB can be sure it is talking to AppA. This is done by configuring SSL to request also client certificate in the SSL handshake. That is your best option. I would not risk trying any self made security protocol instead.
If the user is skilled and owns the device where the app lives, you can forget about securing it. The user could access any local storage, run the app in a debugger, use reverse engineering tools, etc. So if we take this as a given. You need to look carefully at what you are trying to protect. If you assume that the app can be made to serve the user and go from there, you need to look at what needs protecting from the user and see if you can mitigate that by attenuating these powers to the extend that still allows the app to function but without the full impact in case of an unfriendly user. You may also want to look into server side detection of unexpected API usage of the kind that the app should not be able to produce. You could use that detection in combination with token revocation. Basically you should protect your app and its user from snooping by using TLS 1.2, disabling any pre 1.2 cipher suites and using sparse non-guessable tokens. Don't forget to check server certificate validity and issuer. You should make your tokens revocable and you should try to help your user in keeping your tokens from being red by malicious 3th party applications. You should not invest in DRM like technologies that try to protect the tokens that ultimately are the users tokens for your app from being accessed by your users. A persistent user will always find a way to get to those tokens if he wants to, its his machine. A well designed least authority based system design should make that it really does not matter if the user himself or your app is accessing your services. Don't fall into the DRM trap. DRM is both evil when carried out to the extreme and futile when done in any other way.
There are several ways to do this:
Secure communications: Set up an authenticated tunnel between appA and appB. This could be done with Client certificates over an HTTPS connection. AppA knows it is really talking to AppB, and AppB knows that it's really AppA that's talking to it. This way, you don't have alter any source code.
If your apps are on static IP addresses, you could even do URL filtering based on source IP address. (I.e: only 1.1.1.1 can access https://appb.com/api_call)
Using a token. As you stated, a token is more used liked a "secret", i.e: it should be very difficult to guess. Only if appA does a request and has the correct secret value, then the request is honored; else it's dropped. It's easier to implement, but if somebody derives that value, he/she will be able to issue requests.
Bottomline, it's good to do "defense in depth", if you can combine both, then you'd have a pretty secure system. Then instead of "if an attacker has the token value", you'd be worried about "if the attacker has the same IP address, client certificate and the token value" - which is less likely to happen. Unless he has compromised AppA's servers.
