Explanation:

OAuth 2.0 Token Revocation:
The OAuth 2.0 specification (RFC 7009) includes a standard method for clients to request that an authorization server invalidate a previously issued token. The external application must make a secure POST request to Salesforce's token revocation endpoint.
Request Method:
The client application sends the token it wants to invalidate (either an access token or a refresh token) to the revocation endpoint. This process is part of a secure logout procedure to ensure that the token cannot be reused.
Salesforce Implementation:
Salesforce exposes a revocation endpoint (/services/oauth2/revoke) that accepts a POST request with the token to be invalidated. If a refresh token is sent, Salesforce revokes it and any associated access tokens. For a successful revocation, Salesforce returns an HTTP 200 status code.
Logout Procedure:
When a user logs out of the external application, the application's logout logic should include a call to the Salesforce revocation endpoint to ensure the OAuth tokens are also invalidated on the Salesforce side.

Why other options are incorrect

A. Use a HTTP POST to request the refresh token for the current user:
This action requests a new access token using a refresh token, which is the opposite of invalidating an existing token.
B. Use a HTTP POST to the System for Cross-domain Identity Management (SCIM) endpoint, including the current OAuth token:
The SCIM protocol is used for automated user provisioning and de-provisioning, not for revoking an active OAuth token. While it could be used to deactivate a user, it does not specifically revoke a token in the OAuth context.
D. Use a HTTP POST to make a call to the revoke token endpoint:
This option is exactly the same as option C and is the correct action. It is likely a duplicate provided in the original question.

Explanation:

Why:
Sensors are installed “assets” that need to send data to Salesforce and support downstream maintenance (work orders, cases) tied to the specific device. The Asset Token Flow is designed exactly for connected devices: it issues an access token on behalf of a Salesforce Asset, so each device can authenticate without user interaction and its calls are automatically associated to that asset for telemetry and service use cases.

Why not the others

B. Device Authentication Flow — requires a human to complete a verification step on a secondary device. Not suitable for unattended sensors.
C. JWT Bearer Flow — great for server-to-server integrations, but it authenticates a backend integration user, not individual devices/assets (you lose per-device context/controls).
D. SAML Bearer Assertion Flow — used when exchanging a SAML assertion for an OAuth token; not typical for IoT devices and still not asset-scoped.

Explanation:

The feature that directly allows you to embed a Salesforce login experience into a third-party website or application is called Embedded Login.

However, this feature has a significant technical dependency that must be evaluated before recommendation:

D. Embedded Login. Consider whether or not it relies on third party cookies... (Correct):
Embedded Login works by hosting the login form within an iframe on the external service provider's domain. For the authentication session to work correctly, Salesforce needs to set a session cookie. Because the iframe's content is served from the Salesforce domain (e.g., mycompany.my.salesforce.com) while the user is on the external application's domain, this session cookie is considered a third-party cookie.
The Critical Consideration: Modern browsers, such as Safari and Firefox, block third-party cookies by default for privacy and security reasons. Chrome is also phasing out support for third-party cookies. This can cause Embedded Login to fail in these browsers, breaking the login flow for a large portion of users. This is the most important technical constraint an architect must consider before proposing this solution.

Why the other options are incorrect:
A. OpenID Connect Web Server Flow. Determine if the service provider is secure enough...:
The OpenID Connect Web Server Flow is a standard OAuth flow for server-side web applications. It involves redirecting the user to a Salesforce-hosted login page. It does not create an embedded login widget within the service provider's page. The user is always taken away to a Salesforce URL, which is less "seamless" than an embedded experience.
B. Embedded Login. Identify what level of UI customization will be required...:
While UI customization (via Login Flows and Lightning Components) is possible and a consideration, it is a secondary concern. The primary, make-or-break issue that determines if the solution is viable at all is the third-party cookie dependency. If the browser blocks the cookie, the login will fail regardless of how well the UI is customized.
C. Salesforce REST apis. Ensure that Secure Sockets Layer (SSL) connection...:
Using REST APIs to build a custom login is not the standard, supported, or secure way to create a login widget. It would involve handling credentials directly, which is a major security anti-pattern. SSL is a basic requirement for any web traffic, not a specific consideration for an embedded login widget.

Reference:
Salesforce Help: "About Embedded Login":
This documentation explicitly calls out the dependency on third-party cookies as the key consideration.

Key Quote:
"Before implementing Embedded Login, consider this key factor: Embedded login relies on third-party cookies for authentication. Some browsers, like Safari and Firefox, block third-party cookies by default... If a user’s browser blocks third-party cookies, they can’t log in with embedded login."

In summary,
the correct solution is Embedded Login, but the critical factor that must be considered and communicated to the executive sponsor is its reliance on third-party cookies, which can lead to widespread browser compatibility issues.

Explanation:

The first thing that the architect at UC should investigate is the refresh token policy defined in the Salesforce connected app. A refresh token is a credential that allows an application to obtain new access tokens without requiring the user to re-authenticate.
The refresh token policy determines how long a refresh token is valid and under what conditions it can be revoked. If the refresh token policy is set to expire after a certain period of time or after a change in IP address or device ID, then the users may have to re- authenticate after using the app for a while or from a different location or device.

Option B is not a good choice because validating that the users are checking the box to remember their passwords may not be relevant, as the app uses SSO with a third-party identity provider and does not rely on Salesforce credentials.

Option C is not a good choice because verifying that the callback URL is correctly pointing to the new URI scheme may not be necessary, as the callback URL is used for redirecting the user back to the app after authentication, but it does not affect how long the user can stay authenticated.

Option D is not a good choice because confirming that the access token’s time-to-live policy has been set appropriately may not be effective, as the access token’s time-to-live policy determines how long an access token is valid before it needs to be refreshed by a refresh token, but it does not affect how long a refresh token is valid or when it can be revoked.

Explanation:

To meet compliance requirements for tracking device information and enabling the ability to revoke access to specific devices, the most appropriate Salesforce-native feature is the Activations feature (✅ Option B).

This feature tracks browser and device activation events, allowing Salesforce to maintain a history of devices from which users log in, including details such as IP address, browser type, and device identifier. When a user logs in from a new or unrecognized device, Salesforce triggers a verification challenge, and once the user confirms the device, it is recorded in the Activation records.

Importantly, administrators have the ability to revoke trusted devices through the user’s login history and device activations, effectively forcing re-verification or denying access, which directly addresses the second part of the requirement.

Other options are less suitable:

Option A (MFA) enhances login security but does not provide full device tracking or revocation capabilities.

Option C (Login History) captures login details like IP address and time but does not specifically track devices or allow device revocation.

Option D (Login Flows with custom objects) could theoretically be configured to track device info, but it would require significant custom development and would still lack native revocation capabilities.