Explanation:

This scenario requires a centralized authentication mechanism where Salesforce acts as the source of truth for user identities. A connected app is the cornerstone of this solution.
Connected App and OAuth: A Connected App is the key component for integrating external applications with Salesforce. By using OAuth, the mobile app can securely request access to Salesforce data on behalf of the user without needing to store their credentials. This establishes the initial trust relationship and provides the necessary tokens for API access.
Salesforce as Identity Provider (IdP): Once the user authenticates with Salesforce, the platform can then act as a SAML Identity Provider for other non-Salesforce applications. The mobile app, after receiving a successful login token from Salesforce via OAuth, can then use that established session to seamlessly access other applications. The app essentially gets a "ticket" from Salesforce which it can present to the other services. This is a classic Single Sign-On (SSO) pattern.
Mobile App Settings: The Connected App's settings can be configured specifically for mobile apps to enforce policies such as inactivity timeouts, session locking, and even remote wipe capabilities, which are crucial for corporate-distributed mobile apps. This provides the necessary security controls for a privately distributed application.

Why the other options are incorrect:
A. Use connected app with OAuth and Security Assertion Markup Language (SAML) to access other non-Salesforce internal apps. This is partially correct, but it's not the most precise or complete answer. While a connected app and OAuth are used, the flow for accessing the other non-Salesforce apps would be a separate SAML flow where Salesforce acts as the IdP. The option suggests a mixed use of both for the non-Salesforce apps, which is not the standard or most efficient architecture.
C. Use Salesforce as an identity provider (IdP) to access the mobile app and use the external IdP for other non-Salesforce internal apps. This option is incorrect because the user is authenticating with Salesforce first, meaning Salesforce is the initial IdP for the mobile app itself. The question states that the other non-Salesforce apps are accessed after the user authenticates with Salesforce, reinforcing the need for Salesforce to be the IdP for all of the connected services.
D. Create a new hybrid mobile app and use the connected app with OAuth to authenticate users for Salesforce and non-Salesforce internal apps. The prompt specifies a "native iOS mobile app," so a hybrid app is not the correct solution. More importantly, while a connected app and OAuth are used for Salesforce authentication, they don't directly handle authentication for other non-Salesforce apps; that's the role of Salesforce as the IdP via SAML.

Explanation:

In a SAML-based Single Sign-On (SSO) setup, the Identity Provider (IdP) is responsible for authenticating the user and then creating a SAML assertion (token) that contains the user's identity and attributes. This token is then sent to the Service Provider (SP), which consumes it to grant access.

Here’s how it works:
The user attempts to access a service (SP).
The SP redirects the user to the IdP for authentication.
The IdP authenticates the user and creates a SAML token (assertion).
The token is sent back to the SP.
The SP consumes the token and grants access.

❌ Why the other options are incorrect:
A. Validate token – This is the role of the Service Provider, which validates the token received from the IdP.
C. Consume token – Also the role of the Service Provider, not the IdP.
D. Revoke token – SAML tokens are not revocable; they are short-lived and used once per session.

📚 Reference:
Salesforce Help: SAML SSO Overview
Auth0 Docs: SAML Explained

Explanation:

B. Create authentication providers for both Facebook and LinkedIn:
To enable social sign-on, Salesforce must be configured to trust an external service. This is done by creating an authentication provider record in Salesforce for each external identity provider (Facebook and LinkedIn in this case). This record stores information such as the consumer key and consumer secret, allowing Salesforce to delegate authentication to the social media service.
C. Check "Facebook" and "LinkedIn" under Login Page Setup:
After creating the authentication providers, you must explicitly enable them for your Experience Cloud site. This is done in the site's "Login & Registration" administration settings by selecting the checkboxes for the newly created authentication providers.
E. Update the default registration handlers to create and update users:
When a customer logs in for the first time, Salesforce needs to know how to create their user record. An Apex registration handler defines this logic, mapping the information received from the social media provider (like name and email) to a new Salesforce user. The handler also handles subsequent logins, updating the user record as needed. While Salesforce can automatically generate a basic handler, you often need to update it for your specific requirements.

