Docebo + Okta SAML SSO setup for European SMEs
For a Spanish SME running Docebo as the LMS with 50-200 learners and an existing Okta tenant for workforce identity, SAML SSO between the two is the configuration that turns the LMS from “another password to remember” into “one click from the corporate dashboard.” The setup is well-documented but unforgiving: a single attribute mismatch means JIT provisioning silently creates ghost users, and a missing X.509 certificate means the SSO flow fails with an error that points at the wrong layer. This guide walks the integration owner through the production-ready path — the one that survives an INCIBE audit and the next Okta certificate rotation.
Why SAML SSO is the production default for an SME’s Docebo
The alternative to SAML SSO is local Docebo accounts, where every learner has a separate Docebo username and password. For an SME with 50 learners, that means 50 password resets, 50 stale accounts when employees leave, and 50 audit findings the next time the SME has to demonstrate access governance. SAML SSO replaces all of that with a federation: Okta is the source of truth for who is allowed in, Docebo trusts the Okta assertion, and offboarding in Okta automatically locks Docebo. For a Spanish SME under INCIBE expectations on identity lifecycle and ENS access-control evidence, SAML SSO is the configuration that turns “we manage access manually” into “we have one source of truth and a documented federation.” The investment is one-time. The savings are recurring — and large enough that the SAML setup pays for itself within the first quarter for any SME above 30 active learners.
The Okta side: app, attribute statements, IdP metadata
The Okta-side configuration is three steps. Create the application: log in to the Okta admin dashboard, navigate to Applications, click Add Applications, search for “Docebo”, select the official Docebo application, and click Add. Okta provides a pre-built Docebo application that wires most of the SAML metadata automatically. Configure attribute statements: in the new application, open General Settings, scroll to Attribute Statements, click Edit, and add the three attributes Docebo expects. The mapping table below is the production default — case-sensitive, no whitespace, exact match on both sides.
| Okta attribute | Docebo expectation | Notes |
|---|---|---|
email | User email | Must match Okta user’s primary email; case-sensitive |
name | Full display name | First + last; do not split into separate attributes |
branch_code | Branch hierarchy slot | Custom Okta attribute; only required if SME uses Docebo branches |
Capture the IdP metadata: the Okta application provides an IdP metadata URL, the Entity ID, and the X.509 signing certificate on the Sign On tab. The integration owner copies all three to a secure note — Docebo will need them in the next phase. Skipping the metadata capture means returning to Okta later, which is fine the first time and irritating the fifth.
The Docebo side: Smart configuration and login behavior
In Docebo, the integration owner navigates to Settings > SAML and selects Smart as the configuration mode. Smart mode is recommended for the vast majority of SME deployments because it minimises manual XML editing — the integration owner pastes the Okta IdP metadata URL, and Docebo fetches the Entity ID, the certificate, and the SSO endpoint automatically. Standard mode is the fallback for SMEs with custom attribute mappings or non-standard IdPs. After the metadata is loaded, the integration owner configures login behavior: choose whether learners authenticate by email or username (email is the SME-friendly default), set up multi-factor authentication if the SME’s Okta policy requires it, and configure session timeout (90 minutes is a common SME default — long enough that learners do not re-auth mid-course, short enough that an unattended laptop does not stay open all day). The Docebo platform documentation at help.docebo.com covers the Smart-mode flow in detail and is the authoritative reference for any field whose behavior is not obvious.
JIT provisioning and SLO — operational toggles
Two toggles separate a basic SAML setup from a production-grade one. Just-In-Time (JIT) provisioning creates or updates Docebo users automatically based on the SAML assertion — the first time a new Okta user clicks the Docebo tile, JIT creates the Docebo account with the attributes from Okta. JIT removes the manual user-creation step entirely, which is the right default for SMEs that want offboarding in Okta to be the only step required. The risk is misconfigured attribute statements: if email is mapped wrong, JIT happily creates duplicate ghost users with empty fields. Test JIT in sandbox before enabling it in production. Single Logout (SLO) terminates the Docebo session when the learner logs out of Okta. SLO is the right default for shared-device environments — warehouses, classrooms, retail floors — where session bleed-through is a real risk. For SMEs whose learners use personal devices, SLO is optional and sometimes irritating; a learner who logs out of Outlook should not necessarily lose their Docebo session mid-course.
Testing the SSO flow before go-live
The pre-production test pass is four checks, run in sandbox, with one Okta test user assigned to the Docebo application. Authentication: the test user clicks the Docebo tile in Okta, lands in Docebo, and is logged in without a separate password prompt. Attribute mapping: the test user’s Docebo profile shows the correct email, name, and branch — not empty fields, not the literal string “email”. JIT provisioning: a second Okta user, never seen by Docebo before, clicks the tile and is created automatically. Logout: the test user logs out of Okta and is also logged out of Docebo (if SLO is enabled). Every step is documented with a screenshot in the SME’s runbook. For a Spanish SME accessing Kit Digital IA/BI vouchers — Segment III (10-50 employees) up to €12,000, Segment II (3-9 employees) up to €6,000 — that runbook is part of the deliverable the Agente Digitalizador hands over. Note that Docebo is rolling out a new SAML implementation via Launch Pad opt-in from July 22, 2026, with a final cutover on October 28, 2026 — the integration owner should plan the new-SAML migration into the SME’s calendar at the time of initial setup, not as an afterthought next year.
Ready to get started?
Working on this yourself? J4SGON S.L. delivers Docebo Connect, HRIS, SSO and migration work for European organisations — see what a scoped engagement covers or describe your project and we will reply with a written scope.
Tell us what you are integrating or migrating
Send the platform, the systems involved and where you are stuck. You get a written scope back — phases, deliverables and what is out of scope — before anything is billed.