A reporting application must call a company data API to pull a sales manager's own pipeline figures. Security requires that the application act on the manager's behalf with limited, revocable access and never see or store the manager's password. The application does not need to establish the manager's identity for its own sign-in. Which approach meets these requirements?

OAuth 2.0 is an authorization framework for delegated access. The resource owner authenticates to the authorization server, approves the requested scopes, and the client application receives an access token that the API accepts. The token is limited to the granted scopes, expires, and can be revoked without changing the user's password, and the client never handles the user's credentials. That matches every stated requirement: acting on the manager's behalf, limited and revocable access, and no password exposure. OpenID Connect adds an identity layer on top of OAuth 2.0; its ID token tells the client who the user is, and it is not intended to be the credential an API authorizes against, so it answers a sign-in question the scenario explicitly does not ask. Storing the password encrypted in configuration still means the application holds and replays the credential, which violates the core requirement and turns the app into a password store. Basic authentication over TLS protects the password in transit, but the application still sees and forwards it, and access cannot be scoped or revoked separately from the password. Exam caveat: OAuth answers what an application may do, not who the user is. Operational check: confirm the app registration requests only the scopes the reports need and that revoking the grant stops API calls.