Choosing the Right Grant

Every grant selection decision reduces to one question: is there a human resource owner delegating access, or is the client acting purely as itself? If a specific user needs to grant an application access to their own data, that's Authorization Code with PKCE, full stop, regardless of whether the client is a web app, SPA, or mobile app. If there's no user at all, a backend job talking to another backend service, that's Client Credentials. Almost every OAuth misconfiguration traces back to conflating these two cases: using Client Credentials where per-user delegation was actually needed, or building a custom non-standard flow because a team wasn't sure which standard grant fit.

In practice: web apps with a server-side back end and browser-based SPAs and mobile apps should all use Authorization Code with PKCE for anything involving a logged-in user, the difference is only in where the code exchange happens (server-side directly, or via a BFF for SPAs). Backend services calling other backend or third-party APIs with no user context use Client Credentials. Devices with limited or no input capability, smart TVs, CLI tools without a browser, use the Device Authorization Grant (not covered in depth here, but worth knowing it exists specifically for that case). Anything reaching for the Implicit or Password grants should stop and reconsider, per the deprecated-grants discussion, there is essentially always a better modern option.

Whichever grant you choose, scope design should follow least privilege: request only the specific permissions the current operation needs, not a broad 'everything' scope out of convenience. A read-only reporting dashboard should request orders:read, not orders:write or admin:*; a Client Credentials service that only reorders inventory should never also carry a scope that lets it issue refunds. This matters doubly for Authorization Code flows, where overly broad scope requests also erode user trust at the consent screen, users are more likely to abandon a login flow that asks for access it clearly doesn't need for its stated purpose.

When reviewing an OAuth integration, several signals reliably indicate a wrong grant choice: a Client Credentials token being used with a caller-supplied user or account ID parameter (should be Authorization Code or token exchange); a mobile or SPA app embedding a client_secret in its binary or bundle (the app is public, so it needs PKCE, not a secret it can't actually protect); a backend prompting users to type their password into a custom form that then calls another provider's API (ROPC in disguise, likely violating that provider's terms of service); and any homegrown 'bearer token' scheme invented because a team found OAuth's standard grants 'too complicated' for their use case, which usually means missing expiration, rotation, or scope enforcement entirely.