Delegated access: API keys vs OAuth 2.0

Summary

• Delegated access is how you as a user let an app or service act on behalf of you.

• API keys are a common approach and are sufficient in simpler or less externally-facing apps.

• OAuth is more work to implement but allows for secure, manageable delegated access at scale.

What is delegated access?

Delegated access means letting one system act on behalf of another. Instead of the app being you, it’s acting for you. Think: a third-party app syncing your calendar, or a Zapier workflow reading your CRM. The system doing the work needs limited, secure access to your stuff, with rules around what it's allowed to do.

API keys: the typical first step

API keys are the usual first approach. We talked about them a bit in the last post. They're simple: the platform generates a token (usually a long string), gives it to the client, and the client attaches it to every request. If the token checks out, the request goes through.

Pros:

• Fast and easy to implement

• Great for internal tools or service-to-service calls

• Works fine when the platform doesn’t need user-specific access

Cons:

• No built-in user identity

• Takes more work to support scoping or restricting permissions

• Static tokens are risky in frontend apps or anywhere they might leak

API keys are like handing someone your house key. Simple, but you better trust them. And if you lose the key? You have to change the locks.

OAuth 2.0: scopes, tokens, and delegation done right

OAuth 2.0 is designed for modern delegated access. It lets you issue short-lived access tokens that are tied to a specific identity, limited in what they can do via scopes, and revocable at any time.

If API keys are house keys, OAuth tokens are hotel key cards. You can limit them to a room, set an expiration time, and deactivate them if needed.

Pros:

• Fine-grained control over permissions

• Secure for user-delegated access

• Good for mobile, frontend, and third-party devs

Cons:

• More complex to set up

• Requires an auth server (or a service like Auth0)

If you want other people building apps around your API? OAuth is the standard. Google, GitHub, Microsoft, Slack — they all use it.

When to use which

If you can get away with API keys (fewer features, less secure), it saves you a ton of work.

But OAuth shines when the platform is letting users delegate to external parties, managing user-level access, or building a developer ecosystem.