Salesforce Identity and Access Management Interview Questions

The user hits a Salesforce URL — say a deep link to a record — and has no session.

1. Salesforce sees the org is configured for single sign-on and builds a SAML AuthnRequest, recording where the user was trying to go in RelayState.
2. The browser is redirected to the identity provider's login URL, carrying that request.
3. The identity provider authenticates the user however it likes — password, certificate, multi-factor prompt — which is the whole point: Salesforce never sees the credential.
4. The identity provider builds a signed assertion and posts it, via the browser, to Salesforce's Assertion Consumer Service URL.
5. Salesforce validates the signature against the certificate held in the single sign-on settings, checks that the issuer matches, that the audience is this org, that the recipient is this ACS endpoint, and that the current time falls inside the assertion's validity window.
6. It resolves the subject to a user — by username, Federation ID, or User ID, depending on the configured identity type — establishes the session, and redirects to the URL held in RelayState.

The reason I tell it this way in an interview is that every common failure maps to one of those checks: signature to the certificate, audience and recipient to a My Domain or sandbox mismatch, validity window to clock skew, subject resolution to the Federation ID.

In federated authentication the identity provider authenticates the user and sends Salesforce a signed assertion. Salesforce never receives the password. That is SAML, and it is the default recommendation.

In delegated authentication the user types their password into Salesforce, and Salesforce makes an outbound SOAP callout to a web service you host, passing the username, the password, and the source IP. Your service returns true or false.

I recommend delegated authentication in one situation: the credential store can only be queried, not federated with — a legacy system with no SAML or OpenID Connect capability — and the population is small enough that the added risk is contained. Two consequences have to be stated out loud when I do. First, the password is now transiting Salesforce, which is exactly what federation avoids. Second, that endpoint is now on the critical path for login: if it is slow or down, those users cannot get in at all, so its availability target becomes an authentication requirement. It is enabled per user through the single sign-on permission on a profile or permission set, which at least lets me scope it to the population that needs it rather than the whole org.

Trust is certificate-based. I give Salesforce the identity provider's issuer value and its public signing certificate. From then on, Salesforce accepts an assertion if it is signed by the matching private key, names this org as the audience, and is addressed to this org's Assertion Consumer Service endpoint. There is no shared secret and no requirement for a common public certificate authority — self-signed identity provider certificates are normal, because Salesforce trusts the specific certificate I uploaded.

What breaks it, in the order I see it: a signing certificate that expired and was rotated at the identity provider without being replaced in Salesforce; a My Domain change or a sandbox refresh that moves the audience and ACS URL out from under an identity provider still pointing at the old values; and clock drift on the identity provider host, which pushes assertions outside their validity window and produces intermittent failures.

The operational lesson I bring to design reviews is that certificate rotation needs to be a calendared, owned process on both sides. It is the most predictable outage in the whole identity stack and it is always treated as a surprise.

The scope of the symptom is the diagnostic, and it points squarely at that user's data rather than at configuration. Configuration failures are democratic — they break everyone at once.

My sequence is: open Login History and find the failed attempt, because it records the specific single sign-on error and the source IP. Then look at the user record for the identifier the configuration relies on — usually the Federation ID. The recurring causes are a blank Federation ID, a duplicate value shared with another user, a case mismatch (it is treated as case-sensitive), a user who is inactive or has lost their licence, and login hours or IP ranges on the profile that happen to bite this person.

If that does not resolve it, I capture the actual assertion and run it through the SAML Assertion Validator, which tells me the subject value the identity provider is really sending — often different from what the directory team believes it is sending.

An org-wide failure is a configuration or certificate event, and the first question is what changed — on either side.

1. Login History and the error text: signature validation, audience mismatch, and expired assertion each point somewhere different.
2. Certificate expiry. The single most common cause. The identity provider rotated a signing certificate, or the certificate in the Salesforce single sign-on settings expired.
3. My Domain or endpoint changes. If My Domain was changed, or the identity provider's application was reconfigured, the audience and recipient no longer match.
4. Clock drift on the identity provider host, if the failures are intermittent rather than total.
5. The My Domain authentication configuration — someone may have unchecked the single sign-on option, leaving a valid configuration nobody can reach.

