Hi @rterakedis We configured SSO via the SAML app with salesforce as the Identity Provider, so not quite the same combination as you. To get everything working we needed a lot of help from an IT specialist at our Docebo reseller, but fortunately this was during our implementation and included in the price of the launch pack. To be honest, I don’t think we would have been able to handle it ourselves with standard support from the help desk.

Closing the loop on this:

Support agreed to help us troubleshoot, although before they got back to us we figured out the issue by looking at the Developer Tools in Chrome (Network Tab).  On one of the failing calls, an error message called out (see below) that a requested scope was not allowed.   During configuration, we had checked the box next to a scope in our Docebo OIDC configuration that wasn’t part of the permitted set of scopes configured in Salesforce.   After fixing this, OIDC was working correctly.

That said, we found an issue setting up OIDC using Salesforce as the Identity Provider.   When configuring the “connected app” in Salesforce, there is a checkbox in the “Configure ID Token” section where you can “include custom attributes.”   We’ve used custom attributes with other SaaS providers to send additional user information in the claim.   This claim comes across through OIDC as a “custom_attributes” claim, and the value of that claim is a JSON block of Key-value pairs (i.e. the custom data you’ve mapped inside Salesforce).   Using this we could map non-standard things at the SaaS Provider by specifying the claim/key  (i.e. “Company Name”  ==  custom_attribute>company).  Unfortunately, it appears Docebo adheres to the list of supported_claims made available at the Salesforce well-known URL (your-org.my.salesforce.com/.well-known/openid-configuration/ ) and won’t let you leverage these custom attributes.