The session identifier IS sensitive enough. If you get this, you have access to the system with the victim's user profile. Do you really believe that developers implement additional session security if they fail to provide proper input validation? Most of the time - I don't think so.

Furthermore, "other" authentication is almost always more or less broken. The only way "other" authentication could work is to check the user's IP address (which by itself adds only a bit of security - think of a public WiFi, e. g. Starbucks) or browser features (which is not a reliable security factor as this can easily be spoofed).

So, authentication usually works by transmitting session identification cookies.

httpOnly and secure flags come to mind when trying to secure session ids, but XSS can also be used to modify the DOM on the fly and to inject a nice little fake login form that lets you steal the sensitive information in plaintext (with a bit of user interaction though).

What else can you do with XSS? Drive-by downloads exploiting browser plugins, exploitation frameworks such as BeEF, keyloggers etc.

Edit: Non-persistent XSS is surely less dangerous than persistent XSS, but nevertheless, it is a threat and most of the time, an indicator for a generally flawed Web application that should not be downplayed.

The session id is stored in the cookie. if you can read that, then you can convince the website that you are that user, and hence do (just about everything (depending on how often the website asks for password)) that that user can do on that website.