Explanation of the Incorrect Answers
A. Register both Facebook and LinkedIn as connected apps:
A connected app is used when Salesforce is the identity provider (IdP) for an external application. In this scenario, Facebook and LinkedIn are the IdPs, and Salesforce (specifically the Experience Cloud portal) is the service provider (SP).
D. Enable "Federated Single Sign-On Using SAML":
SAML is a standard for exchanging authentication data, but it is not the protocol used for integrating with social media providers like Facebook and LinkedIn. These integrations are typically based on the OpenID Connect and OAuth 2.0 protocols, which are configured via Authentication Providers. Federated SSO using SAML is a separate feature.

Explanation:

Why B fits the requirements
UC must authenticate to Salesforce with mainframe credentials and can’t use SAML. The Salesforce feature for this is Delegated Authentication (DA), which hands username/password verification to an external web service (your mainframe).
On-the-fly user creation via SAML JIT isn’t possible here because SAML isn’t available. The practical pattern is to provision users via API (SOAP/REST or SCIM) from the mainframe when they’re created/first enabled there, and then rely on DA at login time to validate their password against the mainframe.

Why the others are not
A. Login Flow callout — Login Flows run after Salesforce has identified a valid user and authenticated them; they can’t authenticate against the mainframe for a user who doesn’t exist yet, so they can’t create the user “on first login.”
C. JIT on the mainframe — Salesforce JIT user provisioning is a Salesforce-side feature that’s triggered by SAML/OIDC assertions into Salesforce. With no SAML/OIDC, you can’t use JIT.
D. OAuth User-Agent Flow + Registration Handler — Registration Handlers are used with Auth Providers (SAML/OpenID Connect) for inbound login to Salesforce. The OAuth User-Agent flow described here is for Salesforce acting as an authorization server for connected apps, not for logging into Salesforce from an external IdP.

Implementation tip (typical pattern)
Mainframe HR/identity system creates or enables a worker → provision a Salesforce User via API (SOAP/REST/SCIM) with the right Profile/Permission Sets.
Enable Delegated Authentication and point it to your mainframe validation service so Salesforce defers password checks to the mainframe at login time.

Explanation:

Universal Containers (UC) wants to use Salesforce Identity to control access to a custom time tracking app for its employees, implying that Salesforce will act as the Identity Provider (IdP) to authenticate users and enable Single Sign-On (SSO) to the external app. The employees need to use their Salesforce credentials to access the custom app without requiring access to Salesforce objects or data. The Identity Only License is the most appropriate choice to meet this requirement at a minimum. Below is a detailed analysis of why C is correct and why the other options are not suitable.

C. Identity Only License (Correct)
Why Appropriate: The Identity Only License (previously known as Salesforce Identity License) is designed for users who need to authenticate via Salesforce as an IdP to access external applications (like the custom time tracking app) without accessing Salesforce CRM objects or data. It provides:
SSO capabilities using protocols like SAML or OpenID Connect, allowing employees to log in to the custom app with their Salesforce credentials.
Identity management features such as user provisioning, MFA, and session management without granting access to Salesforce objects (e.g., Accounts, Opportunities).
Cost-effective licensing for employees who only need identity services, not full Salesforce functionality.
Fit for Scenario: Since UC’s employees are internal users who only need to access the custom time tracking app via Salesforce Identity, the Identity Only License meets the requirement with minimal overhead. The architect would configure Salesforce as the IdP, set up a Connected App for the time tracking app, and assign Identity Only Licenses to the employee User records. Implementation:
Enable Salesforce as an IdP (Setup > Identity > Identity Provider).
Create a Connected App in Salesforce for the time tracking app, specifying SAML or OpenID Connect settings.
Assign Identity Only Licenses to users and map their Federation ID or username to the external app’s authentication requirements.
Reference: Salesforce Help: Salesforce Identity License.

A. Identity Verification (Incorrect)
Why Not Suitable: Identity Verification is not a standalone license but an add-on feature (e.g., Identity Verification Credits) used to enable advanced verification methods like SMS-based MFA or push notifications, typically for External Identity users. It does not provide user authentication or SSO capabilities on its own and is not sufficient to control access to an external app. It might complement the Identity Only License for enhanced security (e.g., MFA), but it doesn’t meet the core requirement.
Clarification: This option is irrelevant for enabling SSO to a custom app.
Reference: Salesforce Help: Identity Verification.

