How authentik signs Salesforce users in over SAML
authentik acts as the SAML identity provider and Salesforce acts as the service provider, so every Salesforce login is checked against the directory and policies you already run in authentik. The integration follows the Salesforce guide in the authentik integrations catalog, which is the starting point for the SAML provider, application and bindings. This section explains the model before you configure anything, because the three parts the page covers depend on each other: just-in-time (JIT) provisioning, profile assignment and SCIM provisioning.
The first part is JIT. When a user signs in to Salesforce for the first time, Salesforce can create the user from the SAML assertion, but only if the assertion carries the attributes it needs, such as the username, email and name fields. Those attributes are emitted through property mappings that you create in authentik, so the names and formats in the assertion must match what the Salesforce side expects. Confirm the exact attribute names and the federation identifier with the current guide and with your Salesforce admin before you test, since mismatched names are the most common reason a first login fails.
The second and third parts decide what a user can do after the account exists. Profile assignment is the Salesforce-side choice of which profile and permission sets a JIT-created user receives, and it is set in Salesforce rather than in authentik. SCIM provisioning is a separate, optional path that lets authentik create, update and deactivate Salesforce users ahead of login, which matters for leavers and role changes. Whether your Salesforce edition and org allow the SCIM and API access you plan to use should be checked against your agreement and the org's API limits before scoping the work.
What you need before connecting Salesforce to authentik
Six prerequisites have to be in place before any SAML settings are exchanged. Most delays come from one of them being assumed rather than checked, so confirm each item with the owner who controls it.
A supported authentik release
Run authentik on a release that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance, so plan a maintenance window for patches. Confirm your version with the authentik release notes before you start the Salesforce configuration, since a SAML provider built on an unsupported line will need rework after an upgrade. Check the running version on the admin interface, not the version in your deployment template.
A Salesforce edition with SAML SSO
Confirm that your Salesforce edition includes SAML single sign-on and the API access your integration needs. Edition rules change, so check the current Sales Cloud pricing page and your customer agreement at the time of purchase rather than relying on a team memory of last year's contract. Also confirm which Sales Cloud tier and add-ons your users are licensed for, because just-in-time provisioning and SCIM depend on what your org can do.
Salesforce admin access and a My Domain
You need an administrator who can change single sign-on settings, create profiles and permission sets, and manage connected configurations. A My Domain must be deployed and active, because the SAML login and identity provider settings are tied to that domain. Record the exact My Domain name now, since changing it later affects every bookmark, SSO URL and connected app that points at the org.
A sandbox or test org
Test the connection in a sandbox or a separate test org before you touch production. Use a copy of your production org structure where possible, so profiles, roles and permission sets behave the same way. Plan who will sign in during testing, including at least one test user with the same profile as a real user, and confirm the sandbox has its own My Domain, because the SAML settings must be created separately in each org.
Certificate and metadata exchange path
Decide how the signing certificate and endpoint metadata move between authentik and Salesforce, and who approves each change. Assign an owner for the signing certificate, record its expiry date, and agree on the process for renewal, since a certificate that lapses breaks sign-in for every user. Store the metadata in your change system rather than in a chat thread, so the production and sandbox values stay traceable.
Agreed user and attribute source
Define which authentik users may sign in to Salesforce and which attributes carry their identity, including the username, email, first name, last name and profile. Just-in-time provisioning creates users at first login only if these SAML attributes arrive in the expected form. Confirm with your Salesforce admins which profile each group maps to, and document who approves new groups. Without this list, the first pilot usually exposes mismatched names and missing emails.
Configuration sequence for the SAML connection
This sequence builds a working SAML trust between authentik and a Salesforce org, with just-in-time user creation at first login, and proves it in a sandbox before any production user depends on it. Each step ends with a check you can record before moving on.
Create the SAML provider in authentik
An authentik administrator creates a SAML provider that will represent Salesforce as the service provider. Set the ACS URL and entity ID to the values Salesforce shows for your org's SAML SSO configuration, choose the signing certificate and the NameID property you intend to use, and bind the provider to the authorization flow your users already pass through. The step is complete when the provider saves without validation errors and its metadata endpoint returns an XML document in your browser. Confirm the exact field names and values against the authentik integrations guide for Salesforce, since the Salesforce-side URLs come from your org.
Define the JIT attribute property mappings
Create the SAML property mappings that Salesforce needs to create a user at first login. The authentik integrations guide for Salesforce documents the mappings used for just-in-time provisioning, so use its attribute names and map each one to the matching authentik user field, such as the username, email, first name and last name. Attach the mappings to the SAML provider's property mapping list. The check is an attribute preview for a test user that shows every required value populated and no empty fields for the attributes Salesforce expects.
Create the application and bind the provider
Create an authentik application that points to the SAML provider, set its launch URL to your Salesforce login route, and assign access through a group or policy so that only intended users can start the flow. Keep the application slug stable, because it appears in the URLs you will test later. The step is complete when the application appears in the user library of a test account and the provider is listed as bound to it. Record which group controls access, since you will reuse it for the pilot.
Export the authentik metadata and certificate
Download the SAML metadata from the provider and save the signing certificate separately. Check that the metadata contains the IdP entity ID, the single sign-on endpoint and the X.509 certificate, and that the certificate has not expired. Store both files in your change record with the date you exported them, because a later certificate rotation in authentik will require this step again. The check is opening the metadata file and confirming the entity ID matches the value you configured in the provider.
Configure the SAML SSO setting in Salesforce
A Salesforce administrator creates a SAML single sign-on setting in the sandbox org, uploads the authentik metadata or enters the entity ID, SSO endpoint and certificate manually, and sets the federation ID and user identity mapping to match the NameID and attribute values authentik sends. Enable just-in-time provisioning on that setting and link it to the correct profile. Do not enable it for the production org yet. The check is that the setting saves and Salesforce shows the login endpoint and entity ID values you expect.
Test sign-in in a sandbox
Open a private browser session, start from the authentik application, and sign in as a test user who does not yet exist in the sandbox org. Confirm that Salesforce creates the user at first login and places the user under the profile you assigned. Then review the SAML response in an authentik event or log view, and check that the NameID value and each JIT attribute arrived with the expected content. Repeat the test with a user who already exists to confirm matching behaves as planned. Record the result for each test user before continuing.
Enable for a pilot group
Enable the SAML setting for a small pilot group, using a Salesforce permission or a limited login mechanism so that other users continue to sign in through the existing method. Ask the pilot users to sign in through authentik from a private session and confirm that their Salesforce profile, role and access match what they expect. Keep the fallback login available until the pilot results are reviewed. The step is complete when the pilot group signs in successfully and the results are documented. Confirm with Salesforce how your org's login settings interact with this pilot approach before you start.
Which SAML attributes map to Salesforce user fields
This table compares each Salesforce user field with the authentik attribute that typically feeds it during just-in-time provisioning. Confirm every attribute name against the current property mappings in the authentik Salesforce guide before you build, because the guide defines what JIT expects. The key takeaway is that the federation ID is the field most likely to cause duplicate or locked-out users if it changes.
| Salesforce field | Typical authentik source | Notes for the build |
|---|---|---|
| Federation ID | A stable, unique user identifier such as the authentik user UUID or a fixed employee ID | Must be unique and must not change for the life of the user. Avoid email addresses if they can be renamed. |
| Username | A value in the form of an email address, unique across all Salesforce orgs | Salesforce usernames are globally unique. Plan a naming rule before the first login. |
| The authentik user email attribute | Used for notifications and often for matching. Confirm the mapping name in the guide. | |
| First name | The given name attribute from the authentik user profile | Required at creation. Confirm the SAML attribute name the JIT mapping expects. |
| Last name | The family name attribute from the authentik user profile | Required at creation. Missing values can block JIT user creation. |
| Profile | A group or attribute that the JIT handler reads and maps to a Salesforce profile | Confirm whether your org assigns profiles through JIT or after first login, and test each profile in a sandbox. |
| Permission sets | A group or attribute mapped to permission set assignments | Confirm support for permission set mapping in the current guide. Assign elevated access manually if it is not supported. |
Just-in-time provisioning versus pre-created users
With just-in-time (JIT) provisioning, Salesforce creates the user record the first time a person signs in through authentik. The SAML assertion carries the attributes Salesforce needs to build the account, such as the username, email, first name, last name and federation ID. authentik's Salesforce guide uses property mappings to put those attributes into the assertion, and Salesforce uses them to create the user at login. No administrator has to create the account beforehand.
- Account creation: The user record appears at first login, so the attribute mappings must send every value Salesforce requires for user creation.
- Profile and role assignment: JIT handler settings determine the profile and role a new user receives, so those defaults act as the access decision.
- License consumption: A license is consumed when the account is created, which can happen for people who sign in once and never use the org.
- Approval point: Approval moves to the identity layer, so access depends on who can reach the authentik application and its policies.
- Attribute dependence: A missing or malformed attribute can block account creation at first login.
Before enabling JIT, confirm the exact attributes and profile defaults in the current authentik and Salesforce documentation for your edition.
With pre-created users, an administrator creates the Salesforce user in advance, and the SAML login matches that record by federation ID or username. Salesforce does not build a new account at login, so the profile, role and permission set are set before the person first signs in. The authentik assertion must carry the value that Salesforce uses to match the existing user, so identity mapping is the critical step.
- Account creation: Users are created by an administrator or an onboarding process, and login only matches the existing record.
- Profile and role assignment: Profiles, roles and permission sets are fixed by the administrator before first sign-in, which gives a review point.
- License consumption: Licenses are assigned when accounts are created, so the org can see paid seats before anyone logs in.
- Approval point: Approval happens in the provisioning request or ticket that creates the Salesforce user, separate from the authentik login.
- Matching risk: A mismatch between the federation ID and the stored value causes login failure, so test matching for each user group.
Confirm with your Salesforce administrator which matching field your org will use and how it is populated.
The right model depends on how many users join, how strictly access is approved and how tightly the org manages licenses. JIT suits a stable population where the identity provider already holds the authoritative role data and where the org accepts that accounts appear at login. Pre-created users suit orgs that need an approval record for each Salesforce user and that buy licenses against a fixed headcount. Many teams start with pre-created users while they validate mappings, then decide whether JIT reduces their administrative work.
- Small, stable teams: Pre-created users keep administration simple and make license counts easy to audit.
- Large or frequent joiners: JIT reduces manual account creation but depends on clean attribute data.
- Regulated access reviews: Pre-created accounts give a clear approval trail in the provisioning system.
- Contractors and external users: Pre-created accounts usually suit people whose access should be created deliberately.
- Hybrid options: Some orgs pre-create administrators and let JIT handle standard users, which requires separate profile rules.
Ask your Salesforce administrator how many licenses your edition and contract allow and who signs off on new accounts before choosing.
License cost and access approval are where the two models differ most for finance and security leaders. Under JIT, the act of signing in can consume a license, so an unexpected login path can add paid seats. Under pre-created users, the purchase and the account creation are visible together, which makes the seat count easier to reconcile. Pricing details come from Salesforce's own order forms and agreements, so the license terms that apply to your contract should be confirmed directly with your Salesforce account team.
- Seat reconciliation: Compare active Salesforce users with the authentik group that should have access each month.
- Approval source: Decide whether the authentik group, the Salesforce admin or an access request system is the approver of record.
- Deactivation: Plan how a removed authentik user loses Salesforce access, since JIT does not remove accounts on its own.
- Contract terms: Confirm with Salesforce how licenses are counted for your edition under the customer agreements.
- Reporting: Set up a recurring report that lists users created, activated and last logged in.
Ask your Salesforce account team to confirm how license counts and API limits apply to your org before you choose.
When to add SCIM provisioning and what it changes
SAML decides how users sign in to Salesforce, while SCIM decides how their accounts are created, changed and removed. The cards below cover what SCIM adds, what it depends on in the Salesforce org, and the limits to check before you commit to it.
SCIM is a separate decision from SAML
SAML sign-in only works for a Salesforce user record that already exists. Just-in-time provisioning creates that record at first login, but it does not update or remove it later. Adding SCIM from authentik means choosing a second integration that manages the user lifecycle independently of the login flow. Decide on it separately, and confirm with your Salesforce admin which user fields the org needs before you build either piece.
Create, update and deactivate in Salesforce
With SCIM, authentik can send create, update and deactivate operations for each user to Salesforce. Creation removes the need to wait for a first login. Updates keep names, email addresses and role-related attributes aligned with the directory. Deactivation is the control that matters most for leavers, because a user who keeps an active Salesforce license can still sign in. Test each of the three operations against a sandbox before production.
Confirm provisioning options for your edition
Whether Salesforce offers a SCIM or user provisioning path, and what it requires, depends on your org edition, license type and the Salesforce agreement you hold. Ask your Salesforce account team and check the current documentation for your edition before planning. Do not assume a feature available in one edition or suite is available in another, and record the answer in the design document.
Check API call limits against user count
Provisioning calls count against the org's API allowance. The Salesforce limits reference gives an Enterprise Edition org with API access 100,000 calls per 24 hours plus 1,000 per Salesforce license, so an org with 15 licenses has a limit of 115,000 requests per 24 hours. Estimate the calls your sync, login-time reads and other integrations will make, then confirm the limit for your edition and whether extra licenses or add-ons are needed.
Plan for rollback and duplicate accounts
Before enabling SCIM, check whether accounts already exist in Salesforce with the same username or email as the users authentik will provision. Matching identifiers must be agreed first, because a mismatch can create duplicate users or deactivate the wrong record. Keep a documented way to disable the SCIM connection and restore the previous state, and test that path in a sandbox.
Confirm the deprovisioning sequence
Removing a leaver involves more than disabling the authentik account. Confirm how long existing sessions remain valid, whether Salesforce deactivation runs on the same schedule as the authentik change, and who owns records the user owned. Write the sequence down with the Salesforce admin so that a departed employee cannot keep working in the org through a session that was never revoked.
Common SAML and JIT failures and how to fix them
This table lists the failures teams hit most often when authentik signs users in to Salesforce over SAML with just-in-time provisioning, with the likely cause and the fix for each. Work through the rows in order at first login, because a wrong audience or ACS URL blocks everything downstream of it.
| Failure | Likely cause | How to fix it |
|---|---|---|
| Audience or ACS URL mismatch | The SAML provider in authentik uses an ACS URL or audience (entity ID) that does not match the Salesforce My Domain login endpoint and SAML settings for the org. | Copy the ACS URL and entity ID from the Salesforce SAML configuration exactly, including the My Domain host, then re-export or re-enter the metadata in authentik and retest a fresh sign-in. |
| Missing JIT attributes | The assertion lacks the attributes Salesforce needs to create a user at first login, such as the username, email, first name and last name, or the property mappings were never bound to the provider. | Confirm the property mappings from the authentik Salesforce guide are attached to the SAML provider, then inspect a sample assertion to check each required attribute is present and named as Salesforce expects. |
| Malformed attribute values | Values contain extra whitespace, a username that is not in email format, or an email that does not match the Salesforce username, so Salesforce rejects the user record. | Normalize values in the authentik expression or source mapping, make the Salesforce username an email-style value, and test with one account before enabling the flow for all users. |
| Federation ID collision | An existing Salesforce user already holds the same federation identifier or username, or a user was created manually with a different identifier, so JIT cannot match or create the account. | Search the org for the conflicting username or federation ID, decide which record is canonical, and align the value sent by authentik with it. Avoid deleting active users to clear the conflict. |
| Profile not assigned at first login | JIT creates the user but no profile or permission set is assigned from the assertion, so the user signs in with no access or the login fails. | Map a profile or role attribute in the assertion using the Salesforce JIT handler configuration, and confirm a default profile applies when the attribute is absent. Test with a user in each intended profile. |
| Expired signing certificate | The certificate used by authentik to sign assertions, or the Salesforce certificate, has passed its validity date, so signatures fail validation. | Check certificate validity dates on both sides before go-live, set a renewal reminder, and plan the replacement in both authentik and Salesforce so the old and new certificates overlap for a short window. |
| Clock skew between systems | The authentik server, the Salesforce validation or the user's device clock differs enough that assertion timestamps fall outside the accepted window. | Confirm the authentik hosts run time synchronization with a trusted source, then compare assertion timestamps in logs with Salesforce login history before changing any SAML validity settings. |
| Login IP or session restrictions | Salesforce login IP ranges, session timeout or login hour settings block the user even after a successful SAML response, or the profile restricts the login source. | Review the profile's login IP restrictions, login hours and session settings, and the org's network access rules. Adjust only the restrictions that apply to SAML users and document the change for auditors. |
Questions buyers ask before connecting Salesforce to authentik
How much does it cost to connect Salesforce to authentik?
The authentik software cost depends on the edition you run. The Open Source edition is free and offers community Discord support only. The Enterprise edition is listed at $5 per user per month billed annually, plus $0.02 per external user per month, according to the authentik pricing page. Enterprise Plus starts at $20k annually and adds dedicated support with SLAs. Salesforce licenses are a separate cost. The integration work is a one-time cost in a fixed-scope engagement, priced from a written scope, while licenses and any authentik subscription recur. Ask any quote to separate the one-time build, the authentik edition, and the Salesforce licenses so you can compare options side by side.
Does the Salesforce edition change the authentik work?
The edition and license count change the Salesforce side of the work more than the authentik side. The Salesforce Sales Cloud pricing page lists, as of October 2026, Free Suite at $0, Starter Suite at $25 per user per month, Pro Suite at $100 per user per month billed annually, and Core, Advanced and Max at $195, $395 and $550 per user per month, each billed annually. Salesforce directs buyers to a sales representative for detailed Max pricing. Confirm with Salesforce which editions include the SAML single sign-on and just-in-time settings you plan to use. API limits also scale with licenses. An Enterprise Edition org gets 100,000 API calls per 24 hours plus 1,000 per Salesforce license, so a 15-license org has 115,000, according to Salesforce's limits reference.
How long does a Salesforce SAML integration take?
The duration is set in the written scope, and no duration is stated here. The main drivers are the number of Salesforce orgs and sandboxes that need sign-in, how many profiles and permission sets must be mapped, whether the attributes Salesforce expects are already available from your directory, and whether SCIM provisioning is included. Testing with a pilot group of users and agreeing a change window for production also affect the timeline. Ask for a schedule that lists each milestone, the client decisions it depends on, and the testing you expect before cutover. Those dependencies usually determine the calendar more than the configuration itself.
What does our team need to provide for the integration?
The work depends on access and decisions from your side. Plan to provide:
- Administrator access to the authentik instance and to the Salesforce org or sandbox that will be configured.
- The Salesforce My Domain name, the list of profiles and permission sets, and the role each profile should receive.
- The source of the user attributes, such as username, email, first name, last name and a stable federation identifier, along with the naming rules for each.
- A pilot group of users and at least one tested break-glass administrator account that can sign in without SSO.
- A decision on whether SCIM provisioning is in scope, and who approves production changes.
Agree on these inputs in the scope document so that delays do not stem from missing access or unclear ownership.
Can our own team set up authentik and Salesforce without a partner?
Yes, a team can do this alone if it has the right skills and time. The work spans two systems: authentik needs a SAML provider, an application and property mappings that send the attributes Salesforce uses for just-in-time user creation, and Salesforce needs SAML settings, profile assignment and a tested login path. The authentik integration guide for Salesforce describes the property mappings. Your team should include someone who administers your identity provider, a Salesforce administrator, and an engineer who can read SAML assertions. The main risk for an in-house team is locking users out of production, so test with a pilot group and keep an administrator sign-in path that does not depend on SSO.
What does a fixed-scope Salesforce SSO engagement cover?
A fixed-scope engagement covers the deliverables, timelines and responsibilities agreed in writing before work starts. For this integration, the scope typically lists the authentik configuration for the SAML provider and application, the property mappings for just-in-time provisioning, the Salesforce SAML settings and profile assignment, pilot testing with named users, and handover documentation for your administrators. Whether SCIM provisioning, additional orgs or sandboxes, and post-launch support are included should be stated explicitly. Ongoing support, upgrades and continuous testing are available as separate retainers. DeployOpen prepares the configuration and evidence for your reviews but does not issue audit reports or certifications.
Why does just-in-time login fail for some Salesforce users?
Just-in-time login creates a Salesforce user at first sign-in only when the SAML assertion carries the attributes Salesforce needs and those values match your data model. The most common causes are a missing or malformed username, an email value that does not match the Salesforce user record, a federation identifier that differs between sources, or a profile name that does not exist in the org. Check the property mappings against the authentik Salesforce guide, then inspect a failed assertion from a test account and compare each attribute with the Salesforce expectation. Confirm the NameID format and the federation identifier rules with Salesforce before you enable production access for all users.
How DeployOpen scopes and delivers this integration
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, so authentik and the Salesforce SAML integration run in your environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm your Salesforce edition, org count, and whether SCIM provisioning is in or out of scope.
- Map which authentik instance, hostnames and certificates the SAML sign-in will use.
- Agree the attribute set for just-in-time provisioning and the profile and permission set assignments.
- Record the written scope, deliverables and timeline before any configuration begins.
How we build
- Deploy or validate authentik in your infrastructure, with the Salesforce SAML provider and application configured.
- Create the property mappings for just-in-time user creation and test them with sample test users.
- Build profile assignment rules and, where in scope, SCIM provisioning and deprovisioning of leavers.
- Test first login, failed login, and deprovisioning paths in a sandbox org before production cutover.
How we hand over
- Document the SAML settings, certificate rotation steps, attribute mappings and profile assignment logic.
- Record the cutover checklist, rollback steps and the named owners for each configuration element.
- Walk your administrators through first-login behavior, troubleshooting steps and change control.
- Deliver the configuration as versioned artifacts so your team can review and reproduce changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan authentik version upgrades and re-test the Salesforce sign-in path after each change.
- Review SAML certificate expiry, attribute changes and Salesforce release notes that affect sign-in.
- Confirm the support scope, response expectations and SLAs in writing with the quote.
