Why a Salesforce Connected App with JWT Didn’t Solve UI Login

When I first started exploring ways to automate Salesforce login in Playwright, the OAuth 2.0 JWT Bearer flow seemed like the perfect solution. It was secure, didn’t require storing usernames or passwords, and was widely used for backend authentication. On paper, it felt like the right direction.
But once I tried to apply it to browser‑based UI automation, the reality was different.

What I Tried with JWT

The idea was simple: use a Salesforce Connected App to generate an access token without needing a human login. The steps looked straightforward:

• Create a Connected App in Salesforce and enable OAuth.
• Generate a public/private key pair externally.
• Upload the public certificate into Salesforce.
• Use the private key to sign a JWT on the Playwright side.
• Send the JWT to Salesforce to get an access token.
• Use that access token to authenticate the Playwright browser session.

The JWT flow itself worked perfectly — Salesforce issued a valid access token with no issues.
The problem started when I tried to use that token to skip the UI login experience.

Why JWT Didn’t Help with Browser Login

This was the key discovery:

• Salesforce treats the JWT Bearer flow as API‑only authentication.

Here’s what that means:

• It’s built for backend integrations, not browsers.
• It works best with profiles that are meant for API access, not human logins.
• It does not sign a user into the Salesforce UI.
• Even with a valid token, Salesforce still redirects the browser to the normal login page.

When I opened Salesforce in Playwright, MFA, SSO, and standard login flows still kicked in. There was no supported way to inject the JWT token into a browser session and have Salesforce consider it authenticated.

For this POC, the requirement was clear:
Automate the same UI login flow that a real user experiences — or skip it using a stored session.

JWT simply didn’t align with that need.

Practical Challenges with Key Management
Even aside from the UI limitation, JWT introduced additional operational complexity:

• Salesforce only stores the public certificate — we manage the private key.
• That private key becomes a sensitive asset requiring secure storage and rotation.
• CI/CD pipelines must be configured to access it safely.
• Any mistake becomes a security risk.

So even though JWT works well for API authentication, it added overhead without solving the UI automation problem.

Where JWT Still Makes Sense

Although it wasn’t the right fit for Playwright UI login, the JWT flow still has valuable use cases:

• Backend-to-backend integrations
• Scheduled jobs that call Salesforce APIs
• Microservices that require secure non-interactive authentication
• Data sync operations

The main takeaway from this POC was simple:

        Salesforce UI authentication and API authentication are two completely different worlds.

        JWT works beautifully in the API world — but it cannot replace the browser login path required for Salesforce UI automation.

        Once this became clear, the focus shifted toward techniques like storage state, which are actually compatible with UI automation.