Federate SenseCrypt IdP with Salesforce

The authorization model is untouched. Role hierarchy, profiles, permission sets and sharing rules go on deciding record access exactly as your administrators configured them. Only the act of proving identity, before the org opens at all, is different.

The reason to change that step is the population performing it. Field sales and support staff authenticate from hotel lobbies, customer offices and machines belonging to somebody else, usually in a hurry and often mid-call. Those are the conditions under which a password and a verification code end up with whoever asked most convincingly.

External single sign-on has been part of Salesforce for many years, so this connection is made on its standard single sign-on settings. There is no pre-built connector. Federation is standard OIDC or SAML 2.0 configuration on both sides.

Both are supported, and the choice usually follows your team's habits. Most Salesforce administrators have configured SAML 2.0 before, and picking it keeps this connection the same shape as the ones already in production.

OpenID Connect is the stronger foundation for a new build. PKCE (RFC 7636) removes the value of an authorization code lifted in transit, and pushed authorization requests (RFC 9126) submit the request server to server instead of through the address bar. Whichever you choose, the response carries a signature and Salesforce verifies it before reading an attribute.

The ceremony does not vary with the protocol. What the user sees on their phone is the same either way.

This is console work rather than an engineering project. Field mapping decides whether the rollout is quiet: if the identifier arriving from SenseCrypt IdP does not match what the org expects, a user will pass authentication and still arrive nowhere useful.

Keep the current login route live until one test user has completed a sign-in on a real phone. Move a team rather than a company, and give the first group two weeks before widening the change.

1. In the SenseCrypt IdP console, register the Salesforce org as a SAML service provider (or as an OIDC application).
2. Attach at least one SenseCrypt IdP group to the application; with none attached, nobody can sign in.
3. Collect the metadata file for SAML 2.0, or the discovery URL for OIDC.
4. Import that configuration into the Salesforce single sign-on settings.
5. Map the claims to Salesforce user fields, the roles attribute included.
6. Point the group you are moving first at the new sign-in route.
7. Turn on SCIM 2.0 if accounts should be opened and closed automatically.
8. Enroll one test user and complete a face sign-in before anybody else is routed.

A Salesforce org holds pipeline, pricing, contracts and the contact history of every customer relationship you have. That makes its sign-in page a standing target, and the credential in front of it the cheapest thing an attacker can buy.

Social engineering has also moved past email. In a fraud reported in February 2024, a finance employee at the engineering firm Arup authorized transfers of roughly US$25 million after a video call in which colleagues had been convincingly deepfaked. A persuasive impression of a known person is now inexpensive, so any control resting on a human recognizing a face or a voice on a screen is weaker than it looks.

SenseCrypt IdP moves the presence check from human impression to a measured liveness test at the camera, on a phone enrolled to a specific person, with a signed result at the end. Where an org needs origin-bound phishing resistance, require the passkey method.