I don't think you'll be able to do what you want without opening up all the CouchDB documents to all-comers.
The solution is, I believe, to only send back to the client this portion of the returned document URL:
dbname/path/to/file.whatever
And then keep your client talking with Server A:
https://Server A/get_document/dbname/path/to/file.whatever
Server A then just translates this to the return form Server B:
https://username:password@host:port/dbname/path/to/file.whatever
That way the client never needs to know about Server B, and Server B can be locked down away from prying eyes.
I'm afraid adding a Web Service layer is probably the correct solution to your problem.
Separating the client from the underlying database implementation will probably help you in the long run too.
Adding a web service layer doesn't necessarily have to hurt performance...
Indeed, with an appropriate API, a web service can actually improve performance, by batching together multiple database queries within the data center LAN, rather than requiring multiple round trips over the WAN.
And of course a web service layer can often be scaled horizontally, and add appropriate caching to your database queries, perhaps even a change notification mechanism.
A server layer adds security that you cannot possibly ensure with apps running on a remote client. Anything that runs on a client can be "hacked" and should not really be considered in any way trusted. You should only really put presentation logic in the client, and host anything important on hardware you have complete control of.
I don't know about your apps, but my web apps are naturally split into several layers, with the presentation code separated from the persistence layer by at least one level of business logic that keeps the two apart. I find this makes it much easier to reason about my app, and so much faster to add or modify functionality. If the layers are separated anyway, it is relatively easy to keep the presentation layer in the client, and the rest on a server under my control.
So while you can solve your problems without introducing a "web service" layer, by the time you have written all the stored procedures (or equivalent) necessary to fill in the holes in the standard database security implementation, you would probably be better off writing a server-side application that you can write proper unit tests for.
Best Answer
Depending on what you call a web service.
Before WSDL and REST, there was still HTTP, so basically everything you can do now could be done before as well.
There was a lack of uniformity (which is why WSDL and REST were created in the first place), but it provided the same level of data confidentiality and security you are talking about.
You can actually avoid using HTTP as well: you can draft your own protocol, and use a custom server and custom clients which would open a socket to this server and get the data they need (or post the data). Here, you lose all the standardization benefit of HTTP, but once again, you don't give access to the database to the clients.