Docebo SSO with Okta: SAML 2.0 setup guide for SMEs
For a European SME that has standardised on Okta for identity and added Docebo as its learning platform, the single-sign-on wiring is small but load-bearing work. Done right, the employee logs into Okta once and lands in Docebo without re-authenticating, new starters provision automatically, and leavers lose access the moment HR disables their Okta account. Done wrong, you end up with a shadow user directory in Docebo that drifts from the source of truth in Okta and becomes the first thing a GDPR audit picks up.
This guide walks through the SAML 2.0 configuration between Docebo and Okta, the attribute mapping that matters in practice, and the decision between Docebo’s Smart and Standard configuration paths.
Why SSO is the first integration to land
Before any course content is loaded, the SSO decision dictates how every other integration downstream behaves. Three concrete wins from routing Docebo authentication through Okta:
- One identity lifecycle. Joiners, movers, and leavers happen in Okta (usually fed from the HRIS). Docebo inherits the state. No parallel user management.
- Fewer support tickets. Password-reset tickets for Docebo disappear because there is no Docebo password to reset.
- Audit trail. Okta’s System Log captures every sign-in event — useful evidence for GDPR Article 32 controls and for any future ENS or ISO 27001 audit. For Spanish SMEs operating under the Esquema Nacional de Seguridad, centralised identity logs are one of the cheaper control wins available.
The authoritative Docebo reference for the flow sits on their help portal at help.docebo.com; the public product page at docebo.com outlines which editions support SAML SSO (every tier does).
Prerequisites — what needs to be in place before you touch the config
The setup will stall if any of these are missing. We collect them in week 1 of an SME deployment:
- A Docebo Learn instance with administrator access.
- An Okta organisation with administrator access and the Docebo app added (or the Okta Template SAML app if you prefer manual wiring).
- A planned NameID policy — usually
user.email, but confirm whether your SME reuses emails on leaver/re-hire. - Optional but recommended: an SP-side signing certificate for assertion validation.
- A test Docebo subdomain or a test tenant for validating before switching the production IdP.
If the SME does not yet own the Docebo admin console — a common state mid-onboarding — we stage the SAML metadata in Okta as a “draft” app assigned only to the IT admin group until the Docebo side is ready.
Smart Configuration versus Standard Configuration
Docebo offers two setup paths for SAML. The choice is not a quality decision; it is a fit decision.
- Smart Configuration (guided). Docebo reads Okta’s IdP metadata URL and fills most of the SP-side settings automatically. Recommended for the first implementation, for single-IdP SMEs, and for any SME without a dedicated security engineer. This is the default we run.
- Standard Configuration (manual). You enter the IdP entity ID, SSO URL, and public certificate by hand, and you configure every SP-side option explicitly. Worth the extra time when the SME needs non-default assertion signing, a non-standard NameID format, or a second IdP for contractors.
For a ten-person SME with one Okta tenant, Smart Configuration takes 20 minutes and there is no benefit to doing it the long way.
Attribute mapping that survives contact with production
The attribute mapping is where most SSO integrations quietly break six months after go-live. A minimal mapping that holds up across an SME lifecycle:
| Okta profile attribute | SAML claim | Docebo user field | Notes |
|---|---|---|---|
user.email | Email | email | Required, must be unique. Use the work email — not the UPN if they differ. |
user.firstName | FirstName | firstname | Required. |
user.lastName | LastName | lastname | Required. |
user.department | Department | department or custom field | Drives Docebo branch assignment. |
user.managerEmail | ManagerEmail | custom field | Feeds manager-report features. |
user.title | JobTitle | custom field | Useful for learning-path auto-assignment. |
Two rules we apply on every deployment: never map a free-text Okta attribute to a Docebo field that a learning-path rule depends on without a lookup table (free-text drifts), and never use a mutable identifier like email as the NameID unless you have a process for re-mapping when emails change.
Just-in-Time provisioning and the Okta-Docebo lifecycle
With SAML + JIT provisioning enabled on the Docebo side, a new hire hits the Docebo login page, gets redirected to Okta, authenticates, and lands in Docebo as a freshly-created user with the attributes above already populated. We typically pair this with Okta group assignments that drive Docebo branch membership — a user in the Okta group docebo-branch-madrid-sales lands in the Madrid Sales branch on first login, with the enrollment rules for that branch applied automatically.
The leaver path is equally important: deactivating the Okta account should immediately block Docebo sign-in. That part works out of the box; the bit that does not is historical completions. Docebo retains the user record for audit purposes by default — verify this matches your retention policy before go-live, because a GDPR subject-deletion request cannot be satisfied if you are keeping completion records longer than the policy allows.
A quick smoke test before declaring go-live
On the day of cutover we run the same sequence every time:
- Sign in as a test user from an incognito window — expect redirect to Okta and a clean landing on the Docebo dashboard.
- Sign in with a user not assigned to the Docebo Okta app — expect a clear denied message, not a Docebo error page.
- Deactivate the test user in Okta — wait for the session to refresh and confirm the existing Docebo session is invalidated.
- Check the Okta System Log for the assertion event and the Docebo audit log for the corresponding user-created or user-signed-in event.
If any of those fail, do not flip the production IdP toggle. We have seen one case where a typo in the NameID format turned every login into a new-user creation — the fix was a two-character edit, but the cleanup of duplicate users took half a day.
Funding and Spanish market notes
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.
Ready to get started?
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.