Developer Platforms & OAuth2
You'll learn to
- -Design the core pieces of a developer platform: API key management and a self-service portal
- -Distinguish the OAuth2 authorization code flow from the client credentials flow, and know when each applies
Everything so far in this course assumed one client talking to one API you control end to end. A developer platform is different: third-party developers, who you don't control and may never talk to directly, need to register, authenticate, and integrate against your API on their own, self-service.
API Key Management
GET /api/v1/orders
X-API-Key: sk_live_51J8x2KLm9pQr...A plain API key (a long, random, unguessable string, tied to a specific developer account) is the simplest form of third-party authentication, appropriate for straightforward server-to-server integrations where the calling application itself is trusted with a long-lived credential. Keys need to be revocable independently (a compromised key shouldn't require rotating every key an account has), and typically come in pairs - a live key and a test/sandbox key - so developers can integrate and test without touching real production data.
OAuth2: When the End User, Not Just the Developer, Needs to Grant Access
A plain API key works when the developer's own application is the entity being authenticated. It breaks down when a third-party app needs to act on behalf of one of your actual end users - a photo-editing app that wants to save images to a user's cloud storage account needs that specific user's permission, not just proof that the photo-editing app itself is a registered developer.
Authorization Code Flow: User-Delegated Access
# 1. The third-party app redirects the user to YOUR authorization server
GET https://your-api.com/oauth/authorize?client_id=app123&redirect_uri=...&scope=read_photos
# 2. The user logs in and approves - your server redirects back with a code
GET https://third-party-app.com/callback?code=AUTH_CODE_XYZ
# 3. The third-party app's SERVER exchanges the code for an access token
POST https://your-api.com/oauth/token
{"grant_type": "authorization_code", "code": "AUTH_CODE_XYZ", "client_secret": "..."}The user authenticates directly with your service (never handing their password to the third-party app), explicitly approves what the app is allowed to do (`scope=read_photos`, not blanket access), and the resulting access token is scoped specifically to that user's granted permissions - the third-party app never sees the user's actual credentials, only a token limited to exactly what was approved.
Client Credentials Flow: App-to-App, No User Involved
POST https://your-api.com/oauth/token
{"grant_type": "client_credentials", "client_id": "app123", "client_secret": "..."}When there's no end user to delegate on behalf of - a backend service authenticating to call your API purely as itself, with its own permissions, not anyone else's - the client credentials flow skips the user-facing consent step entirely and issues a token directly from the app's own credentials. This is essentially a more standardized, OAuth2-flavored version of the plain API key pattern, useful specifically when the ecosystem around your API already expects OAuth2 conventions.
The deciding question between these two flows is simple: is there a specific end user whose data or permissions are being accessed on their behalf? If yes, authorization code flow. If the caller is acting purely as itself, with its own permissions, client credentials flow is simpler and sufficient.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Design API Marketplace in the API Design Lab's Full System Design act.