OAuth

OAuth (Open Authorization) is an open authorization standard that lets one application access resources in another on the user's behalf, without the user having to hand over their password. The current version is OAuth 2.0, and it is the foundation of "Sign in with Google" style buttons and of almost every modern system integration.

The core idea is delegated permissions: instead of sharing your password, you give the app an access token that represents a limited permission (for example, "read your contacts") with an expiration. That token can be revoked at any time without changing your password or affecting other connected apps. In the Salesforce ecosystem, OAuth is the official mechanism for an integration or an API to consume data from the platform securely.

One important distinction: OAuth handles authorization (what an app can do), not the user's identity directly. To verify who the person is, you use OpenID Connect, a layer built on top of OAuth.

OAuth was created to solve a concrete, everyday problem: how do I let an application use my data from another service without giving it my username and password? Before it was adopted, an app that wanted to read your calendar or post on your behalf asked for your credentials directly, which was a huge security risk. OAuth solves this by delegating a limited permission through tokens, not the password.

How the flow works

A typical OAuth 2.0 flow involves four actors: the resource owner (the user), the client (the app requesting access), the authorization server (which issues the tokens) and the resource server (where the data lives). The most common sequence, the authorization code flow, works like this:

1. The app redirects the user to the provider's login screen (for example, Salesforce or Google).
2. The user signs in and approves the permissions the app requests, expressed as scopes.
3. The authorization server returns a temporary authorization code to the app.
4. The app exchanges that code for an access token (and usually a refresh token), using its client secret in a server-to-server call.
5. The app presents the access token to the resource server every time it needs to read or write data.

The access token is usually short-lived (minutes or hours); when it expires, the refresh token lets the app get a new one without bothering the user again. That separation is key to security: if an access token leaks, its window of damage is small.

Why it matters for a business

Almost every process automation that connects two systems goes through OAuth. When your CRM syncs with your billing platform, when a chatbot checks stock in real time, or when a marketing tool reads data from your database, the connection is most likely authorized with OAuth. For the technical team, that means auditable, revocable connections: if a vendor stops working with you, you revoke its token and you are done, without touching shared passwords or breaking other integrations.

OAuth in the Salesforce context

Salesforce uses OAuth 2.0 as the standard mechanism for its APIs. An integration is registered as a Connected App and, depending on the use case, chooses a flow: the authorization code flow when a human user is approving, or the JWT Bearer flow for server-to-server integrations that run unattended (ideal for nightly syncs or automated processes). Permissions are limited by scopes and by the profiles and permission sets of the user behind the connection.

OAuth is not the same as authentication

The most common mistake is treating OAuth as a login system. OAuth is authorization (delegating permissions), not authentication (proving identity). To know who the person really is, you use OpenID Connect, which adds an identity token (ID token) on top of OAuth. This distinction comes up all the time in integration projects:

Common mistakes to avoid

• Confusing authorization with authentication: using the access token to "know who signed in" instead of OpenID Connect.
• Requesting too many scopes: asking for broad permissions when a narrow one would do increases the attack surface.
• Storing the refresh token poorly: it is a sensitive credential and must be stored encrypted on the server side, never in the browser.
• Not planning for revocation: a serious integration accounts for what happens when a token is revoked or expires, without breaking.

A concrete example

Picture a consumer goods company in Argentina that connects its Salesforce CRM to its e-invoicing system. Instead of loading the Salesforce username and password into the invoicing system (a terrible practice), it creates a Connected App with the JWT flow, with permission only to read orders and create invoices. If six months later they switch invoicing providers, they revoke that token and the connection is cut cleanly, without affecting the other integrations or exposing reusable credentials.