http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy
Then as long as the client can keep its identification token secret from others, you can implement "user can only query their own blog entry"
I suggest you look into couchDB a bit further. CouchDB is a different beast altogether from relational databases. Therefore, the assumptions you make about what a database can and cannot do coming from a relational world doesn't always apply.
It's cool and all, but it sounds like you're still going to basically need a server stack there to enforce permissions and some logic and consistency things. For example, say users have some private data. What stops me from modifying the javascript to insert a record that points to someone else's email address in my record? Unless the database can see this and prevent it I might then be looking at or even able to change someone else's email on their account. It can get very hairy if you don't have full control over the database interaction because you have to start guarding against arbitrary database operations.
Doing per-user security directly in the DB with simple CRUD permissions per table would be enough of a headache, but most applications eventually require finer-grained security than that, and for performance reasons you also don't want a client to be able to execute just any arbitrary query.
It seems like this is pretty close to same trap a lot of people fall into of only enforcing data validation client-side, or only enforcing things like view permissions client-side (by not rendering links), which leaves all sorts of holes open.