Explanation:

To meet the requirements of a mobile app that avoids user consent prompts ("approve API access") and minimizes re-authentication, you must configure specific OAuth policies within the Salesforce Connected App.

Why "Admin approved users are pre-authorized" is correct

By default, when a user logs in via OAuth, Salesforce prompts the user to "Approve" the application's access to their data.

By changing the Permitted Users setting to "Admin approved users are pre-authorized" and then assigning the app to specific users via Profiles or Permission Sets, you bypass the consent screen. This ensures that the user is not forced to manually approve API access, fulfilling the requirement for a seamless user experience.

Why "Refresh Token Policy" is correct

The Refresh Token Policy determines how long a refresh token remains valid.

If you set the policy to "Expire refresh token if not used for..." and define the duration (e.g., 90 days/3 months), the application can use the refresh token to obtain a new access token without the user having to re-enter their credentials. This effectively keeps the user logged in for the desired period, provided the token is used periodically within that timeframe.

Why the other options are incorrect

Set the Session Timeout value to 3 months
Session Timeout is a general security setting for the org's web interface sessions. It is not an OAuth Connected App configuration setting, and usually, organization-wide session timeouts are not set to 3 months for security compliance reasons.

Set Permitted Users to "All users may self-authorize"
This option forces the standard OAuth flow where users must explicitly approve API access, which contradicts the requirement to not force the user to approve access.

References
Salesforce Help: Manage OAuth Access Policies for a Connected App
Salesforce Help: OAuth 2.0 User-Agent Authentication Flow

Explanation:

NTO employees need to:

Authenticate using Salesforce credentials
Access an external (non-Salesforce) application
Not access Salesforce objects

The Identity Only License is specifically designed for this use case. It provides:

Authentication (SSO) capabilities
Identity services (login, user management)
No access to standard/custom Salesforce objects

This makes it the most cost-effective and appropriate choice for employees who only need Salesforce as an Identity Provider (IdP).

Why the other options are incorrect

Identity Verification Credits Add-On License
Not a user license. It’s a consumption-based add-on for verification (e.g., SMS OTP).

External Identity License
Intended for external users (customers/partners), not internal employees.

Identity Connect License
Related to on-premise Active Directory integration, not for this authentication-only use case.

Key Concept
This question tests understanding of Salesforce Identity licensing:
Identity Only License = authentication without CRM access

Exam Tip
If you see:
“No access to Salesforce objects”
“Only need login / SSO”

👉 Always think Identity Only License.

Explanation:
To enable social sign-on with providers like Facebook and Google (supporting OpenID Connect) in Salesforce, an Authentication Provider must be configured for each provider. Additionally, a Registration Handler (an Apex class) is required to map the external user's identity to an existing or new Salesforce user account, controlling how users are linked or created.

Correct Option:

C. configure an authentication provider and a registration handler for each social sign-on provider.
An Authentication Provider defines the connection details (client ID, secret, endpoints) for each social provider. A Registration Handler is an Apex class that implements the Auth.RegistrationHandler interface. It controls linking logic—whether to create a new user, link to an existing contact, or update user attributes. Both are mandatory for a complete social sign-on implementation.

Incorrect Option:

A. configure a single sign-on setting and a JTT handler for each social sign-on provider.
There is no "JTT handler" in Salesforce Identity terminology. SSO settings are for SAML, not for OIDC social providers. Social sign-on requires Authentication Providers, not SAML SSO configurations.

B. configure an authentication provider and an Auto-Time Unit handler for each social sign-on provider.
"Auto-Time Unit handler" is not a real Salesforce component. The correct component is a Registration Handler. This option uses fabricated terminology and would not work.

D. configure a single sign-on setting and a registration handler for each social sign-on provider.
SAML SSO settings are not used for social providers like Google or Facebook. Social sign-on uses OAuth 2.0/OIDC with Authentication Providers. A Registration Handler alone without the Authentication Provider is useless because there is no connection to the external IdP.

