Stop Pasting Tokens: A Better Login Pattern for JetBrains Plugins

The moment a plugin needs access to a user’s account, authentication becomes part of the product. That is where many integrations still take a shortcut: generate a personal access token, paste it into a settings panel, and hope it never leaks.

JetBrains is pushing developers toward a different model. Its latest guidance for IDE plugin developers shows how to implement OAuth2 with PKCE, allowing users to sign in through the provider’s normal browser flow instead of manually handling long-lived secrets.

What Changed#

The JetBrains Platform team published a practical OAuth2 login flow for IDE plugins, using GitHub as the example provider.

The flow is familiar to anyone who has used modern web applications:

• The user clicks a login button inside the plugin.
• The browser opens the provider’s authorization page.
• The provider handles authentication.
• The IDE receives a callback.
• The plugin exchanges the authorization code for a token.
• The token is stored locally and used for API access.

GitHub is only the example. The same structure applies to other OAuth2 providers, although scopes, token formats, refresh behavior, and endpoint URLs vary.

The important change is not the specific implementation. It is the shift away from training users to manage raw credentials themselves.

For years, many developer tools treated token pasting as an acceptable user experience. It was simple to build and easy to document. It was also a security compromise disguised as convenience.

Why Stop Pasting Tokens Matters#

Personal access tokens solve an engineering problem quickly. They often create a security operations problem later.

A pasted token frequently becomes a long-lived credential with broad permissions. It may end up in screenshots, support tickets, clipboard histories, backups, notes, shell history, or configuration exports. Once distributed, visibility becomes difficult.

OAuth2 changes that trust model.

Instead of collecting a master credential, the plugin receives a token tied to a specific authorization flow and a defined set of permissions. The identity provider remains responsible for authentication, consent, scope management, expiration, and revocation.

That distinction matters because plugins increasingly connect to developer infrastructure, source repositories, AI services, ticketing systems, deployment environments, and cloud resources. A plugin requesting account access is no longer making a simple API call. It is becoming part of the user’s trust boundary.

The JetBrains guidance highlights a useful principle: the plugin never needs the user’s password.

That may sound obvious, but many security incidents begin with systems collecting more secrets than they actually require.

Why PKCE Is Central to the Design#

OAuth2 alone is not the interesting part here. PKCE is.

Traditional OAuth deployments often rely on a client secret stored on a backend server. Desktop applications and IDE plugins do not have that luxury.

Anything shipped inside a plugin can be inspected.

A bundled secret is not really secret.

PKCE, short for Proof Key for Code Exchange, addresses that problem by linking the authorization request to the token exchange that follows.

Before opening the browser, the plugin generates a random verifier and derives a challenge from it. The challenge is sent during authorization.

Later, when the provider redirects back with an authorization code, the plugin must present the original verifier.

If the verifier does not match the earlier challenge, the token request fails.

That means an intercepted authorization code is not enough by itself.

For desktop software, this is not a minor implementation detail. It is the mechanism that makes OAuth2 practical without requiring embedded secrets.

The broader lesson extends beyond JetBrains plugins. Any local application handling OAuth2 should be evaluated through the same lens: where does trust live, what can be extracted from the client, and what prevents code interception from becoming account access.

How the Flow Is Structured#

One useful aspect of the JetBrains example is architectural rather than cryptographic.

The implementation is split into small components instead of one large authentication subsystem.

The example separates:

• plugin configuration and registration
• settings UI
• callback handling
• token exchange and storage

That separation sounds mundane, but authentication systems often become difficult to audit because login, storage, networking, state management, and UI logic end up mixed together.

JetBrains explicitly keeps the settings interface simple. The UI primarily exposes login, logout, and connection state.

The callback is handled through the IDE’s built-in HTTP server, which receives the redirect from the provider and completes the pending authorization request.

The result is easier to reason about than many custom authentication implementations that evolve organically over time.

What Developers Should Check#

If you maintain an IDE plugin, extension, desktop client, or developer integration, the practical question is straightforward.

Do users still paste credentials into your product?

If the answer is yes, review whether OAuth2 with PKCE can replace that workflow.

A useful checklist:

• Identify where users manually paste tokens today.
• Review whether those tokens are long-lived.
• Check how tokens are stored and protected locally.
• Verify whether permissions are broader than necessary.
• Confirm that revocation and expiration are handled cleanly.
• Evaluate whether browser-based login can replace credential collection.

This is not only a security improvement. It reduces operational friction for users who already understand and trust the provider’s login experience.

What Not to Overclaim#

The JetBrains post is a developer implementation guide, not a security guarantee.

OAuth2 does not eliminate risk. PKCE does not eliminate risk. Local token storage still matters. Scope design still matters. Providers still differ in how they handle refresh tokens, revocation, and authorization policies.

The article also does not claim that every existing token-based workflow is insecure.

The stronger claim is narrower and better supported: when account access is required, asking users to generate and paste personal tokens is often the weakest part of the experience.

The direction of travel across modern software is clear. Authentication is moving toward delegated access, limited permissions, explicit consent, and provider-controlled lifecycle management.

JetBrains is applying that pattern to IDE plugins. For developers building integrations, the real takeaway is simple: stop treating token pasting as the default.