Knocking on the Door

Module 3 of 5 in the chapter The Client and Server, chapter 2 of the Integration Architect course. Each module stands on its own. Previous: Finding the Server · Next: The Client–Server Tango

The question this module answers: Once a client has found a server, how does it prove who it is, and why does it have to?

When I ask a class what a client needs to call a server, the very first answer is usually: “Don’t they need an access token of some sort?” That’s exactly right. Finding the server, the last module, gets you to the door. Now you have to knock, and say who you are.

An Open Door

Some servers don’t ask. Anyone can call them, with no proof at all. That’s called public access, and it has its place: a public website, a page anyone is meant to read.

But think about what an open door means for an integration. If a server never asks who’s calling, then anyone can call it, as often as they like. Somebody can point a pile of machines at it and just bombard it with calls until it can’t answer the real ones. That’s a denial-of-service attack, and an open server is completely exposed to it. It can’t turn anyone away, because it never asked who they were.

Click to enlarge

An open door: anyone can call, as often as they like, and nobody knows who they are.

And the data we move in integration is almost always data someone wants protected: customers, orders, deliveries, money. So in this course, almost every server we design for will ask the client to prove who it is. Public access is the exception, chosen on purpose, never the default.

Proving Who You Are

So how does a client prove who it is? With credentials: something only that client should have.

In older integrations, that was often a username and password, the same kind a person signs in with. Today it’s more often a client ID and a secret issued to that one integration, or a certificate it signs with, and what it gets back is a token. You met this in chapter 1: every integration signs in as someone, and that someone is almost always its own integration user, not a person. Almost, because there are good exceptions: some OAuth flows act on behalf of a person who signed in and approved it, and some designs let an integration act as a named user. Chapter 12 covers when that’s the right choice. What’s never right is an integration quietly borrowing someone’s own login.

The old way is on its way out on Salesforce. The OAuth username-password flow can’t be enabled in orgs created from Summer ‘26, and it’s retired for connected apps on 2027-02-20. In Salesforce’s words: “The username-password flow directly passes the user’s credentials in HTTP requests, which presents security risks.” (Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (opens in a new tab), Salesforce Help, checked 2026-11-01.) The industry’s own security guidance for OAuth says the same: that grant “MUST NOT be used” (RFC 9700, Best Current Practice for OAuth 2.0 Security (opens in a new tab), section 2.4).

A Second Address

Here’s the part that surprises people the first time. Proving who you are often happens somewhere else. The client may have a second endpoint it has to hit before it ever reaches the API.

That second address is an authorization server. The client goes there first, presents its credentials, and gets back an access token: proof that it was checked, good for a limited time. Then it calls the API it actually wanted, and sends the token with every call. The server behind the API checks the token, not the password.

Think of a food festival. There are dozens of food stalls, and the people cooking don’t have time to check who you are or take your money. That’s done somewhere else. So you go to the entrance first, show who you are, pay, and get a wristband. Then you go to any stall and show the wristband, and they serve you. The stall never sees your ID or your money. It just checks the wristband, and the wristband only lasts for the day.

Click to enlarge

First, the second address: credentials in, a token back.

Click to enlarge

Then the call, with the token. Prove who you are once; show the token on every call.

So when you list what a client needs to know, the location from the last module may really be two: where to get the token, and where to use it.

The Server’s Side of the Door

The server has a job here too. Somebody has to run that authorization server, or use one from someone else. On Salesforce, the org plays both parts: it issues the token, and it checks it on the API. The app registration from chapter 1, the External Client App, is how Salesforce knows the client and decides what it may ask for.

And checking who’s calling is only half of it. Once the server knows who, it still decides what they may do: which objects, which records, which actions. A valid token for an integration user with narrow permissions gets a narrow answer. That’s the difference between getting in the door and being allowed into every room.

Where This Goes Next

This is a preview, on purpose. Chapter 12 is the whole story: which flow to choose for which kind of caller, the food festival told in full, tokens as a design decision, and keeping secrets out of the places they shouldn’t be. For this chapter, the point is that every client needs one more thing besides an address and a port: a way to prove who it is, and usually a second address to do it at.

What an Architect Decides Here

• For every server, whether it’s public on purpose, or asks every caller to prove who it is.
• For every client, how it proves who it is, and as whom: almost always its own integration user, a person only when the design calls for it, and on Salesforce never the retired username-password flow.
• Where the client gets its token, and where it uses it: often two addresses.
• What the caller is allowed to do once it’s in, as narrow as the integration needs.

Explore

• Salesforce Help, Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (opens in a new tab), checked 2026-11-01.
• IETF, Best Current Practice for OAuth 2.0 Security (RFC 9700) (opens in a new tab), January 2025.
• The next module, The Client–Server Tango: each side’s dance moves.