Is a session token enough for critical applications

If you use cookies to store session ID's just make sure it is set in a cookie with the Secure and HttpOnly attribute. Restrict the domain and path attributes as much as possible. Make sure no untrusted web application is hosted on a related domain who could launch a session fixation attack. Set a reasonable expiration time for the session. Serve all your pages over HTTPS since mixed content might leak your session ID. Try to limit the externally loaded JavaScript libraries to minimize the attack surface.

Some application servers like Tomcat allow you to use SSL session ID's instead of session ID's stored in cookies. These SSL session ID's are better protected but you should be able to share the SSL session over multiple servers in your case.

A lot more tips can be found here: Session Management Cheat Sheet

EDIT:

They are no working on binding tokens like session ID's to a client via public-private key and signing. Read the draft here. It will take some time before it will be adopted by the major browser vendors but as far as binding a session ID to a client goes, this seems to solve all the issues. Of course there is some key generation and signing overhead and you require client support for this to work.

You need to ensure that

• you have an authentication information - your token for instance
• this authentication information cannot be guessed - the token must have, among others, a good enough entropy and atomicity (one token is generated independently from others, in other words knowing one token does not help you to know the next one)
• this authentication information cannot be fiddled with while in transit - use HTTPS

if you want to further restrict who can authenticate, use client side certificates (since you will be using HTTPS anyway) - they are likely to scale better than IP filtering.

As you mention, tokens are good enough for Google and other big players. They are therefore good enough for me as well.