I can suggest an approach that I believe should reduce the risk of clickjacking, but it means suggesting to implementations that any requests that return a dialog or preview URI (that is, requests for Service Providers or compact resources) require authentication, and that that authentication is for a real user on the server (e.g. not auth credentials for the client app itself, but for the user who is using it).
However, I'm not entirely sure of the consequence of that:
- Does anyone see any problems with servers requiring authentication in this way?
- I'm not sure how this might affect clients implemented entirely in a browser & mobile apps.
(I'll go into this in more detail later, but the reason for requiring such authentication is so that the server can then provide a URL to the dialog/preview that is specific to that user [in a non-predictable way] then when the server is asked to display the dialog/preview in an iframe it knows: (1) for OAuth, it was a valid consumer that retrieved that URL for the dialog/preview or (2) for HTTP Basic Auth, it was a consumer who the user gave their credentials to that requested the dialog/preview URL. And: (3) the user for which the dialog was requested is the same user for which it is being displayed.)
Any answers to those two questions above would be appreciated - thanks.
Martin