A SaaS provider's public API authorizes every request with a single static API key embedded in a partner's application. The partner now needs each of its end users to see only their own data through that API. What should the API's authorization design change to?

An API key identifies and authenticates a calling application or project. It is typically a long-lived shared secret, carries no information about which end user is acting, and grants the same access to every request that presents it. When authorization must vary by end user, the API needs a delegated authorization framework such as OAuth 2.0, in which the user authenticates, often through OpenID Connect, and the client application obtains an access token representing that user with defined scopes and a limited lifetime. The API then authorizes each request against the user and scopes in the token, so users reach only their own data. Making the key longer and rotating it improves the key's resistance to guessing and limits exposure after theft, but it remains a single application-level credential that cannot distinguish users. Embedding per-user keys in a distributed client places long-lived secrets on devices where they can be extracted, and provides no standard way to issue, scope, expire or revoke user consent. Restricting the key to the partner's IP range limits where requests may originate, which helps against stolen keys used elsewhere, yet every user behind that range still shares the same access. Exam caveat: API keys remain useful for identifying applications and applying quotas alongside OAuth tokens. Operational check: test that a token issued for one user is refused when requesting another user's records.