- The Salesforce Help documentation is the single source that has enough information to get you to pass the exam.
- Don’t dismiss the Exam Guide. You won’t find more accurate hints about the questions anywhere else, e.g. The Community (Customer/Partner) section is now (Jan 2023) 18%.
- Focus on the key concepts: OAuth, SAML, OpenID Connect, Connected App, Authentication vs Authorisation, OAuth 2.0 flows, Single Sign-On flows, etc.
- Use identity related settings in Salesforce org’s Setup to enhance the learning.
The Single Source
Many people claim this certification to be one of the most difficult Salesforce multi-choice exams but I don’t think it is as difficult as it sounds although I did not have that much hands-on experience in commercial projects. But it is a relatively self-contained topic with all details that can be found in a single place, i.e. the Salesforce Help documentation.
I spent most of my preparation time (maybe 80% of the time) reading through the help. I usually read it in a layer-by-layer style rather than page by page. The help documentation is organised in a nice tree-like structure. The root node has the first layer of child nodes which show high level sections of the topic, with each section (child node) having a short paragraph of 3-4 sentences to explain it. If I need to know more details of a particular section, I can drill down into that section and it presents the next layer of child nodes which represent the sub-sections.
Do not dismiss the Exam Guide as it is always kept up to date. Many blog posts’ information is a few years old so the weight of each topic could be very different now. e.g. The Community (Customer/Partner) section is now (Jan 2023) 18% which means there are around 11 questions on this and it certainly felt a lot more than I expected in the actual exam. I read the exam guide many times. If I wasn’t sure what certain concepts mean in the exam outline, I would google the terms and learn that specific concept. But most likely the topic can be found in the help documentation aforementioned.
First of all, OAuth is an authorization protocol while SAML is an authentication protocol. My advice is to google the difference between authorization and authentication and read the top 5 pages in the search result.
I often come to these pages for protocol references:
- Salesforce OAuth Flows
- Salesforce Single Sign On Flows
- Which OAuth flow is suitable for what scenario: see this Decision Guide.
- Which SSO flow is suitable for what scenario: see this Decision Guide.
The design of any OAuth 2.0 flow looks more complicated than I would initially expected. But most of these back and forth communications between different entities are working around various different security issues. Every parameter/attribute introduced, whether being in a redirect URL for an auth. code or an HTTP POST request for the access token, is there for a reason. Ask these questions:
- Why was Implicit Grant (User-Agent) less secure than and replaced by the PKCE flow?
- What’s the difference between Authorisation Code and Access Token?
For lots of the Single Sign-On related questions, the key thing is to figure out who is the service provider and who is the identity provider. If you can quickly get that clear, you are half way though an answer.
A big part of the SSO flow is user provisioning.
Pay attention to external identity in communities and its license details, Experience Cloud’s authentication options and branding options, and embedded login.
Identity Related Settings in Setup
There are various different settings all over the places in the org’s Setup, which can be confusing sometimes. My observation is that Salesforce introduced 3 different SSO mechanisms at different stages. I list them and their key settings in the following table (OpenID Connect seems to be trending these days):
|SSO Settings||Salesforce as SP||Salesforce as IdP|
|Delegated Authentication||Single Sign-On Settings;|
Profile / Permission Set -> Check “Is Single Sign-On”
|API -> Delegated Authentication WSDL|
|SAML||Single Sign-On Settings||Connected App|
|OpenID Connect||Auth. Providers||Connected App|
Connected App is a key concept to understand. A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. It is a representation of an app outside of Salesforce, so when a Salesforce org has a connected app, it is used as either an identity provider for SSO or authorisation server for OAuth. Learn all the settings in the “New Connected App” page. The two main categories of these settings are:
- Enable OAuth Settings
- Enable SAML
Auth. Providers is an SSO setting. An auth provider represents the external authentication providers using OpenID Connect (Facebook, Google, LinkedIn, etc.). Salesforce works as the service provider and external social sites are an identity provider.
Single Sign-On Settings is for Delegated Authentication and SAML. Salesforce works as the service provider. SAML Single Sign-On Settings is a list of settings for SAML configuration. Delegated Authentication is probably the first version of SSO Salesforce introduced and this can be reflected by its setting field “Disable login with Salesforce credentials” and users’ Profile or Permission Set field “Is Single Sign-On”.
Other exam relevant but less important settings:
- Identity Provider
- Identity Verification
- OAuth and OpenID Connect Settings: Two less secure OAuth flows (Username-Password and User-Agent)
- Certificate and Key Management
- My Domain
- User Settings
- Session Settings