Study guide
Study guide for chapter 10 of the Securing Salesforce: Identity and Access course. Read the five modules first; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This chapter carries two of the Identity and Access Management Architect exam’s objectives: choosing the mechanism for accepting third-party identity, in its Accepting Third-Party Identity section, 21% of the exam; and supporting external identity providers in communities, in its Community section, 18%. The exam guide aligns to Summer ‘23, so check its current version before you book.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
Social sign-on (supports TPI-3, COM-2)
- I can say who is the identity provider and who is the client in social sign-on. (Who’s the client?)
- I can walk social sign-on as the web server flow reversed: the button, the provider’s login and consent, the code, the swap, the user info. (Five steps, in the mirror)
- I can name the three single sign-on flows into Salesforce: SP-initiated SAML, IdP-initiated SAML, and social sign-on or OpenID Connect. (Three ways in)
Auth providers (supports TPI-3, COM-2)
- I know social sign-on is set up with an auth provider, and the choices: a ready-made type, OpenID Connect, or a custom one in Apex. (A ready-made list)
- I know not every type does single sign-on: GitHub and Microsoft Access Control Service don’t; X does, but gives no data access. (A ready-made list)
- I can put the pieces in order: the provider’s app, its key and secret, the URL suffix, the callback URL back into the provider’s app, the button. (The pieces)
- I know the button’s Icon URL shows only on an Experience Cloud site’s login page. (The button)
- I know the Salesforce type connects two orgs, with an external client app in the identity provider org. (Between two Salesforce orgs)
The registration handler (supports TPI-3, COM-2)
- I know social sign-on needs a registration handler, the
Auth.RegistrationHandlerinterface. (Two methods) - I know its two methods:
createUserthe first time,updateUserevery time after. (Two methods) - I know it runs as the Execute Registration As user, who needs Manage Users. (The user it runs as)
- I know it can be Apex or a flow. (Apex or Flow)
Where it fits (supports COM-2)
- I know social sign-on is most likely for customers on an Experience Cloud site, and staff come in through the company’s identity provider. (Three groups, three doors)
Delegated authentication (supports TPI-3)
- I can walk delegated authentication: Salesforce’s login page collects the password, calls your SOAP web service, and gets back true or false. (True or false)
- I know the permission is Is Single Sign-On Enabled, and Salesforce doesn’t store the password. (True or false)
- I know what it gives up: no password reset, and it doesn’t meet the MFA requirement. (What you give up)
- I know when to choose it: only when the store can’t learn SAML or OpenID Connect. (The better answer first)
Beyond the Exam
Section titled “Beyond the Exam”The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.
- A registration handler that checks before it lets anyone in, and refuses rather than guess.
- Validate the ID token before trusting a claim from it.
- PKCE on every auth provider, and your own app in production, not the Salesforce-managed one.
- Ask only for the data you’ll use, so the consent matches the need.
- Teach the legacy store SAML or OpenID Connect before you reach for delegated authentication.
- Keep admins off delegated authentication, so somebody can always get in.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Social sign-on | Logging in to Salesforce with an account at another provider, such as Google |
| Auth provider | The setup in Salesforce that sends people to another provider and brings them back |
| Relying party | The org that trusts another for login; here, Salesforce in the mirror |
| URL suffix | The auth provider’s name in the addresses Salesforce generates for it |
| Callback URL | Where the provider sends the person back with the code; goes into the provider’s app |
| Registration handler | The Apex class or flow that decides which Salesforce user she becomes |
Auth.UserData | The one shape Salesforce gives the handler, whatever the provider sent |
createUser | Runs the first time; returns a user, new or existing |
updateUser | Runs every time after; updates her user |
| Execute Registration As | The user the handler runs as; needs Manage Users |
| Delegated authentication | Salesforce asks your web service whether the password is right |
| Is Single Sign-On Enabled | The permission that sends a user’s password check to your service |
| Delegated Gateway URL | Your web service’s address, in Single Sign-On Settings |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. In social sign-on with LinkedIn, which system is the identity provider, and which is the client?
LinkedIn is the identity provider: it collects her credentials. Salesforce is the client: it asks LinkedIn for her information. Reread Who’s the client?.
2. A team is building social sign-on for a customer site. Which class do they implement, and with which two methods?
Auth.RegistrationHandler, with createUser and updateUser. Or they build it as a flow. Reread Two methods.
3. After social sign-on goes live, people with no relationship to the company are getting users and using up licences. What went wrong?
The registration handler creates a user for anyone who signs in. It needs checks before createUser returns anyone: who may come in, matched to whom, with which profile and licence. Reread The checks.
4. A company wants its staff to log in to Salesforce with their personal Google accounts, "to save setting up single sign-on". What do you say?
Staff should come in through the company’s identity provider, so leaving is one switch and the company sets their MFA. Social sign-on is for people nobody manages but themselves, such as customers. Reread Three groups, three doors.
5. A company's users and passwords live in an old directory. Its team can't change it, and it can't speak SAML. How can those users log in to Salesforce with those passwords?
Delegated authentication: give them Is Single Sign-On Enabled, and Salesforce sends each login to your SOAP web service, which answers true or false. Keep the admins off it. Reread True or false.
6. An org puts every profile on delegated authentication. One morning the web service is down. What happens, and what should have been different?
Nobody on delegated authentication can log in, admins included. Always keep some users, starting with the admins, on Salesforce passwords. Reread Don’t lock yourself out.
7. Two Salesforce orgs need their users to log in to one with the other's credentials, over OAuth. What do you set up, and where?
An external client app in the identity provider org, and an auth provider of type Salesforce in the other org with its key and secret; the auth provider’s callback URL goes back into the app. Reread Between two Salesforce orgs.
Explore
Section titled “Explore”- Authentication Provider SSO (opens in a new tab), Salesforce Help (Winter ‘27; checked 2026-11-07)
- Salesforce Certified Platform Identity and Access Management Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-07)
The official list of objectives and their weights. Always check the current version before you book an exam.