B. Identity Connect (Incorrect)
Why Not Suitable: Identity Connect is a specific tool for synchronizing user data between Salesforce and Microsoft Active Directory (AD) to enable SSO and user management. It is not a user license and is not required for employees to access a custom app using Salesforce Identity.
Identity Connect would be relevant if UC were integrating mainframe or AD credentials with Salesforce, but the scenario specifies leveraging Salesforce Identity directly.
Clarification: Identity Connect is a middleware solution, not a license for user access or SSO.
Reference: Salesforce Help: Identity Connect Overview.

D. External Identity (Incorrect)
Why Not Suitable: The External Identity License is designed for high-volume, external users (e.g., customers or partners) accessing Experience Cloud sites or lightweight portals, often with contactless user capabilities. It is not intended for internal employees, as it restricts functionality to basic community features and is not optimized for employee SSO to custom apps. Using External Identity for employees would be inappropriate and likely more restrictive than needed.
Clarification: This license is suited for customer-facing portals, not internal employee apps.
Reference: Salesforce Help: External Identity License.

Additional Notes
Implementation Steps:
Assign Identity Only Licenses to employee User records in Salesforce.
Configure Salesforce as the IdP (Setup > Identity > Identity Provider) and enable the appropriate protocol (SAML or OpenID Connect).
Create a Connected App in Salesforce for the time tracking app, specifying the SSO protocol and settings (e.g., SAML Assertion Consumer Service URL or OAuth endpoints).
Ensure the time tracking app is configured to trust Salesforce as the IdP and map user attributes (e.g., Federation ID or email).
Test the SSO flow in a sandbox to verify authentication and session handling.

Security Considerations:
Enable MFA for employees using the Identity Only License to enhance security, as it’s supported and aligns with best practices.
Validate that the time tracking app supports SAML or OpenID Connect for compatibility with Salesforce’s IdP.
Use secure attribute mapping (e.g., Federation ID) to prevent account linking issues.

Architectural Impact:
The Identity Only License minimizes licensing costs by avoiding full Salesforce licenses (e.g., Sales Cloud) for employees who don’t need CRM access.
Ensure the custom app’s authentication endpoints are scalable and secure (e.g., using TLS).
Trailhead Reference: Trailhead: Salesforce as an Identity Provider.

Explanation:

The External Identity license is specifically designed for this type of use case. It allows for high-volume external users (like customers) to perform identity-centric functions without needing a full or even a partial CRM license.

Here's a breakdown of why it's the right choice:
External Users: The scenario involves customers, not internal employees, which immediately points to an external-facing license.
External Authentication: The prompt states customers are logging in using external providers like Facebook and Google. The External Identity license is built to handle social sign-on and other authentication protocols like SAML and OAuth 2.0.
App Launcher Access: A key requirement is that customers need to access an "off platform application" via the Salesforce App Launcher. The External Identity license provides access to the App Launcher, enabling users to launch connected apps and other integrated services.
No CRM Data Access: The prompt mentions that customers use Salesforce to track order status and access an external label generator. This suggests a limited scope of access, primarily for identity management and launching external apps, rather than needing full access to standard Salesforce objects like accounts, contacts, or opportunities. The External Identity license is a cost-effective solution because it provides these identity services without the additional overhead of a full Experience Cloud license.

Why the other options are incorrect:
A. Customer Community license: This license is intended for customers who need to access and collaborate on Salesforce objects like cases, knowledge articles, and accounts. While it supports social sign-on, it provides more data access than is required by the problem statement, making it a more expensive solution than necessary.
B. Identity license: The Identity Only license is for internal employees who don't need access to standard Salesforce CRM functionality but require a Salesforce identity for SSO to other internal apps. It is not for external customers.
C. Customer Community Plus license: This license is an upgrade from the standard Customer Community license, providing even more advanced features like roles, delegated administration, and reporting. It is significantly more than what is needed for this scenario.

Explanation:

In Salesforce OAuth architecture, scopes are used to define and restrict the level of access a connected app has to Salesforce resources. When Universal Containers builds a custom mobile app and wants to limit what data or functionality mobile users can access, scopes are the key feature to implement.

