OAuth 2.0 for Integrations

Why it matters: Every "Connect your Google/HubSpot account" button is OAuth. Understanding scopes and tokens helps you grant the least access needed and handle expired or leaked tokens.

By the end you can:

• Explain OAuth roles and the authorization-code flow
• Tell access tokens from refresh tokens
• Review scopes and redirect URIs
• Store and rotate tokens safely

Learn (15 min)

1. Delegated authorization (5 min)

OAuth 2.0 lets an app get limited access to a service on a user's behalf without the user giving the app their password.

User ──(1) clicks Connect──► App
App ──(2) redirects to Authorization Server (with scopes, PKCE challenge)──► User signs in & consents
Auth Server ──(3) redirects back with a one-time code──► App
App ──(4) exchanges code (+ PKCE verifier) for tokens──► Auth Server
App ──(5) calls API with access token──► Resource Server

OAuth is mainly about authorization. Login ("who are you") is typically handled by OpenID Connect on top.

2. Tokens and scopes (5 min)

• Access token: short-lived; presented to the API. Whoever holds a bearer token can use it, so treat it as a secret.
• Refresh token: longer-lived; exchanged for new access tokens. Store with extra care.
• Scopes: the permissions requested, e.g., calendar.events instead of "everything." Request the minimum.

3. Redirects and lifecycle (5 min)

Register exact redirect URIs; the server must match them per the provider's rules. Current security guidance favors the authorization-code flow with PKCE and discourages legacy patterns such as the implicit flow. Plan for token expiry, revocation, user consent changes, and credential rotation. In automation platforms, let the platform's connection manager hold tokens; don't paste tokens into workflow text.

Apply (15 min)

Worked example (3 min). An integration creates calendar events. Requested scope: create/edit events on the user's own calendar only, not "read all Drive files." Tokens are stored in the platform vault; the app handles a 401 by refreshing once, and on refresh failure asks the user to reconnect and alerts the owner.

Lab (7 min): Scope review.

1. Pick three apps you've connected (or imagine them). For each, find the permissions shown on the consent screen.
2. Mark each permission: needed / not needed for the stated purpose.
3. Write the narrower request you would prefer.
4. Check where tokens for those connections live and who can see them.

Deliverable: A table: app | permission | needed? | narrower alternative. You're done when: At least one over-broad permission is identified, or you can justify why none is.

Check yourself (5 min)

1. What does OAuth provide?
2. Is OAuth the same as login?
3. Scenario: A bearer token shows up in a screenshot in a support ticket. What do you do?
4. Why minimize scopes?
5. What is a redirect URI?

Reference

Common mistakes

Cheat sheet: Register client → authorization code + PKCE → minimal scopes → protect tokens → refresh/revoke safely.

Key terms: authorization server, resource server, client, access token, refresh token, scope, PKCE.

Interview prompts: Explain OAuth to a non-technical stakeholder. What do you do when a token leaks?

Go deeper: RFC 6749 OAuth 2.0 · RFC 9700 Security BCP · RFC 6750 Bearer tokens

Next: Lesson 18 — what to do when integrations fail.