In more detail
You approve the request at the service you already use, which then gives the app a limited, revocable access token (often a JWT) with specific permissions, called scopes. OAuth is about authorisation; the OpenID Connect layer on top adds proof of who you are. Apps should request only the scopes they need. Four roles take part: the resource owner (you), the client (the app), the authorization server that issues tokens and the resource server (the API) that accepts them. Access tokens are short-lived; a longer-lived refresh token can fetch new ones. The recommended flow for most apps is the authorization code flow with PKCE (RFC 7636).
Why it matters
OAuth is why you can let a calendar app read your events without giving it your password, and why you can later cut it off without changing that password. Problems arise when it is treated as login. An access token says what the holder may do, not who they are, so an app that uses it as proof of identity is open to confusion attacks. Attackers also abuse the consent screen itself: a malicious app with a harmless name asks for broad scopes and, once approved, keeps access even after you change your password. Read the permissions, and review and revoke connected apps now and then.
Example
A request to start the authorization code flow carries parameters like these:
response_type=code
client_id=abc123
redirect_uri=<the app's registered callback>
scope=contacts.read
state=xyz789
code_challenge=<hash of a secret kept by the app>
code_challenge_method=S256
scope is the permission asked for, state stops a forged response being accepted, and the code_challenge ties the final token exchange to the app that began the flow. The service then redirects back with a one-time code, which the app swaps for tokens.
Common confusion
OAuth is not Basic authentication and is not itself a login system. Adding Multi-factor authentication (MFA) protects the account behind the approval screen.