Explanation:

Universal Containers (UC) has enabled refresh tokens for their mobile app to prevent users from re-entering credentials, but users still need to log in daily. Refresh tokens in Salesforce OAuth flows allow apps to obtain new access tokens without user re-authentication, typically lasting until revoked or expired. The issue likely stems from the refresh token configuration.

B. The refresh token expiration policy is set incorrectly in Salesforce:
This is the most likely cause. In Salesforce, the refresh token expiration policy for a Connected App can be configured to expire after a set period (e.g., 24 hours). If UC set the refresh token to expire daily, users would need to re-authenticate every 24 hours, causing the reported issue. Correcting the policy (e.g., setting it to "Refresh token is valid until revoked") would resolve this.

A. The OAuth authorizations are being revoked by a nightly batch job:
While possible, this is less likely without specific evidence of a batch job revoking tokens. Revocation typically occurs manually or through explicit admin action, not as a default behavior, and would likely cause immediate access issues, not a daily prompt.

C. The app is requesting too many access tokens in a 24-hour period:
Salesforce does limit access token issuance, but this would typically result in API errors (e.g., rate limit exceeded) rather than forcing daily re-authentication. Refresh tokens are designed to handle multiple access token requests, so this is unlikely.

D. The users forget to check the box to remember their credentials:
This is irrelevant in the context of OAuth refresh tokens, as the "remember credentials" option applies to browser-based login flows, not mobile apps using OAuth. The app should handle token refresh automatically.

Reference:
Salesforce Help: OAuth Tokens and Scopes
Salesforce Developer: Understanding Refresh Tokens

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:

Rationale for High-Assurance Session
This solution leverages Salesforce's built-in Session Security Levels to manage access to sensitive actions like exporting reports, which is the most secure and scalable approach for this requirement.
SAML Federated Authentication: Users logging in with their Active Directory (AD) credentials will use SAML (or another SSO protocol) to authenticate against the external Identity Provider (AD).
Treat SAML Sessions as High Assurance: In Salesforce's Single Sign-On Settings, the Identity Architect can configure the SAML login handler to result in a High Assurance session. This marks all users who successfully logged in via AD as having met the highest security standard.
Raise Session Level for Exporting Reports: In Salesforce's Session Settings, the administrator can move the "Export Reports" permission from the standard "Standard" session security level to the "High Assurance" session security level.

Why This Works

AD Login (SSO): Users log in via AD → Session is High Assurance → User can export reports.
Salesforce Login (Standard Credentials): Users log in directly with Salesforce credentials → Session is Standard assurance → User cannot export reports (they can view them, as viewing is typically a Standard level action).
This meets all parts of the requirement: users must use AD to export, but they can still view reports when logged in with Salesforce credentials.

Why Other Options Are Incorrect

A and D. Use a Permission Set or Login Flow: While login flows and permission sets can dynamically manage permissions, they are not the best practice for session security requirements. A login flow runs once at login, but a user's session assurance level is checked continuously before executing high-risk actions. If you use a permission set, the user would lose the ability to export reports immediately upon logging out and back in via the non-AD path, but relying on session security levels is the correct feature for continuous, policy-based risk mitigation.
C. Block access to reports when accessed through a standard assurance session: This is too broad. The requirement is only to block exporting reports, not viewing them. Raising the session level for the specific "Export Reports" permission is the granular control needed.

Explanation:

Login Forensics is a feature in Salesforce designed specifically to help security teams detect suspicious login behavior. It provides advanced insights such as:

📊 Average number of logins per user
🚨 Users who logged in more than the average
🌙 Logins during non-business hours
🌍 Geographic anomalies (e.g., logins from unexpected countries)

This makes it the ideal tool for identifying potential fraudulent activity or compromised accounts in a large organization like one with 15,000 employees.

❌ Why the other options fall short:
B. Login Report:
Offers basic login data but lacks advanced analytics like averages or time-based anomalies.
C. Login Inspector:
Used for debugging login issues during development—not for security analysis.
D. Login History:
Provides raw login data (IP, time, status), but requires manual analysis and doesn’t highlight patterns or anomalies.

🔗 Reference:
Salesforce Login Forensics Overview

Explanation:

Universal Containers (UC) will build a custom Innovation platform entirely in Apex and Visualforce, using custom objects. They plan to authenticate employees via a third-party Identity Provider (IdP) with SAML SSO; employees shouldn't use Salesforce credentials. For this scenario, the Salesforce Platform License is optimal. It supports Apex, Visualforce, custom objects, reports, dashboards, Flows, and SAML-based SSO, ensuring employees have the tools they need without full CRM access.

👉 Option A (Identity License) isn't sufficient. Identity licenses are focused on authentication and single sign-on and do not support Visualforce, Apex, or access to custom objects.

👉 Option B (Salesforce License) is overkill—this full-featured CRM license grants access to standard Sales Cloud objects like Leads, Opportunities, and Cases, which the Innovation platform doesn’t need.

👉 Option C (External Identity License) is for external users (e.g., partners or customers) and lacks access to custom Apex/Visualforce or internal apps.

Therefore, the Platform License neatly fits the requirement: SSO login via SAML, ability to use Apex/VF and custom objects, without unnecessary licensing features.

References:
Standard User & Platform Licence Overview — Salesforce Help