References:

SAML-based Single Sign-On (SSO) relies on strict security and timing protocols. Even if Salesforce settings are correct, issues on the Identity Provider (IdP) side can cause authentication failures.

🔹 B. Clock on the IdP server is twenty minutes behind Salesforce — ✅
SAML assertions include a timestamp and are valid only for a short window (typically ±5 minutes).
If the IdP clock is out of sync with Salesforce, the assertion may be considered expired or not yet valid, causing login failures.
Time synchronization between IdP and SP is critical.
📘 Reference: Salesforce SAML Assertion Time Validity

🔹 C. Issuer Certificate from the IdP expired two weeks ago — ✅
SAML assertions are digitally signed using the IdP’s certificate.
If the certificate is expired, Salesforce will reject the assertion for security reasons.
Certificates must be renewed and updated in both IdP and Salesforce metadata.
📘 Reference: Salesforce SAML Certificate Expiry Issues

❌ A. IdP is used to SSO into five other applications
This is not inherently problematic. IdPs are designed to support multiple service providers.
Unless there's a misconfiguration or overload, this is not a likely cause of SSO errors.

❌ D. Default language mismatch between IdP and Salesforce
Language settings do not affect SAML authentication.
They may impact UI or error message localization, but not the SSO flow itself.

Explanation:

Why:
The OAuth 2.0 Web Server flow (aka Authorization Code grant) is for apps that run on a secure server and can safely store a client secret. The user signs in via the browser, the app’s server receives an authorization code, exchanges it for tokens, and then uses those tokens to call Salesforce APIs on the user’s behalf.

Why the others are wrong (brief):
B — Rendering pages isn’t what defines this flow; it’s about secure server-side token exchange.
C — Mobile apps typically use User-Agent or JWT/Device-appropriate flows, not Web Server.
D — All OAuth flows end up verifying access to protected resources; this isn’t specific to the Web Server flow.

Explanation:

Northern Trail Outfitters (NTO) wants employees to log in to Salesforce Service Cloud using credentials from a third-party employee portal, which supports OAuth for authentication. The goal is to enable single sign-on (SSO) for a seamless experience. Let’s evaluate each option to determine the best approach for an identity architect:

A. Configure SSO to use the third-party portal as an identity provider: Incorrect.
While using the third-party portal as an Identity Provider (IdP) is feasible if it supports SAML or OpenID Connect (OIDC), the question specifies that the portal only supports OAuth. OAuth is an authorization protocol, not an authentication protocol like SAML or OIDC, and Salesforce requires an IdP to support SAML or OIDC for standard SSO configurations. The portal’s OAuth limitation makes it unsuitable as a traditional IdP for Salesforce SSO.

B. Create a custom external authentication provider: Correct.
Salesforce supports custom authentication providers, which allow integration with external systems for SSO using protocols like OAuth or OpenID Connect. Since the third-party portal supports OAuth, NTO can create a custom authentication provider in Salesforce using Apex to handle the OAuth flow (e.g., Authorization Code or Implicit flow). This involves configuring the portal as an OAuth provider, directing users to authenticate via the portal’s OAuth endpoint, and exchanging tokens to authenticate users in Salesforce. This approach enables seamless SSO by leveraging the portal’s OAuth credentials, meeting NTO’s requirements.

C. Add the third-party portal as a connected app: Incorrect.
A Connected App in Salesforce is used when Salesforce acts as the IdP or resource server, allowing external applications to access Salesforce data via OAuth or SAML. In this scenario, the third-party portal is the authentication source, not Salesforce, so defining the portal as a Connected App in Salesforce is not applicable. Connected Apps are for outbound integrations, not for using an external system’s credentials to log in to Salesforce.

D. Configure Salesforce for Delegated Authentication: Incorrect.
Delegated Authentication allows Salesforce to delegate user authentication to an external service via a custom web service (e.g., SOAP-based). However, the third-party portal only supports OAuth, not a custom web service protocol required for Delegated Authentication. Additionally, Delegated Authentication replaces Salesforce’s password-based login entirely, which may not align with the SSO goal and requires significant custom development on the portal side.

Why B:
A custom external authentication provider allows Salesforce to integrate with the third-party portal’s OAuth-based authentication, enabling employees to use their portal credentials for SSO into Salesforce. This leverages Salesforce’s extensible identity framework, supports the portal’s OAuth limitation, and ensures a seamless login experience with minimal changes to the existing portal.