✅ What scopes do:
Control which APIs and data sets the app can access
Limit access to specific objects, permissions, or identity features
Prevent overexposure of sensitive data by enforcing least privilege
For example:
api → Grants access to the REST API
refresh_token → Allows the app to obtain new access tokens
openid → Enables OpenID Connect identity features
custom_permissions → Restricts access based on custom permission sets

📚 Reference:
Salesforce Help – OAuth Scopes

❌ Why the other options are incorrect:
A. Access Tokens
These are the result of an OAuth flow, not a mechanism for restricting access. They carry the scopes but don’t define them.
B. Mobile Pins
Related to mobile security policies, not OAuth. Used for enforcing device-level security, not API access control.
C. Refresh Tokens
Allow apps to renew access tokens without re-authentication. They extend session duration but don’t restrict access types.

Explanation:

JWT Bearer Token Flow: This OAuth 2.0 flow is designed specifically for server-to-server integrations where end-user interaction isn't required after initial setup.
Seamless Integration: The flow is seamless for the end user because the desktop application (the client) authenticates itself using a JSON Web Token (JWT) that has been signed with a digital certificate. This avoids repeated login prompts for the user and allows the integration to happen automatically in the background.
Security: A digital certificate, uploaded to the connected app in Salesforce, is used to establish a secure, trusted relationship. Salesforce validates the digital signature on the JWT before granting an access token, ensuring that the request is legitimate.

Explanation of the Incorrect Answers
B. Web Server Authentication Flow: This flow requires user interaction via a web browser to grant an authorization code. This is not "seamless" for a desktop application that primarily works offline, as it would force the user to log in through a browser repeatedly.
C. User Agent Flow: This flow is not suitable for desktop applications because it is less secure. It's designed for clients (like single-page applications) that cannot protect their client secret and receive access tokens via a URL redirect in the user's browser. This is not appropriate for a desktop application that needs to securely create leads in the background.
D. Username and Password Flow: This flow is a legacy option that Salesforce strongly advises against for security reasons, especially in production environments. It requires the application to store and transmit a user's plain-text credentials, making them vulnerable to interception.

Explanation

Why these:
A. Key logging attacks — Even if a keystroke logger steals the password, the attacker still lacks the second factor.
C. Phishing attacks — 2FA adds a barrier when credentials are phished; the attacker also needs the one-time code or possession factor. (Not perfect, but it meaningfully reduces risk; phishing-resistant methods like FIDO/WebAuthn are strongest.)
D. Dictionary attacks — Guessing passwords alone isn’t enough; the attacker must also pass the second factor, which typically stops automated password-guess attempts from succeeding.

Why not these:
B. Network perimeter attacks — Firewalls, segmentation, and patching address these; 2FA doesn’t meaningfully protect network infrastructure itself.
E. Man-in-the-middle attacks — Some OTP-based 2FA can be intercepted or relayed by an active MITM; only phishing-resistant, cryptographic methods (e.g., FIDO2/WebAuthn with origin binding) offer strong MITM protection.

Explanation:

Universal Containers (UC) wants to enable Single Sign-On (SSO) between their existing Active Directory (AD) infrastructure and Salesforce, with user management centralized in AD. They aim to avoid manual user setup in Salesforce, including the assignment of profiles, roles, and groups. This requires a solution that provisions users from AD to Salesforce automatically, including their attributes, and supports SSO. The two optimal solutions are Identity Connect and an AppExchange product designed for AD-Salesforce synchronization. Below, we analyze why B and D are correct and why A and C are not optimal.

B. Use an AppExchange product to sync users from Active Directory to Salesforce. (Correct)
Why Optimal: AppExchange offers third-party tools (e.g., Okta, OneLogin, or Ping Identity’s Salesforce connectors) that provide robust, out-of-the-box solutions for syncing users from AD to Salesforce and enabling SSO. These tools:
Automate user provisioning and deprovisioning by syncing AD user attributes (e.g., username, email, group memberships) to Salesforce User records, including profiles, roles, and permission sets.
Support Just-In-Time (JIT) provisioning, where users are created or updated in Salesforce during their first SSO login, based on AD attributes (e.g., mapping AD groups to Salesforce profiles or roles).
Enable SSO via SAML or OpenID Connect, integrating seamlessly with AD through protocols like LDAP or Kerberos.
Offer prebuilt connectors, reducing setup complexity compared to custom development, and provide additional features like MFA, user lifecycle management, and reporting.
Fit for Scenario: An AppExchange product is ideal for UC because it minimizes custom coding, supports automatic user provisioning (avoiding manual setup), and maps AD groups to Salesforce roles/profiles. It’s a scalable, enterprise-grade solution that aligns with IT’s preference to manage users in AD.
Implementation: Install an AppExchange product (e.g., Okta for Salesforce), configure the AD connector to sync user data, map attributes (e.g., AD group to Salesforce profile), and set up SAML-based SSO. Test in a sandbox to ensure proper user creation and role assignment.
Reference: Salesforce AppExchange: Identity Management Solutions; Salesforce Help: External Identity Solutions.

