Checkpoint challenge
Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter The Mirror Image: Social Sign-On and Delegated Authentication, chapter 10 of Securing Salesforce: Identity and Access.
Scenario
Section titled “Scenario”Your lab has the same two Salesforce orgs as chapters 6 and 7, each with its own My Domain and logo, an admin who never uses single sign-on, and Priya Sharma as the test user in both.
In chapter 7, Priya logged in from one to the other with SAML. Now you do it the other way Salesforce offers: OAuth and OpenID Connect, through an auth provider. The identity provider org plays Google. The service provider org, called the relying party here, plays Salesforce in the mirror.
Requirements
Section titled “Requirements”- The identity provider org has an external client app for the service provider org, with OAuth on.
- The service provider org has an auth provider of type Salesforce, using that app’s key and secret, with PKCE on.
- A registration handler that only matches Priya’s existing user, and never creates one.
- Priya logs in from the service provider org’s login page, through the identity provider org, and lands as the service provider org’s Priya.
Constraints
Section titled “Constraints”- Lab orgs only. No company data, nothing personal.
- Never for an admin. Both admins keep a password and MFA.
- Your own external client app, not the Salesforce-managed one, which “isn’t recommended for production” (S5).
- Priya’s email: the same address in both orgs, and used by no other user in the service provider org. The handler matches on it. A plus address of your own mail works, such as
you+priya@yourmail.example.
Your task
Section titled “Your task”1. Check where you are. Log in to both orgs as their admins, in two different browsers so the sessions don’t mix. Check the logos. On Priya’s user record in each org, check her email, and that no other user in the service provider org has it.
2. Make the handler, in the service provider org. From Setup, Apex Classes, New, paste module 3’s skeleton, MatchExistingUsersHandler, and save. If it won’t save, the error names the line; compare that line with module 3.
3. Make the app, in the identity provider org. In External Client App Manager, create a local external client app, “Service provider org login”. In its OAuth settings, enable OAuth and set the callback URL to https://example.com/callback for now: you’ll replace it in step 5. Choose the scopes for OpenID Connect and her basic information: openid, and the identity URL service (id, profile, email). Salesforce shows each one with a longer label. Leave PKCE required. Save, then copy the consumer key and the consumer secret somewhere private.
4. Make the auth provider, in the service provider org (S5). From Setup, Auth. Providers, New:
| Field | Value |
|---|---|
| Provider Type | Salesforce |
| Name | Identity provider org |
| URL Suffix | IdentityProviderOrg |
| Consumer Key, Consumer Secret | from step 3 |
| Authorize Endpoint URL | https://YOUR-IDP-DOMAIN.my.salesforce.com/services/oauth2/authorize |
| Token Endpoint URL | https://YOUR-IDP-DOMAIN.my.salesforce.com/services/oauth2/token |
| Use Proof Key for Code Exchange (PKCE) Extension | on |
| Registration Handler Type | Apex |
| Registration Handler | MatchExistingUsersHandler |
| Execute Registration As | the service provider org’s admin (in production, a system user) |
Use the identity provider org’s My Domain for both endpoints: Salesforce recommends it, and the paths must end in /services/oauth2/authorize and /services/oauth2/token (S5). Save.
5. Copy the callback back. On the saved auth provider, under Client Configuration URLs, copy the Callback URL. In the identity provider org, open the external client app and replace https://example.com/callback with it (S5). This is chapter 9’s rule again: the callback address must match.
6. Test it, as Priya. Copy the Test-Only Initialization URL from the auth provider. Open a private browser window, paste it, and sign in at the identity provider org as Priya. Approve the app. Read what comes back: the information the identity provider org sent about her.
7. Put the button on the login page, in the service provider org. In My Domain’s settings, under Authentication Configuration, click Edit, select the auth provider as an authentication service, and save.
8. Log in, for real. In a new private window, open the service provider org’s My Domain login page. Click the button for the identity provider org. Sign in there as Priya, and you land in the service provider org. Check the logo, and check whose name is in the corner.
9. Look at the link. As the service provider org’s admin, open Priya’s user record. Under Third-Party Account Links you’ll see the link the auth provider made between her two users (S5). The next time she logs in this way, updateUser runs instead of createUser.
Discussion
Section titled “Discussion”How is this different from chapter 7’s SAML login? With SAML, the identity provider org sent a signed assertion through the browser, and the service provider org matched Priya by her Federation ID. Here, the browser carried only a code; the service provider org swapped it server to server, asked who she was, and your registration handler matched her. Two front doors, the same result.
Who was the client, and who was the server? The service provider org was the client: it asked for Priya’s information. The identity provider org was the server: it gave it.
Why does the handler refuse when it finds two users with her email? Because it would have to guess, and a wrong guess logs someone in as somebody else. Refusing is the safe answer, and an admin can fix the data.
What would have happened with a handler that created a user for anyone? Any user of the identity provider org who found the button would get a user in the service provider org, with a licence. In this lab, that’s two orgs you own. With Google, it’s anyone with a Google account.
Whose MFA did Priya use? The identity provider org’s, where she signed in. The auth provider’s Use Salesforce MFA for this SSO provider setting would add the service provider org’s own, for users who have MFA applied to them directly (S5).
Check your lab
Section titled “Check your lab”- The app: local, in the identity provider org, with OAuth on and the auth provider’s callback URL.
- The auth provider: type Salesforce, in the service provider org, both endpoints on the identity provider org’s My Domain, PKCE on.
- The handler: matches one existing user by email, refuses otherwise, creates no one.
- The login: from the service provider org’s login page, through the identity provider org, as Priya, not the admin.
- The link: under Third-Party Account Links on Priya’s record.
Exam objectives exercised
Section titled “Exam objectives exercised”- TPI-3 (choosing the authentication mechanism for accepting third-party identity): an auth provider beside SAML.
- COM-2 (supporting external identity providers): the same setup a community uses for social sign-on.
Explore
Section titled “Explore”- Configure a Salesforce Authentication Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- RegistrationHandler Interface (opens in a new tab) (Apex Reference Guide; checked 2026-11-07)