Two things I always cover in the same breath. First, a break-glass administrator account that does not depend on single sign-on, held under proper controls, so the org is recoverable. Second, the Setup Audit Trail, which will usually name the change and the person within a minute of looking.

I choose by constraint rather than by name, because that is how the requirement arrives.

• Authorisation code flow (web server flow) — a user is present and the client can protect a secret. Server-side web applications.
• Authorisation code flow with PKCE — a user is present but the client cannot protect a secret. Single-page applications and native mobile apps. This has replaced the older user-agent (implicit) flow, which returned the token in a URL fragment.
• JWT bearer flow — no user present, no password permitted. Server-to-server integrations, signed with a certificate, with the user pre-authorised on the connected app.
• Device flow — the device has no usable browser or keyboard. The user completes authentication on a second device while the first polls.
• Refresh token flow — not a way in, but how an existing grant is renewed without re-prompting.
• Client credentials flow — the application acts as itself against a designated run-as user, with no end user in the picture.
• Username-password flow — I name it so the panel knows I know it, and then say I do not use it: it stores the credential the rest of the model exists to eliminate, and Salesforce blocks it by default in newer orgs.

PKCE — Proof Key for Code Exchange — closes the gap that makes the plain authorisation code flow unsafe for a client that cannot keep a secret.

The client generates a random code verifier, hashes it into a code challenge, and sends the challenge with the authorisation request. When it later redeems the authorisation code, it must present the original verifier. Salesforce hashes it and compares. So an attacker who intercepts the authorisation code — through a malicious app registered for the same custom URL scheme, or a leaky redirect — cannot exchange it, because they do not have the verifier.

Why it matters practically: it is what lets a mobile or single-page application use the authorisation code flow at all. The alternative used to be embedding a client secret in a distributed binary, which is not a secret, or using the implicit flow, which put the access token in a URL where it ends up in history and referrer headers. PKCE removes the need for either.

A scope is a boundary on what a token can do, and it is independent of the user's profile and permission sets. Both apply: the token can never exceed the user's permissions, but the scope can restrict it far below them. That second boundary is what limits the blast radius when a token leaks.

My working rules: an API-only integration gets api, plus refresh_token only if it genuinely needs a long-lived grant. A sign-in use case gets openid, which is what produces an identity token, with profile or email for the claims it needs. I avoid full unless there is a specific reason, because it grants everything the user can do, and I avoid adding web or visualforce to an integration that never opens a page.

I also pair scopes with the rest of the connected app policy, because scope alone is not the whole control: permitted users set to admin-approved so the app cannot be self-authorised, a refresh token policy suited to the client, IP relaxation scoped to that app rather than the org, and a dedicated integration user rather than a person's account.

When a client completes an interactive flow with the refresh token scope, it receives a refresh token alongside the access token. Access tokens are short-lived; the refresh token is exchanged for new ones without prompting the user again. That is what keeps a mobile app signed in for weeks.

The connected app's refresh token policy is where the lifetime is governed: valid until revoked, immediately expired, expires after a fixed period, or expires if it has not been used for a set period. For a field mobile app I choose the inactivity-based policy. Active engineers are never interrupted, but a device that goes quiet for the threshold period loses its access automatically — which is the practical control for handsets that are lost, resold, or left in a drawer after someone leaves.

The point I make sure lands is that a refresh token is a live credential that survives the identity provider. Disabling someone in Active Directory does not touch it. Offboarding has to deactivate or freeze the Salesforce user and revoke the tokens, or that mobile app keeps working.

They answer different questions, and conflating them is the source of a lot of muddled design.

• SAML is an authentication protocol. It answers “who is this user?” by having an identity provider send a signed XML assertion to a service provider. It is the workhorse for enterprise web single sign-on.
• OAuth 2.0 is an authorisation protocol. It answers “may this application act on this user's behalf, and how far?” It issues tokens with scopes. On its own it says nothing reliable about who the user is.
• OpenID Connect is a thin identity layer on top of OAuth 2.0. Requesting the openid scope adds a signed identity token with standard claims, plus a UserInfo endpoint and a discovery document. It is how you get authentication out of an OAuth exchange properly.

In Salesforce terms: SAML single sign-on settings for inbound enterprise authentication, Auth. Providers for inbound social and OpenID Connect identity, and connected apps for outbound — Salesforce as a SAML identity provider or as an OpenID Connect provider, and as the authorisation server for API integrations.