D. Use Identity Connect to sync users from Active Directory to Salesforce. (Correct)
Why Optimal: Salesforce Identity Connect is a purpose-built tool for integrating Salesforce with Microsoft Active Directory to enable SSO and user provisioning. It:
Synchronizes user data from AD to Salesforce, creating or updating User records based on AD attributes (e.g., email, name, group memberships).
Supports automatic mapping of AD groups to Salesforce profiles, roles, or permission sets, meeting UC’s requirement to avoid manual setup of these attributes.
Enables SSO using SAML, allowing users to authenticate via AD credentials and access Salesforce seamlessly.
Provides bidirectional sync (e.g., updating AD when Salesforce attributes change) and supports real-time or scheduled provisioning.
Fit for Scenario: Identity Connect is tailored for AD-Salesforce integration, making it an optimal choice for UC’s IT team to manage users centrally in AD while automating Salesforce user provisioning and SSO. It’s a Salesforce-native solution, ensuring tight integration and support.
Implementation: Install Identity Connect on a server with AD access, configure LDAP mappings to Salesforce User fields, set up group-to-profile/role mappings, and enable SAML SSO. Test user creation and updates in a sandbox.
Reference: Salesforce Help: Identity Connect Overview; Identity Connect Setup.

A. Use the Salesforce REST API to sync users from Active Directory to Salesforce. (Incorrect)
Why Not Optimal: While the Salesforce REST API can be used to create and update User records programmatically (e.g., syncing AD users to Salesforce), it requires custom development to:
Integrate with AD (e.g., via LDAP queries or an AD connector).
Map AD attributes to Salesforce fields (e.g., profiles, roles).
Handle ongoing synchronization, error handling, and security (e.g., OAuth or API authentication).
This approach is time-consuming, error-prone, and requires ongoing maintenance compared to prebuilt solutions like Identity Connect or AppExchange products. It doesn’t align with UC’s goal of avoiding manual setup, as custom code still requires significant configuration and testing.
Clarification: The REST API is better suited for one-off integrations or scenarios where no commercial tools are available, not for enterprise-grade AD-Salesforce sync with SSO.
Reference: Salesforce Developer: REST API User Management.

C. Use Active Directory Federation Services to sync users from Active Directory to Salesforce. (Incorrect)
Why Not Optimal: Active Directory Federation Services (ADFS) is primarily a SAML-based identity provider for SSO, allowing users to authenticate to Salesforce using AD credentials.
However, ADFS does not natively handle user provisioning (e.g., creating or updating Salesforce User records with profiles and roles). While ADFS supports JIT provisioning with SAML assertions to create users on login, it requires additional configuration (e.g., custom attribute mappings) and may not fully automate role/group assignments as seamlessly as Identity Connect or AppExchange products. ADFS focuses on authentication, not full user lifecycle management.
Clarification: ADFS could be part of the SSO solution but doesn’t fully meet UC’s provisioning requirements without additional tools or custom logic.
Reference: Salesforce Help: ADFS for SSO.

Additional Notes

Implementation Steps:
For Identity Connect (D):
Install Identity Connect on a server with AD access.
Configure LDAP queries to pull user data and group memberships.
Map AD attributes to Salesforce fields (e.g., sAMAccountName to Username, AD group to ProfileId or RoleId).
Enable SAML SSO and test user sync and login in a sandbox.

