Skip to content
SteveTechArcSteveTechArc Courses

The Re-Entry Pass

Module 5 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: How does an app get a new wristband without sending the person back to the entrance?

Two kinds of token

Section titled “Two kinds of token”

There are two kinds of token, and they’re very different things. The access token is the wristband that gets you in. The refresh token doesn’t get you in, and no stall will serve you for it. But it lets you go back to the guards and get a fresh wristband. That’s the re-entry pass from the Front Door chapter.

Why would you want one? Think of an app on your phone that reaches Salesforce for you. You signed in once. The wristband runs out after a while, “usually minutes or hours” (S2). Without a re-entry pass, the app would have to send you to the login screen again every time. With one, it gets a fresh wristband quietly, and you don’t notice.

The same request, a different pass

Section titled “The same request, a different pass”
The re-entry pass: the refresh token The same three columns. Step 1: the client holds the re-entry pass, a refresh token, from a flow with a person, and presents it at the entrance with grant_type=refresh_token; the entrance checks the pass and, with rotation, gives a new pass too, along with a new wristband. Step 2: the client shows the wristband at the stall and gets the data. Footnote: only flows with a person give a re-entry pass, never client credentials; its life, rotation, the 30-day idle limit and revoking, is chapter 13. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-OF-05", "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=refresh_token: the re-entry pass from a flow with a person The entrance checks the pass; with rotation, gives a new pass too 2. Goes to the stall shows the wristband on every call The stall checks the wristband the re-entry pass a new wristband the wristband the data Only flows with a person give a re-entry pass, never client credentials. Its life (rotation, the 30-day idle limit, revoking) is chapter 13. HOW TO READ IT the entrance: where you prove who you are, once © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Here’s the nice part: you already know this flow. It’s the base pattern again. Same entrance, same request, one more substitution in what’s presented (S3):

POST /services/oauth2/token HTTP/1.1
Host: MyDomainName.my.salesforce.com


grant_type=refresh_token&
client_id=*******************&
client_secret=*******************&
refresh_token=*******************
  • grant_type=refresh_token names the flow.
  • refresh_token is the re-entry pass, “a secret. Take appropriate measures to protect it” (S3).
  • client_id and client_secret say which app is asking, as in module 3.

Back comes a new access token, the same shape as module 3’s answer. A refresh token is never an access token itself. It has to be exchanged for one.

Which flows give one

Section titled “Which flows give one”

Not every flow gets a re-entry pass. The refresh token flow “renews access tokens issued by the OAuth 2.0 web server flow or the OAuth 2.0 user-agent flow” (S3), the flows with a person in them. And only when the app asks for it: the refresh_token scope (S2). Even full doesn’t bring one on its own (S2).

And never with client credentials: “This flow doesn’t support refresh tokens” (S1). That makes sense once you see the shape. A program with its own ID and secret can always go back to the entrance. It’s the app acting for a person who isn’t there that needs a way back in without her.

So in this chapter you see the refresh token’s shape. You’ll meet the flow that gives one, the web server flow, in chapter 9.

Why the pass needs care

Section titled “Why the pass needs care”

A wristband runs out in minutes or hours. A refresh token “can have an indefinite lifetime, persisting for an admin-configured interval or until explicitly revoked” (S2). So a stolen pass is worth far more than a stolen wristband.

That’s why the newest protections are all about the pass. The one to know here is refresh token rotation: with it on, the app gets a new refresh token along with each new access token, “The previous refresh token is automatically invalidated”, and if anyone tries an old one, “Salesforce invalidates the current refresh token and any associated access tokens” (S3). A thief who copies a pass gets one use at most, and then everybody’s cut off.

One practical rule comes with it. Don’t send the same refresh token twice at once: simultaneous requests can fail with “Token request is already being processed”, and Salesforce’s advice is to “cache and reuse tokens instead” (S3).

The rest of the pass’s life, from the 30-day idle limit to the five-passes-per-person rule and passes tied to one machine, is chapter 13 of this course, and Integration Architect tells it for integrations in its chapter 13, module 7. The Front Door chapter has the 30-day limit in a line.

Taking it back

Section titled “Taking it back”

Any token can be taken back. One POST to the revocation endpoint does it (S4):

POST /services/oauth2/revoke HTTP/1.1
Host: MyDomainName.my.salesforce.com
Content-Type: application/x-www-form-urlencoded


token=*******************

Send an access token, and Salesforce invalidates it. Send a refresh token, and “Salesforce revokes it and any associated access tokens” (S4): the pass and every wristband it gave out. Salesforce suggests it for an app’s log-out button (S4).

And any app can ask whether one of its tokens is still good, at the introspection endpoint, /services/oauth2/introspect (S5). “By default, all external client apps can introspect their own tokens” (S9). The practice does both: revoke a token, then check it.

What’s next

Section titled “What’s next”

Module 6: once you know this one, the family of flows that pass something different.

What an architect decides here

Section titled “What an architect decides here”
  • Which apps get a re-entry pass at all: only those acting for a person who isn’t there.
  • Rotation on, for every app that gets one.
  • Where the app keeps its pass, and what happens when the refresh fails: back to the login, not a thousand retries.
  • How you’ll take tokens back when someone leaves or an app is compromised.

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.