I sometimes use these features where I can use my Google account to sign in to different service providers. For example, the Postman app lets me sign in to it using either their own user store, or Google's (I believe this uses the OAuth schema, but I could be wrong).

When I do this on a website, it's pretty clear I am sending my Google credentials to Google, not to the site I'm trying to sign in to, as I can verify the URL in the browser. However, in native apps, I don't see an easy way to check this. How do I know my credentials are being sent to Google, and not to Postman or some other site (by accident, or maliciously)?

See, for example, a screenshot of the Postman Google sign-in screen: screenshot of the Postman Google sign-in screen

Note: I don't think this is a duplicate of How can an end-user verify the authenticity of a third-party authentication provider's login form That questions asks specifically about websites, I'm asking about native apps, where the accepted answer to that question does not apply. The answer does tough on that, but only to the extent that the user just needs to trust the native app. I am wondering if there is anything concrete I can do as a user to make sure the prompt is legitimate?


2 Answers 2


Expanding somewhat on Jeff's answer: The purpose of OAuth is to provide a way for an untrusted service (that is, one you don't want to give credentials to, in this case Postman) to verify your identity (and optionally access data from) some identity provider (in this case Google). For web pages, it's relatively easy to do this securely, so long as you trust the web browser's security, because the browser tells you what domain it's executing code from and sandboxes sites on different domains so that one cannot read requests, responses, cookies, or other data from another unless the latter explicitly allows it (this is the Same-Origin Policy).

However, when you're running native apps, none of those guarantees apply. The app (Postman, in this case) could be completely above-board here, loading the login and authorization pages from Google and politely not looking at what requests you make to Google or what responses you get back until redirected back to Postman. However, it could also be monitoring every keystroke and every bit of network traffic (TLS won't save you here; it's implemented by the application and Postman is the application), presenting a completely faked login screen, or even be doing totally above-board OAuth but also silently encrypting all your personal files for a ransomware attack.

In other words, if you're worried about the trustworthiness of a native app, the point where you need to think about that is before you ever run it, not when it gets to the point of prompting for credentials. By the time you've run it (or even run an installer for it, in the case of anything that doesn't come from an "app store"-type system where the author cannot control the install process), it could already have acted maliciously.

Now, if you just want to verify that the app doesn't have accidental security vulnerabilities, there are things you can do there. For example, regarding your exact query, using a network monitor application (such as Wireshark), or Windows' built-in Resource Monitor, you can see what network connections each app opens, including what protocol, remote server, and port. Wireshark will also let you look at the traffic, so you can verify that it's using HTTPS. Additionally/alternatively, a proxy application (such as Burp Suite or Fiddler) can install a TLS root certificate and use its own faked certificates to MitM TLS network traffic, so you can see exactly what was sent and received (Burp in particular also has tools for testing things like "does the app verify certificates correctly").

To see what the app is doing aside from network traffic, there's a few options. You can disassemble and possibly decompile the binaries (or, for scripting languages, just extract and de-minify the scripts) and analyze the program's behavior that way. You can use a process tracing tool (on Windows, try the Process Explorer tool from Sysinternals) to see where the app is reading and writing data (or doing many other things), which will let you know if it's storing user data somewhere it shouldn't or anything like that (though it takes some expertise to understand the captured trace). You can also just go check the likely data stores (user profile in general, app-specific data directories, system-wide data directories for anything installed as Admin, registry keys, etc.) to see if anything in there looks fishy, or has insufficient security. There are other options, but they all basically boil down to "perform a security review / penetration test of the application".


You cannot know if the app intercepts your credentials even if you are directed to the real Google account website.

That is precisely the reason Google stops supporting this.

Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June (2019)

  • Interesting, thanks for the answer and reference. It is curious that I was just able to sign in with postman through their embedded sign-in page, and it is now almost September. I wonder if Google back-pedaled on this. Commented Aug 28, 2019 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .