Skip to content
SteveTechArcSteveTechArc Courses

How It Began

Module 2 of 6 in the chapter OAuth: The Base Pattern, chapter 8 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: What did the first version present at the entrance, and why is Salesforce retiring it?

The old school one

Section titled “The old school one”

When I first teach the food festival, I tell it the way it began. You walk to the entrance, you show your username and password, and you get your wristband. It’s the simplest way to see the base pattern, and for years it’s how a lot of integrations signed in to Salesforce.

It’s called the username-password flow. It’s the old school one, the least advantageous of them all, and Salesforce is retiring it. But it’s worth learning first, as history, because the shape is so clear. Every flow in this chapter is this one with something else presented in place of the password.

What the client sends

Section titled “What the client sends”
How it began: a username and password at the entrance The same three columns. Step 1, in amber: the client holds a person's username and password, plus the security token, and presents them at the entrance with grant_type=password; the entrance checks the password and gives back a wristband, a session ID, with no scope and no re-entry pass. Step 2: the client shows the wristband at the stall and gets the data. Legend: amber is retiring, still in orgs, not for new work. Footnote: the same two steps; retiring, enforced February 20, 2027, and off in orgs created in Summer '26 and later. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-OF-02", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE CLIENT THE ENTRANCE: SALESFORCE'S TOKEN ENDPOINT THE STALL: AN API 1. Goes to the entrance grant_type=password: a person's username and password, plus the security token The entrance checks the password; the wristband is a session ID, no scope, no re-entry pass 2. Goes to the stall shows the wristband on every call The stall checks the wristband username + password the wristband the wristband the data The same two steps. Retiring: enforced February 20, 2027, and off in orgs created in Summer '26 and later. HOW TO READ IT retiring: still in orgs, not for new work the entrance: where you prove who you are, once © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The client posts to the token endpoint with five values (S6):

grant_type=password&
client_id=*******************&
client_secret=*******************&
username=priya@example.com&
password=*******************
  • grant_type=password says which flow this is.
  • client_id and client_secret say which app is asking.
  • username and password are a person’s own login.

And one surprise for people the first time. From a network Salesforce doesn’t trust, the password alone isn’t enough: you add the user’s security token to the end of it. “The security token is an automatically generated key that must be added to the end of the password to log in to Salesforce from an untrusted network” (S6). In class, the demo fails until I reset the security token, it arrives by email, and I paste it onto the end of the password. Then the wristband comes back.

What’s wrong with it

Section titled “What’s wrong with it”

Look at what’s in that request. A person’s password, sitting in another system, sent across the wire every time the app needs a new token.

That’s the one thing OAuth set out to stop. The username and password should go from the person who has it to one place only: the system that checks it. If a third-party system is storing your Salesforce username and password, that’s bad. It should never happen. Only Salesforce should have your Salesforce password.

Salesforce says the same: “we recommend avoiding this flow because it passes credentials back and forth” (S6). And the retirement notice is blunter: “The username-password flow directly passes the user’s credentials in HTTP requests, which presents security risks” (S7).

It has smaller problems too. The token it gives back is a Salesforce session ID that “can’t be introspected”, so you can’t ask Salesforce later whether it’s still good. And “This flow doesn’t support scopes or refresh tokens” (S6): no way to limit what the wristband allows, and no re-entry pass, so the app holds on to the password to get the next one.

When it ends

Section titled “When it ends”

Here are the dates, from Salesforce’s release update (S7):

  • Orgs created in Summer ‘26 and later can’t use it at all. In Setup, the option to allow the username-password flow is “disabled and grayed out”. In my 2024 class I turned it on for the demo, and said at the time that normally you wouldn’t. In a new org, you can’t.
  • Salesforce enforces the retirement on February 20, 2027. It was first announced in Spring ‘26 and originally planned for Winter ‘27. After that, “This update will break all connected app integrations that use this flow.”

Its cousin goes too. SOAP API login(), the old way to log in with a username and password through the SOAP API, retires for API versions 31.0 to 64.0 with Summer ‘27 (S10). Chapter 13 covers it.

What to use instead

Section titled “What to use instead”

Salesforce names the replacements: “For end user login and authorization, use the OAuth 2.0 web-server flow with the Proof Key for Code Exchange (PKCE) extension. For server-to-server integrations, use the OAuth 2.0 client credentials flow” (S7).

  • A program with no person there: client credentials, the same shape with the program’s own key and secret at the entrance. That’s module 3.
  • A person, through an app: the web server flow with PKCE. That one isn’t a single step; it’s the flip, in chapter 9.

And if you have integrations on this flow today, Salesforce’s advice is to block it before the deadline does: “We also recommend that you block all connected apps from using the username-password flow” (S6). Find them first. The retirement notice says what happens to any you miss.

Why learn it at all?

Section titled “Why learn it at all?”

Because the shape is the lesson. Present something at the entrance, get a wristband, go to the stall. This flow is simple, and that same shape is going to be used for a whole bunch of flows, just substituting what’s presented for the username and password. In the next module, you’ll see the substitution.

What’s next

Section titled “What’s next”

Module 3: client credentials, the same shape in its current form.

What an architect decides here

Section titled “What an architect decides here”
  • Which integrations still use the username-password flow, and the date each one moves.
  • Whether to block the flow now, before February 20, 2027 does it for you.
  • What each one moves to: client credentials for a program, the web server flow with PKCE for a person.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.