What is PKCE (Proof Key for Code Exchange) in Salesforce?

 

 What is PKCE?

PKCE (Proof Key for Code Exchange) is an extra security step in the OAuth 2.0 flow.
It makes sure that the app asking for the access token is the same app that started the login process.

This is super useful for public apps (like mobile apps or single-page web apps) that cannot safely hide a client secret.

---

 How PKCE Works (Simple Version)

1. App creates a code verifier & code challenge

   • The app makes a random secret string (code verifier).

   • It also makes a scrambled version of it (code challenge).

2. Login request

   • The app sends the code challenge when asking Salesforce for an authorization code.

   • Salesforce remembers this challenge.

3. Salesforce gives back an authorization code

   • But Salesforce keeps the challenge safe.

4. App asks for an access token

   • The app sends back the authorization code AND the original code verifier.

5. Salesforce checks

   • Salesforce scrambles the verifier the same way and checks if it matches the stored challenge.

   • If it matches → Salesforce knows it’s the same app and gives the access token.

---

Why PKCE is Important

• No stolen codes → If a hacker steals the authorization code, they can’t use it without the secret verifier.

• Safer for public apps → No need to store a client secret in the app.

• Salesforce supports it → You can turn PKCE on in connected apps or org-wide.

---

Think of it like a two-part lock system:

• You give Salesforce a scrambled key first.

• Later, you must prove you have the real key that makes that scramble.

• Only then you get in. 

In Salesforce PKCE, the algorithm used is:

• SHA-256 (most secure and recommended)

• Or plain (no hashing) – only allowed for backward compatibility

---

How it works with algorithm:

1. SHA-256 (recommended)

   • App generates a random code_verifier.

   • Creates a code_challenge = BASE64URL(SHA256(code_verifier)).

   • Salesforce stores the challenge.

   • Later, Salesforce checks the provided verifier by hashing it again with SHA-256 and comparing.

2. Plain (not secure, but supported)

   • code_challenge = code_verifier (no hashing).

   • Easier but less secure, because if someone sees the challenge, they know the verifier.

---

So in practice:

• Always use SHA-256 with Salesforce PKCE.

• Only fall back to plain if you’re debugging or integrating with a legacy client.

 PKCE (Proof Key for Code Exchange) – Interview Q&A

---

1. What is PKCE in OAuth 2.0 and why is it used in Salesforce?

Answer:
PKCE (Proof Key for Code Exchange) is a security extension to the OAuth 2.0 authorization code flow.
It is mainly used for public clients (like mobile apps or SPAs) that cannot securely store a client secret.

• It prevents authorization code interception attacks by requiring the client to prove it was the original requester before exchanging an authorization code for a token.

---

2. How does PKCE work in simple steps?

Answer:

1. The client generates a random string → code verifier.

2. It hashes it (SHA-256) → code challenge.

3. The code challenge is sent in the authorization request to Salesforce.

4. Salesforce stores the challenge and issues an authorization code.

5. The client later sends the authorization code + original code verifier to get the access token.

6. Salesforce re-hashes the verifier, compares it with the stored challenge, and if they match → access token is issued.

---

3. What algorithms does PKCE support?

Answer:

• S256 (SHA-256 hashing) → recommended and most secure.

• plain → allowed for backward compatibility (but not secure).
  Salesforce supports both, but SHA-256 should always be used.

---

4. How is PKCE different from using a client secret?

Answer:

• Client Secret: Used by confidential clients (server-based apps) that can keep secrets secure.

• PKCE: Designed for public clients (mobile, SPA) that cannot store secrets safely.
  Instead of relying on a fixed secret, PKCE generates a dynamic, one-time secret (code verifier) for each flow.

---

5. Why is PKCE needed if we already have HTTPS?

Answer:
HTTPS protects data in transit, but doesn’t prevent an attacker who steals the authorization code from using it.
PKCE ensures that only the client with the original code verifier can exchange the authorization code, making the stolen code useless to attackers.

---

6. How do you enable PKCE in Salesforce?

Answer:

• Salesforce allows enabling PKCE in Connected Apps or at the org level.

• When enabled, any client using the Authorization Code flow must supply code_challenge and code_verifier.

---

7. Can PKCE be used with all OAuth flows in Salesforce?

Answer:
No. PKCE is specifically designed for the Authorization Code flow.
It’s not needed for flows like Client Credentials flow (used server-to-server) because those already use a client secret.

---

8. What happens if the code verifier and stored challenge don’t match in Salesforce?

Answer:

• Salesforce rejects the token request and does not issue an access token.

• This prevents attackers from using a stolen authorization code without the correct verifier.

---

9. Give a real-world example of PKCE in Salesforce integration.

Answer:

• A mobile app that integrates with Salesforce for user login.

• Since the app cannot store a client secret securely, it uses PKCE:

  • The app sends a code challenge when starting login.

  • When exchanging the code for tokens, it proves it has the original code verifier.

---

10. Quick Analogy Question

Q: “Explain PKCE to a non-technical stakeholder.”
Answer:
PKCE is like locking a box with a custom key you just created:

• You tell Salesforce the “shape” of the key (the code challenge).

• Later, you must prove you still have the original key (the verifier).

• If the shape and key match, Salesforce gives you access.

• If a thief steals the code (the box), they can’t open it without your unique key.