TL;DR

OAuth (Open Authorization) is an authorization framework that lets one application access resources in another on a user's behalf, without the user sharing their password. In recruitment, it's the mechanism behind "Connect to Bullhorn" or "Sign in with Google" buttons. It replaced an era of integration setups that required embedding credentials in configuration files.

How OAuth Works

OAuth solves one specific problem: how does Application B prove to Application A that a user has authorized it, without Application B ever seeing the user's password? The answer is a token exchange. The user authenticates directly with the resource server (say, Greenhouse), Greenhouse issues a time-limited access token, and that token is handed to the requesting application. The requesting application uses the token to make API calls on the user's behalf. If the token is compromised, it can be revoked without changing the user's password.

The standard version in active use is OAuth 2.0. It defines several "grant types" for different scenarios. The Authorization Code flow is what browser-based applications use: the user is redirected to the authorization server (e.g., Greenhouse's login page), they log in and approve the requested permissions, and an authorization code is returned to the calling application. The application exchanges that code for an access token via a back-channel server-to-server request, keeping the token out of the browser URL. This is the flow you see when connecting a sourcing tool like Gem to your ATS.

Scopes are how OAuth controls what an authorized application can actually do. A vendor requesting read-only access to job postings requests a narrow scope like jobs:read. Full account administration requires broader scopes. Users and IT administrators should review scope requests carefully during OAuth authorization screens - an integration asking for admin:write when it only needs to post job listings is a red flag. Most enterprise ATS platforms publish their scope definitions in developer documentation.

Access tokens expire, typically within an hour. Refresh tokens are longer-lived credentials that allow the application to obtain new access tokens without user interaction. When an integration "reconnects" after a long period of inactivity, it's usually because the refresh token has also expired or been revoked - a deliberate security boundary. This is why re-authorizing integrations every 90 or 180 days is common in enterprise environments with strict security policies.

Why It Matters in Recruitment

The recruitment technology stack is deeply interconnected. A typical mid-market recruiting team might connect their ATS to a background check provider, a video interviewing platform, a job board, a sourcing tool, and an analytics layer. Before OAuth became standard, each of these integrations required creating a service account with a password, embedding that password in the integration configuration, and hoping nobody rotated the credentials. When a recruiter left the company and their account was deactivated, integrations broke.

OAuth replaced that with a model where permissions are explicit, revocable, and tied to an authorization record rather than a person's credentials. When a recruiter who connected their Lever account to LinkedIn Recruiter leaves, the IT team can revoke that specific OAuth authorization without touching anyone else's credentials or deactivating shared service accounts. Audit logs show exactly when the token was issued, what scopes were granted, and when it was last used.

For staffing agencies managing dozens of client-specific integrations, OAuth's per-authorization revocability is operationally significant. A token scoped to one client's job board account can be revoked without affecting the agency's other integrations. The alternative - shared API keys embedded in configuration files - creates a tangled web that's difficult to audit and dangerous to rotate.

OAuth in Practice

A technical sourcing team at a [staffing agency](/glossary/staffing-agency) wants to connect their Greenhouse ATS to a new AI sourcing tool. The setup flow begins with the sourcing tool redirecting the user to Greenhouse's OAuth authorization page, requesting scopes for reading jobs and creating candidates. The recruiter logs into Greenhouse, reviews the requested permissions, and clicks Approve. Greenhouse issues an authorization code, the sourcing tool exchanges it for an access token and a refresh token, and the connection is live.

Three months later, the agency's IT security policy requires reauthorizing all third-party integrations. The sourcing tool's refresh token has been invalidated. The recruiter gets a notification, clicks "Reconnect to Greenhouse," completes the OAuth flow again, and the integration resumes. No passwords were exchanged at any point in this process.

Key Considerations