The Re-Entry Pass, Over Time
Module 3 of 5 in the chapter External Client Apps, Tokens and Their Lifecycle, chapter 13 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: What happens to a refresh token after it’s handed out, and how does an admin take it back?
How often do you log in to your streaming app?
Section titled “How often do you log in to your streaming app?”Here’s a question I ask the room. If you watch a streaming service on your phone, how often do you have to put in your password? Every day? Every hour? Not very often.
What’s happening behind the scenes is that the app signed you in once and got a refresh token. When its access token runs out, it uses the refresh token to get a new one, without bugging you. In the web server flow (chapter 9), the refresh token came for the ride: not only did the Burger House get an access token, it got a refresh token too. At the festival, it’s the re-entry pass (chapter 8).
That’s lovely for Priya. It’s also a token that keeps working long after she’s stopped thinking about it. So what happens to it over time, and who can take it back?
Integration Architect’s chapter 13, module 7, teaches this as a design decision for integrations. This module is the admin’s side: where each control is switched on, and what it does.
A refresh token’s life
Section titled “A refresh token’s life”Each pass works once: rotation
Section titled “Each pass works once: rotation”Turn on Enable Refresh Token Rotation in the app’s OAuth settings, and every time the refresh token is used, the app gets a new one and the old one dies. Salesforce calls it “a security best practice” (S6).
And here’s the clever part. If someone tries to use a refresh token that’s already been rotated out, Salesforce doesn’t just refuse it: it “invalidates the current refresh token and any associated access tokens” (S6). A copy used by a thief gets caught, and takes the good one down with it. The real app has to sign in again, and someone notices.
An unused pass expires: the idle limit
Section titled “An unused pass expires: the idle limit”A refresh token nobody uses for 30 days expires. Salesforce “requires a 30-day limit to the idle refresh token TTL” (time to live), and it’s a sliding window: “each time the token is used within the 30 day-period, its idle TTL resets” (S6). When it expires, “Salesforce revokes the associated access token”, and the person signs in again (S6). For flows with no refresh token, the same control “caps the access token lifetime at 30 days from the last login date” (S6).
It’s being enforced in production on a rolling basis from November 4, 2026, for every connected app and external client app, installed ones included (the shared security record). So a token forgotten in an old integration can’t wake up a year later.
On for new apps, not yet for old ones
Section titled “On for new apps, not yet for old ones”From July 2026, every new app gets rotation and the 30-day idle limit switched on, with PKCE (S11). Apps made before then may not have rotation on. That’s what module 1’s Insights page is for: find the apps missing controls, and switch them on.
Only from where it should be: the IP allowlist
Section titled “Only from where it should be: the IP allowlist”For an app that runs from known addresses, Enforce Refresh Token IP Allowlist: only those addresses can use the web server flow or the refresh token flow (S6). A refresh token copied and used from elsewhere gets nothing.
Five per person, per app
Section titled “Five per person, per app”One more limit, from Integration’s module 7: by default, five authorizations per app per user. Approve a sixth, and the one unused the longest is revoked. For Priya with a laptop, a phone and a tablet, that’s plenty.
Taking it back
Section titled “Taking it back”Every token you hand out, you should know how to take back. Three ways:
- She can. Priya can revoke an app’s access to her own account. In the refresh token video I put it simply: the refresh token can be revoked by the user.
- The admin can. On the OAuth Usage page for external client apps, review active integrations and “block any suspicious or unapproved clients” (S9). Blocking an app ends its sessions (module 2).
- Code can. The revoke endpoint,
/services/oauth2/revoke(chapter 8): revoke a refresh token and its access tokens go with it. Put it in your runbook for when a partner says they’ve been breached.
Only on the wrist it was given to: DPoP
Section titled “Only on the wrist it was given to: DPoP”The last control goes furthest. DPoP, Demonstrating Proof-of-Possession, “cryptographically binds OAuth access and refresh tokens to your client. To use a token, clients must prove that they own the private key. Even if a threat actor steals an OAuth token, they can’t use it to access your data” (S10). It’s available on a rolling basis from October 5, 2026, for both kinds of app (S10).
It’s two halves again, like module 1: the admin turns on Require DPoP in the app’s OAuth settings, and the developer has to make the client produce DPoP proofs (S10). Switch it on before the client is ready, and the app stops working.
Test knowledge. The exam guide aligns to Summer ‘23, before rotation, the idle limit and DPoP. In my experience, know what a refresh token is for, which flows give one, and how it’s revoked.
Beyond the exam: what AI changes. Agents and MCP servers hold tokens too, often refresh tokens, often for a long time. Everything in this module applies to them. Chapter 17 takes it further.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of the refresh token flow: the token that came for the ride, stored securely, and swapped for a new access token. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 4: where it went wrong, 2024 to 2026, and which of these controls would have closed the door.
What an architect decides here
Section titled “What an architect decides here”- Rotation on for every app with refresh tokens, old ones included.
- Who checks the Insights page for apps missing controls.
- IP allowlists for apps that run from known addresses.
- The revoke runbook: which app, which user, who may pull the plug.
- DPoP for the apps whose tokens would hurt most if stolen, with the developer ready first.
Explore
Section titled “Explore”- Configure the External Client App OAuth Settings (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Protect Your Data with the OAuth 2.0 DPoP Extension (opens in a new tab) (Winter ‘27 release notes; checked 2026-11-07)