impersonate the legitimate server cannot know (e.g. Yahoo's sign-in-seal, 3D-Secure's "personal assurance message"). There is a specific problem on mobile devices though, due to the inability for the user to distinguish between a browser instance and a malicious app: the app can create a pixel-perfect image of a browser window by writing to the full screen, connect to the legitimate site using its own HTTP(S) code, and become an undetectable man-in-the-middle. To get round that, the secret sign must not be held on and delivered by the server, it must be in a trusted app on the phone which takes over the screen, shows the secret sign to the user, handles the OAuth exchanges, and then returns the token to the untrusted app. I proposed this in my talk at OTA last year (slide 18). Furthermore, there's a couple of other problems with oauth: 1. If the web view is embedded, there are delegate callbacks available to the developer. This means it's trivial for the developer to intercept and examine the request; I.e. read the credentials; embedded web views essentially dont provide what they are attempting to do 2. Every oauth enabled app has a concept of their app key - this is why the provider can say "Application x wants your permission to log in" (and obviously, identify the application for security reasons). When your app is web based, you can secure you app key relatively easily (by encryption, local file permissions, etc.). If you're on mobile, it needs