Skip to content
SteveTechArcSteveTechArc Courses

Who Is She?

Module 4 of 5 in the chapter The Burger House: Flows With a Person, chapter 9 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: How does an app learn who signed in, not just what it may reach?

Access isn’t identity

Section titled “Access isn’t identity”

Everything so far has been about access. The wristband says what the app may reach, for Priya. But think about what the Burger House actually knows at the end of the web server flow. It has a token it can use. It doesn’t have, in the answer itself, a statement it can trust about who signed in.

For a lot of apps that’s the first thing they need. Show “Hello, Priya”. Find her account in the app’s own database. Decide whether she’s an admin in the app. That’s identity, not access, and OAuth on its own wasn’t built for it.

OpenID Connect was. It’s a small layer on top of OAuth that adds one thing: a trusted answer to “who is she?”

The same flow, plus openid

Section titled “The same flow, plus openid”

Here’s the good part. You already know the flow. OpenID Connect is the web server flow from modules 1 to 3, with one more scope in the authorize request: openid.

Who is she? OpenID Connect The same four lanes and five steps, with OpenID Connect. Step 2: the authorize request adds the openid scope. Step 4: the token endpoint's answer adds an ID token, which says who she is, beside the access and refresh tokens. Footnote: same steps; the access token says what the app may reach; the ID token says who signed in. {"author": "Steve Simpson", "blueprint": "1.1.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-FWP-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA'S BROWSER THE BURGER HOUSE SALESFORCE: THE ENTRANCE SALESFORCE: TOKEN ENDPOINT AND API 1. Orders a burger and her drink her drink is at the food festival: Salesforce Needs her drink sends her browser to Salesforce 2. Goes to Salesforce redirected, with the request The festival's entrance Priya signs in and approves 3. Brings the code back to the Burger House's callback address Has the code a short-lived code, not a token 4. Swaps the code server to server: the back channel The token endpoint checks the code and the app 5. Fetches her drink her data, acting as Priya, wearing her wristband The API what Priya may see a burger + her drink redirect to Salesforce + scope openid redirect + the code the code burger + drink, after 5 code + client ID and secret + an ID token: who she is the wristband her data Same steps. The access token says what the app may reach; the ID token says who signed in. HOW TO READ IT Salesforce: the only place Priya gives her password the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Ask for openid (with PKCE, as always), and the token answer comes back with a new field, id_token, beside the access token (S1):

{
  "access_token": "*******************",
  "id_token": "eyJraWQiOi…",
  "scope": "openid api",
  "instance_url": "https://MyDomainName.my.salesforce.com",
  "id": "https://login.salesforce.com/id/00Dx00000000001/005x00000000002",
  "token_type": "Bearer",
  "issued_at": "1762272000000",
  "signature": "*******************"
}

The openid scope “Allows access to the current, logged in user’s unique identifier for OpenID Connect apps… In addition to the access token, this scope enables you to receive a signed ID token” (chapter 8’s S2).

The ID token

Section titled “The ID token”

What’s in that id_token? In Salesforce’s words, it’s “a signed data structure that contains authenticated user attributes, including a unique identifier for the user and when the token was issued. It also identifies the requesting client app” (S5).

Three things make it trustworthy:

  • It’s signed. It’s a JSON web token, a JWT, signed by Salesforce. The app checks the signature with Salesforce’s published keys, at /id/keys on your My Domain (S5). That’s chapter 3’s signature again: anyone can read it, nobody can change it.
  • It names the app that asked (S5), so the app can check the ID token was issued to it.
  • It can be tied to one request. The app can add a random nonce to the authorize request; Salesforce says it “helps to detect replay attacks” (S1).

So the Burger House can now say, with confidence, “this is Priya, and Salesforce says so.” And it can still use the access token for her data.

If it needs more about her, there’s the UserInfo endpoint, “a RESTful API defined by OpenID Connect” that returns “basic personal information about the user”, and only “for the current user” (S4). The app calls it with the access token.

Salesforce as the login for another app

Section titled “Salesforce as the login for another app”

This is what chapter 7, module 5 promised. With OpenID Connect, Salesforce can be the login for an app that isn’t Salesforce, and “it’s not necessary to enable Salesforce as an identity provider” (S6). No SAML, no Enable Identity Provider. You register the app, give it the openid scope, and users “log in to the external app with their Salesforce or Experience Cloud site credentials” (S6).

That suits a web or mobile app that wants “Log in with Salesforce”: the app gets an identity it can check, and, if it needs one, a wristband for the person’s data in the same flow.

The mirror

Section titled “The mirror”

When I taught the Burger House, a student asked: isn’t this social sign-on? And it is. It’s exactly social sign-on, with the roles reversed.

Here, the Burger House is the app and Salesforce is the entrance. In social sign-on, Salesforce is the app, and Google or LinkedIn is the entrance. Change the names in the swim lane, Salesforce where the Burger House was, the social provider where Salesforce was, and it’s the same flow: Salesforce sends the person to the provider, gets a code back, swaps it, and learns who she is. Chapter 10 is that mirror image, and it’ll look familiar.

What’s next

Section titled “What’s next”

Module 5: the derivatives, the device flow and the token in the browser.

What an architect decides here

Section titled “What an architect decides here”
  • Whether an app needs identity, access, or both: openid for who, the API scopes for what.
  • That the app checks the ID token’s signature with Salesforce’s keys, and uses a nonce.
  • Salesforce or another identity provider as the login for each app (chapter 7, module 6).

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.