What each model actually gives you
- OAuth: per-user identity, explicit consent, per-client revocation, short-lived tokens.
- API key: fast setup, no user binding, long-lived, revoked only by rotating the secret.
- OAuth: role and entitlement checks apply naturally to the acting user.
- API key: permissions have to be attached to the key itself, which tends to over-grant.
The audit consequence
When something is created, changed or sent by an assistant, the record needs to name who authorized it. With OAuth, the acting user is present in the token and can be written into the audit row. With a shared key, the honest entry is 'a machine did this', which is not enough when the question is whether the action was approved by someone allowed to approve it.
Where API keys still make sense
Server-to-server jobs with no human in the loop — scheduled syncs, internal batch reads — are a reasonable fit, provided the key is scoped narrowly and its actions are attributed to a system actor rather than a person. What is not reasonable is using a shared key to let an external assistant perform work on behalf of unidentified humans.