For AppExchange Product (B):
Choose a product like Okta or Ping Identity from AppExchange.
Install and configure the AD connector to sync users and groups.
Set up SAML or OpenID Connect for SSO and JIT provisioning.
Test attribute mappings (e.g., AD group to Salesforce role) and user creation.
SSO Setup: For both solutions, configure Salesforce as the Service Provider (SP) with My Domain enabled and set up SAML SSO settings to trust the AD-based IdP (e.g., ADFS or the AppExchange tool’s IdP).

Architectural Considerations:
Both solutions support JIT provisioning, creating users on first login if real-time sync isn’t needed.
Ensure AD group structures align with Salesforce profiles/roles for accurate mapping.
Monitor sync performance and API limits (for AppExchange tools using Salesforce APIs).

Security Considerations:
Enable MFA for SSO users to enhance security (supported by both solutions).
Use secure LDAP (LDAPS) for AD communication and HTTPS for SAML.
Validate attribute mappings to prevent duplicate users or incorrect role assignments.
Trailhead Reference: Trailhead: Identity Management Basics; External Identity for Provisioning.

Explanation:

To allow Salesforce profiles to be managed from a central system of record, the architect should recommend to implement JIT provisioning on the SAML IDP that will pass the profile ID in each assertion. JIT provisioning is a process that creates or updates user accounts on Salesforce based on information sent by an external identity provider (IDP) during SAML authentication. By passing the profile ID in each assertion, the IDP can control which profile is assigned to each user.

Option B is not a good choice because creating an Apex scheduled job in one org that will synchronize the other orgs profile may not be scalable, reliable, or secure.

Option C is not a good choice because implementing Delegated Authentication that will update the user profiles as necessary may not be feasible, as Delegated Authentication only verifies the user’s credentials against an external service, but does not pass any other information to Salesforce.

Option D is not a good choice because implementing an OAuth JWT flow to pass the profile credentials between systems may not be suitable, as OAuth JWTflow is used for server-to-server integration, not for user authentication.

References: Authorize Apps with OAuth, [Identity Management Concepts], [User Authentication]

Explanation:

When using a social authentication provider (like Facebook) with Salesforce, the process of creating and updating the corresponding Salesforce user is handled by an Apex class called a Registration Handler. This class implements the Auth.RegistrationHandler interface, which contains two key methods:

createUser(): Called when a user logs in for the first time to create their Salesforce user record.
updateUser(): Called on every subsequent login after the first.

The updateUser() method is the mechanism designed specifically for this requirement. It receives two parameters:

userId: The ID of the existing Salesforce user.
provderData: An object containing the latest user profile information (e.g., first name, last name, email, location) fetched from the identity provider (Facebook) during the current login.

Therefore, by implementing logic within the updateUser() method of the custom Registration Handler, Universal Containers can compare the incoming data from Facebook with the existing data on the Salesforce User record and update the record accordingly. This ensures that any changes made on Facebook are reflected in Salesforce the next time the user logs in.

Why the other options are incorrect:
A. Use SAML Just-In-Time Provisioning between Facebook and Salesforce. This is incorrect because social sign-on with providers like Facebook uses the OpenID Connect (OIDC) protocol, not SAML. While the concept of JIT provisioning applies, it is implemented through the Registration Handler in the OIDC flow, not through a SAML configuration.
B. Use information in the Signed Request that is received from Facebook. A "Signed Request" is a specific concept related to Facebook Canvas apps or pages embedded within Facebook. It is not the standard mechanism for passing user profile data during a standalone OIDC-based login flow to an external site like a Salesforce Community. The standard mechanism is the providerData object passed to the Registration Handler.
C. Develop a scheduled job that calls out to Facebook on a nightly basis. This is a poor solution for several reasons. It is inefficient (polling for changes for all users daily, even if they haven't logged in), complex (requiring to store Facebook access tokens securely), and not real-time. The updateUser() method is a event-driven, real-time solution that updates data only when a user actually authenticates, which is the optimal and intended approach.

Reference
Salesforce Help: Create a Registration Handler Class - This documentation explicitly describes the purpose of the updateUser method: "This method is called each time a user logs in. You can add logic to this method to update the user’s record in Salesforce when attributes, such as email or last name, change in the external system."

In summary,
the built-in, event-driven way to keep user data synchronized upon login is by implementing the logic within the updateUser() method of the custom Registration Handler class.