The best way to authenticate a web-server is through a third party agent such as OpenDirectory (LDAP).   Procedures for doing this vary from server to server, and company to company.

If the app must present some kind of identifying token, it should be a token that only has meaning when presented by this server at this IP.   (For example, when the connection wants to align itself to what it has been GRANTed to do, if different levels of database privilege are obtainable at different times.)  It must be utterly worthless if stolen.   The third party (LDAP) vouches for both servers, one to the other.

I do not mean to be condescending if I go on to state that, in an “intranet” setting, LDAP should be used to authenticate and to authorize the connecting web-users also.   The web server can restrict access to an entire site (or any portion thereof) based on the LDAP settings of the connecting user, and can reliably use group-membership etc. in its own code, without bothering with any sort of separate password-system of its own devising.   The same (trustworthy) credentials can be presented to the database servers and so on.   If the connecting user is coming in “from the Internet,” then the user’s identity cannot be strongly trusted, but the database server can nonetheless trust the web-server to some degree, although not to the degree that it could trust a (separate...) web-server that it knows can only be reached from “inside.”   In any case, the use of “passwords” is not appropriate, unless those passwords are configured such that they are useless if presented by any party other than the designated web servers ... a determination that should be made, once again, by a centrally-managed authentication authority, i.e. LDAP.   (And if all of this preceding ¶ is “old news to you,” ... well, of course it is ... of course.)