I start by separating the three concerns, because they have different mechanisms: authentication, provisioning, and de-provisioning.

Authentication is SAML to the corporate identity provider. Provisioning and de-provisioning I put on a push mechanism — the identity provider's own Salesforce connector, or a general-purpose provisioning product, driving Salesforce's SCIM-based user provisioning. That is the part that can create a user before they first log in, update attributes when someone moves department, and deactivate a leaver on the day they leave.

I will often add just-in-time provisioning on top, so attributes and permission set assignments refresh at each login. But I am explicit that just-in-time provisioning cannot be the whole answer: it only fires when someone logs in, and it has no mechanism to deactivate anyone. An org relying on it alone accumulates active accounts for people who left, which is a finding waiting to happen.

One thing I flag on Active Directory projects: Identity Connect used to be the Salesforce-provided answer here, but Salesforce has announced its retirement and is not building a replacement, so a new design should be built on a third-party provisioning tool or the SCIM APIs.

Four, and I raise them before anyone commits to a design.

1. It only runs at login. A user who does not sign in never gets updated, so entitlements drift silently.
2. It cannot deactivate. There is no “this user has left” event, because a leaver by definition stops logging in. De-provisioning needs a push mechanism or a reconciliation job.
3. It is only as good as the attributes sent. A missing required attribute fails the whole assertion rather than partially provisioning, and the error surfaces to the user as a login failure.
4. Community provisioning is harder than internal. An external user needs a contact and an account, so the assertion has to carry enough to establish that chain, not just the user attributes that suffice internally.

None of that makes it a bad tool — it is excellent at keeping a user's attributes and permission sets current at the moment they arrive. It is just not a lifecycle solution, and the interview question is usually testing whether I know the difference.

I treat it as three layers, because stopping at the first one is the mistake I see most often.

1. Directory: disable the account at the identity provider. This stops new interactive single sign-on logins.
2. Salesforce user: freeze and then deactivate the user. Freezing is the immediate action — it takes effect instantly and does not require the licence to be freed — while deactivation may need record ownership to be reassigned first.
3. Tokens and app access: revoke the user's OAuth tokens. A refresh token issued to a mobile app or a desktop tool is a standalone credential that the identity provider never sees; it keeps working until it is revoked, the user is deactivated, or the connected app's refresh token policy expires it.

Alongside that I check anything that was configured to run as that person — scheduled jobs, integration connections, named credentials, connected app run-as users — because deactivating a user who is silently the identity of an integration turns an offboarding into an outage. Designing integrations to run as dedicated integration users rather than named individuals is what prevents that in the first place.

The question I actually answer is: where does the identity of record live, and who owns the login experience?

For employees, Salesforce is almost always the service provider. The enterprise already has an identity provider that authenticates people across dozens of applications; adding a second authority for one of them fragments the experience and creates a second place to reset a password.

Salesforce is the identity provider when it is where the population is defined and where the journey starts — commonly for partners and customers in an Experience Cloud site who need onward access to other systems, or when the App Launcher is being used as the front door to a set of third-party applications for a group of employees whose primary system really is Salesforce.

For consumer identity I ask the same question about a dedicated customer identity platform. If one already authenticates the consumer across several non-Salesforce channels, Salesforce should accept that identity and keep the contact and consent data. If Salesforce owns the login and the surrounding experience, Salesforce Identity for customers is a reasonable choice. What I will not do is put credentials in both and synchronise them.

Four steps, in order.

1. Ensure My Domain is deployed, then enable Salesforce as an Identity Provider and choose the certificate that will sign assertions — self-signed is fine, and its expiry goes straight into the rotation calendar.
2. Get the service provider's values from the vendor: Entity ID, Assertion Consumer Service URL, the Name ID format they expect, and any attributes they need.
3. Create a connected app with SAML enabled and enter those values, choosing the subject type — username, Federation ID, User ID, or a custom formula — that matches how the vendor identifies users on their side.
4. Assign the connected app through a profile or permission set. This is what makes the tile appear in the App Launcher and what actually authorises the user; without it the configuration exists but nobody can use it.