References:
Salesforce Help: Create a Custom External Authentication Provider
Salesforce Help: External Authentication Providers
Trailhead: Identity for Developers
Salesforce Developer Docs: Custom Authentication Provider Example

Explanation:

Requirement:
Universal Containers (UC) is setting up an authentication provider for a Salesforce Experience Cloud site for its container wholesale business. We need to identify two options that can be utilized when creating an authentication provider in Salesforce.
Context:
An Authentication Provider in Salesforce enables external authentication (e.g., via Google, Facebook, or another IdP) for Experience Cloud users, typically using OAuth, OpenID Connect, or SAML. When configuring an Authentication Provider, certain settings can be customized to manage user authentication and integration.

Option Analysis

A. A custom registration handler can be set.
A Registration Handler is an Apex class (implementing the Auth.RegistrationHandler interface) that processes user data from the external IdP during login. It can create or update Salesforce user records based on data (e.g., email, name) received from the authentication provider (e.g., via OAuth or OpenID Connect). This is a key feature for Experience Cloud sites to map external identities to Salesforce Community users, making it a valid option for configuration.
Why It Fits:
Allows UC to customize how user profiles are created or updated in the Experience Cloud site based on the IdP’s data.
Verdict: Correct.

B. A custom error URL can be set.
When configuring an Authentication Provider in Salesforce, you can specify a Custom Error URL to redirect users if an authentication error occurs (e.g., invalid credentials or IdP failure). This is useful for providing a branded or user-friendly error page in the Experience Cloud site, improving the user experience during login issues.
Why It Fits:
Enhances the authentication process by allowing UC to handle errors gracefully in the Experience Cloud context.
Verdict: Correct.

C. The default login user can be set.
There is no concept of a "default login user" in the configuration of an Authentication Provider in Salesforce. Authentication Providers handle external authentication and map to Salesforce users dynamically (e.g., via Registration Handlers or JIT provisioning for SAML). Setting a default user is not a supported feature for Authentication Providers.
Verdict: Incorrect.

D. The default authentication provider certificate can be set.
Authentication Providers using OAuth or OpenID Connect typically rely on client IDs, client secrets, or JSON Web Key Sets (JWKS) for authentication, not Salesforce certificates. Certificates are more relevant for SAML-based SSO (e.g., when Salesforce is the IdP or SP). While SAML configurations might involve certificates, the question focuses on an Authentication Provider (typically OAuth/OpenID Connect for Experience Cloud), and no "default authentication provider certificate" setting exists in this context.
Verdict: Incorrect.

Why A and B are Correct
A. Custom Registration Handler:
Allows UC to define custom logic for creating or updating Experience Cloud user records based on data from the external IdP, ensuring seamless integration and profile synchronization.
B. Custom Error URL:
Enables UC to redirect users to a custom page in the Experience Cloud site if authentication fails, improving user experience and branding.

References
Salesforce Help: Set Up an Authentication Provider
Salesforce Help: Registration Handler
Trailhead: External Identity Basics

Explanation:

✅ Correct Answer: A. OAuth 2.0 Asset Token Flow
This flow is specifically designed for IoT devices and hardware (like sensors, smart devices, gateways) that need to send data securely to Salesforce.
An asset token is issued for a connected device, which then allows the device to authenticate and push data into Salesforce without needing a human user session.
Perfect fit here since sensors (non-human clients) must send continuous data into Salesforce and be linked to installed assets for maintenance.

❌ Why not the others?

B. OAuth 2.0 Device Authentication Flow
Used for devices with limited input/display capability (like a TV, console, or set-top box) where a human must enter a code on another device to authenticate.
Not meant for autonomous sensors.

C. OAuth 2.0 JWT Bearer Token Flow
Used for server-to-server integrations where there is no user interaction but the integration still acts on behalf of a Salesforce user.
Good for backend services, but not for physical IoT devices/assets tied to Salesforce assets.

D. OAuth 2.0 SAML Bearer Assertion Flow
Used when an external Identity Provider (IdP) issues a SAML assertion to get an access token in Salesforce.
Not relevant for IoT sensors since they don’t use SAML.

📖 Reference:
Salesforce: Asset Token Flow for Securing IoT Device-to-Cloud Communication
Salesforce Identity Implementation Guide – OAuth Flows

👉 Final Answer: A. OAuth 2.0 Asset Token Flow