Notifications
Clear all
Topic starter
16/08/2026 1:12 pm
TL;DR: OIDC setup, registration handlers, user mapping, and permission set configuration determine whether federated login actually works in practice, according to Descope’s Salesforce SSO guide. The article is useful because it exposes how much identity risk sits in executor permissions, profile design, and attribute handling, not in the button on the login screen.
NHIMG editorial — based on content published by Descope: Adding Salesforce SSO With Descope [Step-by-Step Guide]
Questions worth separating out
Q: How should security teams govern Salesforce SSO with OIDC?
A: Treat the federation flow as an identity lifecycle process, not just an authentication integration.
Q: What breaks when the Salesforce SSO executor user is misconfigured?
A: Provisioning and user updates can fail if the handler runs under an account without the right permissions or with an API-only restriction.
Q: How do you know if OIDC attribute mapping is working safely?
A: Check that mapped claims consistently populate only approved fields, that the fields already exist in Salesforce, and that no access-relevant data is being inferred from unmanaged custom claims.
Practitioner guidance
- Review the registration handler as a lifecycle control Validate how new users are created, existing users are matched, and attribute updates are applied.
- Separate executor privilege from end-user access Use a dedicated Salesforce user for handler execution, then scope it only to the permissions required for user management and Apex execution.
- Map claims only to pre-approved user fields Confirm that every OIDC claim used by AttributeMap has a corresponding Salesforce field and a defined business owner.
What's in the full article
Descope's full guide covers the operational detail this post intentionally leaves for the source:
- The exact Salesforce configuration sequence for creating the Auth Provider and registration handler.
- The Apex handler boilerplate for user creation, lookup, and updates in production use.
- The permission set and API Integration licensing steps needed to make the SSO flow work.
- The Experience Cloud login and registration setup that exposes the provider on a public-facing site.
👉 Read Descope's step-by-step guide to Salesforce SSO with OIDC →
Salesforce SSO with OIDC: where identity setup gets operational?
Explore further
16/08/2026 1:13 pm
Federated login does not remove identity governance work, it relocates it into the registration path. The article shows that SSO success depends on a handler that creates, updates, and reconciles users at the moment of authentication. That means the control problem shifts from password policy to lifecycle correctness, executor scope, and attribute trust. IAM teams should treat SSO as a governance workflow, not just an authentication protocol.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means identity teams often govern access without a complete inventory.
A question worth separating out:
Q: Who is accountable for access failures in federated Salesforce login flows?
A: The identity team and Salesforce administrators are jointly accountable for the federation design, but the business owner of the application remains accountable for the access outcomes. Authentication may be external, but lifecycle accuracy and privilege scope are local responsibilities.
👉 Read our full editorial: Salesforce SSO with OIDC exposes the real IAM setup burden
