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".