Reference:

Salesforce Help Article: "Set Up Social Sign-On for External Users"

Trailhead: "Social Sign-On" – Unit on "Configure Authentication Providers and Registration Handlers"

Salesforce Developer Guide: "Auth.RegistrationHandler Interface"

Explanation:

This question tests your ability to select the correct protocol when the third-party system has specific technical limitations (only supporting OAuth).

✅ Option D: OpenID Connect (OIDC)
Since the third-party portal only supports OAuth, it cannot use SAML (which is XML-based). OpenID Connect is the identity layer built directly on top of the OAuth 2.0 protocol. By configuring Salesforce to use OpenID Connect, Salesforce acts as the Service Provider (or Relying Party) and the third-party portal acts as the Identity Provider. This allows employees to authenticate using their portal credentials, and Salesforce receives an ID Token to verify their identity.

❌ Option A: Add the third-party portal as a connected app
A Connected App is used when Salesforce acts as the Identity Provider to allow an external app into Salesforce, or to define how an external app connects to Salesforce APIs. In this scenario, the portal is the one holding the credentials (the IdP), so adding it as a Connected App doesn't solve the problem of getting the user into Salesforce using those external credentials.

❌ Option B: Configure Salesforce for Delegated Authentication
Delegated Authentication is a legacy method where Salesforce sends a web service call (SOAP) to an external system to validate a username and password. This does not provide a "seamless" SSO experience (the user still has to type their password into the Salesforce login page), and it does not utilize the OAuth capabilities of the portal.

❌ Option C: Create a custom external authentication provider
While you could write custom Apex code to create an Auth Provider, Salesforce has a native OpenID Connect option within the Auth Provider settings. An architect should always recommend the "out-of-the-box" configuration (Option D) before suggesting custom development to reduce maintenance and complexity.

🔧 Reference:
→ Salesforce Help: Configure an OpenID Connect Provider
This documentation confirms that you can use any provider that supports OpenID Connect (including those built on OAuth 2.0) to allow users to log in to Salesforce.

Explanation:

This question tests knowledge of OAuth 2.0 token lifecycle management in Salesforce, specifically how to properly invalidate an active OAuth token upon user logout from an external application. Ensuring token invalidation is critical for security — simply ending a session is insufficient without explicitly revoking the active token on the Salesforce authorization server.

✅ A. Use a HTTP POST to make a call to the revoke token endpoint.
Salesforce provides a dedicated token revocation endpoint (/services/oauth2/revoke) that accepts an HTTP POST request with the current OAuth token. This immediately invalidates the access or refresh token on the Salesforce side, ensuring the external application can no longer use it to access Salesforce data after logout, following OAuth 2.0 revocation standards (RFC 7009).

❌ B. Use a HTTP POST to request any refresh token for this current user.
Requesting a new refresh token does not invalidate the existing OAuth token. This action would generate additional tokens rather than terminating the current session, which is the opposite of the desired behavior and leaves the original token still active and exploitable.

❌ C. Enable Single Logout with a secure logout URL.
Single Logout (SLO) is a SAML-based mechanism used to terminate federated SSO sessions across identity providers and service providers. It is not applicable to OAuth 2.0 token invalidation. Enabling SLO does not revoke OAuth access tokens issued to external applications.

❌ D. Use a HTTP POST to the System for Cross-domain Identity Management (SCIM) endpoint, including the current OAuth token.
SCIM is a protocol used for user provisioning and deprovisioning, not for OAuth token management. Posting to a SCIM endpoint has no effect on revoking or invalidating an active OAuth access or refresh token in Salesforce.

🔧 Reference:
→ Revoke OAuth Tokens – Salesforce Help
Confirms that a HTTP POST to the /services/oauth2/revoke endpoint is the correct method to invalidate an active OAuth token upon logout in Salesforce.