3

Scope

Currently we are developing a backend REST API which is consumed by handful of MVC applications. In this case we are talking only about server-server communication and the API won't be consumed by any user directly. The environment is purely on Windows Server and it's to mention that there are no plans at the moment to use active directory.

What is the best way to authenticate a server application (MVC) to the backend API?

Considering everything is done over https, at the moment we considering either client certificate or token based authentication (via Basic / Bearer).

With both of those approaches a lot of pros and cons emerge and I really would like your help to verify, correct and maybe complement them.

Token-Based Authentication

  • Scales well in case we decide to use it for other parts aswell
  • No client certificates (installation, renewal)

Client Certificate Authentication

  • Wide spread in the enterprise environment
  • Well established
  • Manageable amount of clients
  • Considered by many as one of the securest option
  • No single point of failure (self hosted identity server)

Conclusion

I am pretty sure I've forgot some important ones and I appreciate any kind of input.

In addition, given the scope above which approach would you opt?

Improve this question
4
  • Will the backend be accessible from the client or protected by firewall rules ? - does not really matter whether it is accessed in normal operations...
    – Serge Ballesta
    Jun 26, 2017 at 8:12
  • There could be a firewall between but everything is done over http which shouldn't pose a problem I guess. The user part was mentioned, because client certificates wouldn't be feasible for a wide audience of endusers.
    – HansMusterWhatElse
    Jun 26, 2017 at 8:19
  • 1
    Is the server-to-server authentication based on a one-time server registration (per server)? Or is it like a typical OAUTH flow where a user authorization enables per-user data to be shared by a 3rd party with your server?
    – Sas3
    Jun 26, 2017 at 9:17
  • That hasn't been decided yet. What are the current best practises for this? To request a token previously to the setup and store it somewhere on the disk of the consuming MVC application (would require a rather long expiration date)? Otherwise have some kind of "prefetch token" mechanism, which gets called each time the token is invalid (would allow a lower expiration date and thus leave a limited attack window), In the end we just need a mechanism to authentication / authorise our MVC applications and according to that give them dedicated access privileges to different REST APIs.
    – HansMusterWhatElse
    Jun 26, 2017 at 9:28

1 Answer 1

Reset to default
1

My advice would be to not worry about authentication between the frontend servers and the backend one, but to setup a secure channel between them. From an architectural point of view, this means setting all those servers in the same security zone, and prevent any external access to the backend. From there on, if one front end server submits a requests to the backend, it just passes the user id, and the backend will trust that because the request can only come from a trusted server.

This is common in medium to large computation center: the user authentication is done by the MVC servers or in case of X509 certificate authentication by reverse proxies, and the other servers just trust what has been put in the request by the first server that did the authentication.

Improve this answer
4
  • 1
    You'd rely on what, the IP of the server? In case of spoofing, I'd use HTTPS for this at least. Or better yet, a proper public key authentication system over HTTPS.
    – Awn
    Jun 26, 2017 at 10:27
  • @Awn: I would rely on a physical network with only one external gateway and a correctly configured firewall if the machines are on the same physical netword. If they are not, I would only rely on a secure VPN.
    – Serge Ballesta
    Jun 26, 2017 at 10:33
  • That's a lot of things to worry about for your security setup to work correctly. Simplicity is key.
    – Awn
    Jun 26, 2017 at 19:33
  • And how will it work when some day you decide to have some public API? Will you create one more frontend-wrapper handling all authorization stuff and then just redirecting the very same calls to the real backend? What will you do when some user will try to "hack" request from public website i.e. by changing ID of item to delete? So you still have the need to perform auth check somewhere. And if it's done in frontend, it looks not really good solution IMO
    – The Godfather
    Oct 16, 2018 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .