{"id":2639,"date":"2026-06-02T03:37:33","date_gmt":"2026-06-02T03:37:33","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/02\/stop-pasting-tokens-oauth2-login-for-jetbrains-ide-plugins\/"},"modified":"2026-06-02T03:37:33","modified_gmt":"2026-06-02T03:37:33","slug":"stop-pasting-tokens-oauth2-login-for-jetbrains-ide-plugins","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/02\/stop-pasting-tokens-oauth2-login-for-jetbrains-ide-plugins\/","title":{"rendered":"Stop Pasting Tokens: OAuth2 Login for JetBrains IDE Plugins"},"content":{"rendered":"
\n
\n
\n
\n

IntelliJ Platform<\/a> Plugins<\/a><\/p>\n

Stop Pasting Tokens: OAuth2 Login for JetBrains IDE Plugins<\/h2>\n

The moment a plugin needs account data, a simple API call turns into an authentication problem. The bad shortcut is familiar: ask the user to create a personal access token (PAT), make them paste it into settings, and hope it never leaks.<\/p>\n

For a JetBrains IDE plugin, use this flow instead: the user clicks the Login<\/strong> button, the browser opens, the provider handles sign-in, the IDE receives a callback, and the plugin stores the token.<\/p>\n

At a high level, the plugin will:<\/p>\n

    \n
  1. Open the provider\u2019s authorization page in the browser.<\/li>\n
  2. Receive the OAuth2 callback inside the IDE.<\/li>\n
  3. Validate the returned state<\/code>.<\/li>\n
  4. Exchange the authorization code with PKCE.<\/li>\n
  5. Store the access token in PasswordSafe<\/code>.<\/li>\n<\/ol>\n

    This post uses GitHub as the OAuth2 provider, but the same shape works elsewhere. Scopes, URLs, token responses, and refresh rules will change.<\/p>\n

    Sample code: <\/strong>https:\/\/github.com\/JetBrains\/intellij-sdk-docs\/tree\/main\/code_samples\/oauth2<\/a><\/p>\n

    \n<\/figure>\n
    <\/blockquote>\n

    The Mental Model<\/h2>\n
    <\/figure>\n

    OAuth2 is easier to reason about as hotel key cards.
    At check-in, you do not get a master key. You get a card for your room, maybe the elevator or gym. When your stay ends, the card stops working.<\/p>\n

    That is the useful bit: allowed access, but limited and temporary. An OAuth2 access token works the same way. The user signs in with the provider, and the plugin gets a token for the API access the user approved. The plugin never needs the user\u2019s password.<\/p>\n

    That approach is better than asking people to paste a long-lived secret into settings. Users stay in the browser login flow they already trust, while the provider keeps control of scopes, expiration, and revocation.<\/p>\n

    So the goal is simple: get the plugin a limited token without making the user paste one manually. The catch is that a desktop plugin cannot protect a traditional client secret.<\/p>\n

    Why PKCE Is Part of the Story<\/h2>\n

    In a web app, the server can keep a client secret on the backend. A desktop plugin cannot do that. Anything bundled into the plugin can be inspected.<\/p>\n

    That is where PKCE comes in. PKCE stands for Proof Key for Code Exchange, and it ties the returned authorization code to the login request that created it.<\/p>\n

    Before opening the browser, the plugin creates a random code_verifier<\/code> and sends GitHub a derived code_challenge<\/code>. Later, when GitHub redirects back with a temporary code, the plugin sends the original verifier to the token endpoint.<\/p>\n

    GitHub compares the verifier with the earlier challenge. If they do not match, no token. That means the returned code is not enough on its own, which is exactly what we want for a desktop plugin.<\/p>\n

    The Flow<\/h2>\n

    Here is the full flow:<\/p>\n

    <\/figure>\n
      \n
    1. The user clicks Login with GitHub<\/strong>.<\/li>\n
    2. The plugin creates state<\/code>, code_verifier<\/code>, and code_challenge<\/code>.<\/li>\n
    3. The plugin opens GitHub\u2019s authorization URL in the browser.<\/li>\n
    4. GitHub redirects back to the IDE with state<\/code> and a temporary code<\/code>.<\/li>\n
    5. The plugin validates state<\/code>.<\/li>\n
    6. The plugin exchanges the code and verifier for an access token.<\/li>\n
    7. The plugin stores the token in PasswordSafe<\/code> and calls the GitHub API.<\/li>\n<\/ol>\n

      Where the Flow Lives in Code<\/h2>\n

      The sample code lives in code_samples\/oauth2<\/code><\/a>. The flow above is split across four small pieces:<\/p>\n