Salesforce Integration Interview Question & Answer Part 1

A Salesforce interview about OAuth will focus on your understanding of the protocol, its various flows, and how to implement it securely within the Salesforce platform. A strong candidate can discuss specific Salesforce features like Connected Apps and Named Credentials, as well as general security best practices. 

Question 1: What is OAuth 2.0, and why is it used?

Answer: OAuth 2.0 is an open standard for access delegation. It allows a client application to access resources on behalf of a resource owner without needing their credentials. In Salesforce, this is used for secure API integrations, allowing external apps to interact with your Salesforce org using an access token instead of a username and password.

Cross Questions:

• Q: Why not just use username-password? → Hard-coded creds are insecure, rotation is painful, and audit control is missing. OAuth avoids this.

• Q: What’s the main benefit in Salesforce? → Central control through Connected App (you can revoke anytime).

Question 2: Explain the difference between OAuth and OpenID Connect (OIDC).

Answer: OAuth 2.0 is an authorization protocol for delegating access to resources. OIDC is an identity layer on top of OAuth 2.0. While OAuth only confirms that an application has permission to access data, OIDC provides an ID token that confirms the identity of the end user.

Question 3: What is the purpose of an access token vs. a refresh token?

Answer: An access token is a short-lived credential that grants access to specific resources (e.g., Salesforce APIs) and is included with each API request. A refresh token is a long-lived credential used to obtain a new, fresh access token after the current one expires, without requiring the user to log in again. 

Question 4: What is a Connected App in Salesforce?

Answer: A Connected App is a framework that allows an external application to connect to Salesforce APIs. It defines the permissions and OAuth settings for the integration. It includes a consumer key (client ID) and a consumer secret (client secret) for authentication.

Cross Questions:

• Q: Who creates it? → Admin configures in Salesforce.

• Q: Can I control which users can use it? → Yes, via Profiles & Permission Sets.

Question 5: When would you use a Named Credential for an integration?

Answer: You would use a Named Credential when making an authenticated callout from Salesforce to an external system. Named Credentials simplify callouts by handling all authentication details—including the OAuth flow—so developers don't have to write code for token management. It also centralizes configuration and prevents hardcoding credentials in Apex.

Question 5: What are the different OAuth 2.0 flows available in Salesforce?

Answer: Salesforce supports several OAuth 2.0 flows, including:

• Web Server Flow: For web apps that can securely store a client secret.
• User-Agent (Implicit Grant) Flow: For client-side apps like single-page applications, though it's less secure and often replaced by the Auth Code + PKCE flow.
• JWT Bearer Flow: For server-to-server integrations that don't require user interaction, using a digital signature for authentication.
• Username-Password Flow: For apps with trusted clients that can securely store user credentials.
• Device Flow: For devices with limited input capabilities, like TVs or IoT devices.

Question 6: Explain the OAuth 2.0 Web Server flow in Salesforce.

Answer:

• The client app requests authorization by redirecting the user to a Salesforce login page.
• The user logs in and approves the Connected App's access.
• Salesforce sends an authorization code back to the client's registered callback URL.
• The client app exchanges the authorization code for an access token (and optionally a refresh token) using its client secret.

Cross Questions:

• Q: Why 2-step (code + token) instead of direct? → Adds security, prevents leaking tokens in browser redirect.

• Q: How long is access token valid? → By default, ~15 min.

Question 7: Describe the JWT Bearer flow and when it is used.

Answer: The JWT Bearer flow is used for server-to-server integrations where a user is not present. Instead of a manual login, a JSON Web Token (JWT) is signed with a certificate and sent directly to Salesforce's token endpoint. Salesforce validates the signature and issues an access token. This is ideal for automated, headless processes.

Cross Questions:

• Q: How do you rotate keys? → Maintain multiple certs in Connected App, rotate smoothly.

Question 8: How does PKCE enhance the Web Server flow in Salesforce?

Answer: Proof Key for Code Exchange (PKCE) is an extension that adds an extra layer of security to the Web Server flow, particularly for public clients like mobile apps. The client generates a random code verifier, hashes it to create a code challenge, and sends the challenge with the initial authorization request. It then sends the original verifier when exchanging the code for a token. Salesforce validates that the verifier matches the challenge, preventing authorization code interception. 

Scenario-based and advanced topics

Question 1: How do you securely handle client secrets in OAuth integrations?

Answer: The method depends on the client. For web server-based integrations, the secret should be securely stored on the server. For public clients like mobile apps, the secret cannot be kept confidential, which is why a flow with PKCE is required to prevent interception. You should never store the client secret in client-side code.

Question 2: A user reports an "invalid_grant" error during token exchange. What are the potential causes?

Answer: This error often indicates a problem with the authorization code or refresh token. Potential causes include:

• The authorization code was used more than once.
• The refresh token has expired or been revoked.
• There is a mismatch in the redirect_uri used during the initial request and the token exchange.
• The client_id or client_secret are incorrect.

Question 3: What are OAuth scopes and how do you use them in Salesforce?

Answer: Scopes define the permissions granted to an application via an access token. In Salesforce, you define scopes in a Connected App to control what data and API access a third-party application can have. Examples include api, full, refresh_token, or chatter_api.

Cross Questions:

• Q: Why not always give “full”? → Follows principle of least privilege. Reduce risk.

Question 4: How do you manage token expiration and refreshing in a custom integration?

Answer: Your client application needs to monitor the lifespan of the access token. When an API call returns a 401 Unauthorized error (or when the token is about to expire), the app should use the long-lived refresh token to request a new access token from Salesforce's token endpoint. This avoids requiring the user to re-authenticate.

Question 5: Describe a scenario where you would use an Auth Provider in Salesforce.

Answer: You would use an Auth Provider to configure Salesforce as a client to a third-party service, enabling Single Sign-On (SSO) or social sign-on. For example, you can use an Auth Provider to allow users to log in to Salesforce using their Google or Facebook credentials.