The point of this blog is to help you understand your options when configuring OWA to work with external users.
There is one major configuration issue with this, that is that office web app calls need to be passed through, seemingly, without being challenged. In lync 2013 there are articles that talk about the configuration of your TMG reverse proxy. It is suggested that you leave the web apps portion accessible anonymously. This is considered acceptable because if everything else is https that leaves very little in the way of security vulnerabilities.
The reason for this is because office web apps need to be able to communicate via OAuth from client to host (user pc to sharepoint).
The above just means that your web apps calls need to be anonymous OR they can be pre-authenticated(so any auth challenge is passed along without issue).
So if you’re using sharepoint and your users are logging in there first you just need to make sure that the session cookie issued applies to your web apps as well. This should stop a second authentication attempt from taking place.
Best way to test this is to first go to your hosting/discovery page via http(s)://<wacexternalurl>/hosting/discovery, you should see something like the below.
If you get an auth page then you want to test by first going to your sharepoint site > leave that page open >then test the above. If you have a session cookie configured correctly it should open without issue.
If you still get redirected to an authentication page then you want to look at the security token being issued by your authentication provider. Whatever is being issued isn’t covering the traffic to the web apps server as well.
If you can get the above to work, but are still having issues try reaching the http(s)://<wacexternalurl>/op/generate.aspx page. This page allows you to test a client machines ability to display rendered owa documents.
Once you’ve configured your security to allow for seamless travel with pre-auth or anonymous you should be able to now view documents in browser.