OAuth Consent and Connected Applications: Safe Delegated Access
Understand delegated access, consent grants, scopes, tokens, connected-app risk, and the evidence needed to investigate or revoke access safely.
Delegation is not the same as signing in
OAuth lets a person or service authorize an application to act against a protected API without handing that application the account password. Authentication establishes who is present; authorization determines what an application may do. Keeping authentication and authorization separate prevents a familiar interface from hiding the significance of a consent decision.
A connected application may receive access to mail, files, calendars, profiles, or administrative functions. The grant records the authorization decision, while access and refresh tokens are credentials used afterward. Removing the visible app or changing the user’s password may not remove the grant. Defenders therefore need an inventory of clients, owners, scopes, grant type, tenant reach, and last activity—not merely a list of interactive sign-ins.
Read the consent screen as a risk statement
A useful consent review identifies the publisher, redirect destination, requested scopes, affected account, duration, and whether approval covers one user or an entire organization. Broad labels such as “read your data” need translation into concrete actions: which resource types, whether write or delete is possible, whether access continues when the user is absent, and whether administrators are delegating authority for others.
Treat urgency, copied branding, and a plausible app name as presentation rather than proof. Start from an approved application catalog or a known service page when possible. If the requested privilege exceeds the task, stop and ask the application owner. Safe generative AI use requires the same scrutiny because connectors may give an assistant continuing access to repositories, mailboxes, drives, or collaboration spaces after the original conversation ends.
Design grants for narrow, observable use
Prefer exact redirect URI matching, short-lived access tokens, sender-constrained or rotated refresh tokens where supported, and scopes restricted to the required API operations. Separate development, test, and production clients so a low-trust environment cannot inherit production authority. Human-facing public clients should use current authorization-code protections rather than legacy flows that expose credentials through browsers or URLs.
Governance complements protocol security. Assign an accountable owner, document the purpose, review publisher changes, expire unused grants, and require renewed approval when privilege grows. Log client identifier, subject, tenant, scopes, token events, source context, and API actions with consistent timestamps. These records connect session and token evidence to effects such as mailbox reads, file downloads, forwarding-rule changes, or directory updates.
Investigate grants through actions, not labels
Begin with the application identifier and grant object, then pivot to consent time, approving identity, scopes, refresh-token issuance, source context, and API activity. Compare these with the user’s normal work and the application’s declared purpose. A suspicious grant may follow a phishing message, but a legitimate client can also be abused after its secret, signing key, owner account, or refresh token is stolen.
Preserve identity-provider, application, audit, and resource logs before short retention removes them. Determine the earliest possible access and enumerate affected resources from that point. Distinguish the person who approved access from the application identity that performed actions. That distinction prevents investigators from treating non-interactive API activity as if it were an ordinary browser session and improves the accuracy of scope and notification decisions.
Revoke the authority and close the persistence paths
Response should disable or restrict the client, revoke grants and refresh tokens, invalidate relevant sessions, remove attacker-created credentials, and inspect actions already performed. If an administrator granted tenant-wide consent, checking only the administrator’s mailbox misses every other affected identity and resource. Rotate a confidential client’s secret or key when compromise is plausible, and verify that automation has not recreated the grant.
Recovery ends with a known-good inventory: approved owner, necessary scopes, valid credentials, monitored use, and no unauthorized persistence. Reissue access deliberately rather than restoring the original broad grant. Document which controls stopped future use and which downstream changes were reversed. Password resets remain useful when a password was exposed, but they are not a substitute for revoking independent tokens, application credentials, delegated grants, and active sessions.
