Over the last few months I have become familiar with OAuth2.0 authorization within google apps script but a recent anomaly has me confuzzled. I have a standalone web-app that acts as a front-end to a fusion table. The web-app is set to 'execute as' the script and fusion table owner and the fusion table grants view access to external users. The program detects authorization, prompts if needed, and uses refresh tokens if they're available. When run from the account that owns the script and fusion table, all is well.

Once I published the web-app, I tested it from an external account and it worked fine. The refresh token was then removed from the script-owner's UserProperties. When the app was run again from an external account, it prompted for authorization and authorized correctly (saving the new tokens in the UserProperties of the script-owner). However, the next POST call to the API received a 403-Forbidden error. At this point the app will continue to receive 403-Forbidden errors from any account (including the script-owner's account) until the tokens are manually cleared and reauthorized as the script-owner.

Why is it that these tokens are not valid? I would expect that since the app is being 'executed as' the script/fusion owner, any tokens received programmatically would be as valid as those those authorized by the script/fusion owner. If my expectations are incorrect, how can I protect against this situation for multiple users?

Update

I've gained some more traction on this and have identified some related issues that I wanted to share here. First of all, I was manually deleting the tokens (refresh and access) to test the ability of the app to authorize. Subsequent authorizations were not returning a refresh token (which caused excessive prompting). I found out that this is an intentional outcome from the google API. Aside from the requisite request parameters to return a refresh token, I found out that a refresh token is only returned on the first user-prompt and authorization(ref. here). In order to get another refresh token, you need to either revoke-acess and re-authorize or force the approval prompt in the request. Once I fixed that it became much clearer that the token was 'attached' to the user making the initial authorization request. As long as I retained the refresh token acquired by the script/table owner, then the script could be used (and reauthorized programmatically using the refresh token) by any external user. Which brings me back to the point. If I lose the refresh token, I need to manually delete all remaining token scraps, login as script/table owner, revoke access to the app, then reauthorize.

Per Zig's answer below, that is just how it is. Is there no way I can programmatically prevent that very manual process?

Script executing as owner will save owner tokens automatically through appscript builtin authentication. However if you are doing the oauth flow yourself, it will save the user's token and thus wont have access to your data.