Then I test both directions — identity-provider-initiated from the App Launcher, and service-provider-initiated from the vendor's own login page — and use the Identity Provider Event Log to diagnose anything that fails, since that is where Salesforce records the assertions it issued.

The accepted factors are the Salesforce Authenticator mobile app, third-party time-based one-time password authenticator apps, physical security keys, and built-in platform authenticators such as fingerprint or facial recognition on a laptop or phone.

The distinction candidates most often miss: email and SMS one-time codes are not accepted as a multi-factor factor. They are identity verification methods, used when someone logs in from an unrecognised browser or device, and both channels are susceptible to interception and account-takeover attacks. Proposing SMS as the second factor is a common way to fail a security review.

When single sign-on is in place, the cleanest design is to satisfy the requirement at the identity provider — it already has the enrolment, the recovery process, and the policy engine, and Salesforce trusts the authentication described in the assertion. If Salesforce is still challenging those users, I do not disable multi-factor authentication; I look at what is demanding a higher assurance level than the single sign-on login method has been credited with. I would also confirm the current accepted-method list in Salesforce Help, because that guidance is revised over time.

Salesforce assigns every login and verification method a session security level — typically Standard or High Assurance — and specific resources can require the higher level. If a user in a Standard session reaches a resource that requires High Assurance, they are prompted to step up rather than simply refused.

A design I have used: a connected app exposing a payments integration, and report folders containing regulated data, both set to require High Assurance, with the multi-factor login method raised to High Assurance in session settings. Day-to-day work is unaffected; the moment someone opens the sensitive resource, they are asked to verify. The profile setting that requires a session security level at login is the blunter alternative when a whole population must always be at the higher level.

The reason I reach for this rather than profiles and permission sets is that assurance is a property of this session, not of the user. Encoding it as a static assignment loses that, and cannot react to how the person actually authenticated today.

A login flow is a screen flow that runs after authentication succeeds and before the user reaches their landing page. It is assigned by profile, so it can be scoped to a specific population.

Typical uses: capturing acceptance of terms or a data-processing notice on first login, forcing registration of a verification method, collecting or confirming a piece of profile data, presenting a security notice, or ending the session outright when a condition is not met.

What I make sure to say is what it cannot do, because the exam and real projects both probe it: it runs once, at login. It cannot react to something the user does an hour into the session. If the requirement is “block an unusually large export as it happens” or “require step-up when a risky action occurs”, that is Transaction Security in real-time event monitoring, not a login flow.

They sound alike and do three different jobs.

• Login IP ranges on a profile are a restriction: a user on that profile cannot log in from outside them at all.
• Trusted IP ranges under Network Access are a relaxation: a login from inside them does not trigger identity verification. Users outside them can still log in, they just have to verify.
• Connected app IP relaxation scopes an exception to a single application, so one integration can run from a datacentre that the profile restriction would otherwise block, without weakening anything for interactive users.

The mistake I look out for in reviews is someone adding a datacentre to trusted IP ranges to fix an integration that is being blocked by a profile login IP range. It looks plausible and does nothing, because the two controls are unrelated. The connected app setting is the right lever, and it has a middle option — enforce the restriction for the initial authorisation but relax it for token refresh — which is often the best fit when the first authorisation happens somewhere known.

Salesforce as the consumer identity store is attractive when Salesforce owns the customer-facing experience: one system, the login and the contact and the consent record all in one place, no integration to build, and the identity data is immediately usable in service and marketing.

A dedicated platform wins when the consumer touches several channels that are not Salesforce. It is built for very high authentication volumes, tends to move faster on authentication features, and — the decisive point — gives the consumer one login across every channel rather than one for the Salesforce-powered channel and another for the rest.

So I frame it as ownership of the identity of record rather than as a product comparison. If a platform already authenticates the consumer elsewhere, Salesforce should accept that identity as a service provider and keep the contact as the profile record. If Salesforce is the front door, Salesforce Identity for customers is a sound choice. The answer I refuse to give is “both, synchronised nightly” — two credential stores double the attack surface and guarantee drift.

• Salesforce Identity is for employees whose relationship with Salesforce is identity rather than CRM — single sign-on out to third-party applications, an App Launcher tile, connected app provisioning — without full CRM object access.
• External Identity is for consumer-scale external identity: registration, login, profile and consent management, with deliberately limited data access.
• Customer Community is the high-volume external licence. Those users have no role, which is why they cannot appear in sharing rules and why sharing sets and share groups exist for them.
• Customer Community Plus and Partner Community are role-based: users sit in an external role hierarchy under their account, participate in sharing rules, and get broader functionality. Partner Community adds the sales-oriented objects partners need.

The architectural point is that the licence sets a ceiling a permission set cannot lift. So the licence question belongs in requirements, not in build. “Can these External Identity users also work cases?” asked at the end of a project means re-licensing a live population; asked at the start it is a five-minute conversation. And because entitlements are revised over time, I confirm the current terms in the licence documentation rather than quoting figures from memory.

An Auth. Provider for each social network, and an Apex class implementing Auth.RegistrationHandler behind them. The Auth. Provider handles the protocol exchange; the handler owns the identity decision, which is where the real design sits.

In createUser I decide how to match: if a contact already exists with that verified email, link the new user to it rather than creating a duplicate; otherwise create the contact under the right account and then the user, assigning the profile and permission sets. In updateUser I keep attributes current on subsequent logins. I would also decide up front whether the data model is person accounts or consumer contacts under a bucket account, and say plainly that a bucket account concentrates children under one parent — the account data skew pattern — so the choice has to be made against expected volume.

Then the site-level configuration, which is the step people forget: each Auth. Provider has to be enabled on that site's login and registration settings before it appears. Beyond that I would cover what happens when a social account's email changes, whether matching on email alone is acceptable to the security team, and what the fallback is when a social provider is unavailable.

Embedded Login renders the Salesforce-hosted login experience inside a page on a non-Salesforce website, through a JavaScript include and a connected app. The visitor stays on the corporate site visually, but Salesforce is still rendering and processing the login, so the credential never touches the external application.

The Headless Identity APIs go further: registration, login, passwordless login and password recovery are exposed as endpoints, so the application owns the interface completely and Salesforce owns the credentials and issues the tokens. No Salesforce-rendered page appears anywhere.

I choose Embedded Login when the requirement is “inline on our website” and the team is happy for Salesforce to render the form — it is far less to build and maintain. I choose Headless Identity when there is a native mobile application, or a design system that will not tolerate an embedded frame, or a passwordless journey the team wants full control over. What I will not accept is the third option people propose: a hand-built form on the external site that collects the password and posts it to Salesforce. That puts the credential in the external application, cannot handle verification or step-up, and is the pattern security reviews exist to catch.

The guest user is the most constrained identity on the platform, deliberately. It cannot own records. Its access is private by default and can only be widened through guest user sharing rules, which grant read access. It cannot be added to public groups or queues, and it should never be given broad object permissions.

The design consequence people run into: an anonymous visitor submits a form, and the business wants a confirmation page showing what they submitted. Because the guest user cannot own the record, there is no ownership path back to it. So either the confirmation is rendered from the data already in that request, or the visitor authenticates — and if they are going to authenticate, that is a registered external identity, not a guest.

The pattern I actively reject is a sharing rule that matches records on an email address the visitor typed. It looks like it satisfies the requirement and it lets anybody read anybody else's submission by typing their email. If unauthenticated write access to a business process is genuinely needed, I would put a controlled Apex service or a web-to-case style intake in front of it rather than widening guest sharing.

An org can hold multiple SAML single sign-on configurations, so this is a configuration problem rather than an architecture problem. I create one configuration per identity provider and enable both — plus the standard login form if some population still needs it — on the My Domain authentication configuration.

For routing I use login discovery: the login page asks for an identifier, and a Login Discovery Handler Apex class decides what happens next based on it — redirect to identity provider A, redirect to identity provider B, prompt for a password, or send a one-time passcode. That gives one login URL for everyone, which matters because bookmarks and email links do not respect audience boundaries. The alternative is exposing both as buttons, which works but pushes the decision onto users who often do not know which company's directory they are in.

Two things I plan alongside it. First, the Federation ID namespace — if both directories issue employee numbers, they can collide, and the Federation ID must be unique across the org, so I would prefix or otherwise namespace them. Second, the merge path: this configuration should be explicitly temporary, with an agreed target of one identity provider, or it quietly becomes permanent and every future change has to be made twice.