How "Add to Slack" OAuth Actually Works

Three players, one handshake, and a secret that never touches the browser.

1 Meet the three players

🙂

The browser

What the person actually sees and clicks. Anything shown here is public.

🛤️ Rails

The Rails app

Runs on a server the public can't inspect. This is where the real secret lives.

💬 Slack

Slack's servers

Decides whether to trust the Rails app, and hands out the real access token.

2 The whole handshake, step by step

Browser Rails app Slack 1. Click "Add to Slack" — full page nav, with scopes + client ID 2. User clicks Allow — Slack redirects the browser to the Rails app's URL, with a short-lived code 3. Page JS reads code, POSTs to /api/teams 4. Rails calls Slack directly: trades the code + its secret for a real token 5. Slack replies straight to Rails with the access token 6. Rails saves the token 7. Browser shows "Team successfully registered!"
full-page redirect (browser)
background request from browser JS
server-to-server (browser never sees it)

3 Why the code isn't the token

🎫

The code

Rides through the browser in a URL. Short-lived, and by itself useless — nobody can act on it.

🔑

The access token

Only ever handed to Rails, directly, alongside a client secret only Rails knows. This is the real credential.

Splitting it into two steps means the powerful, long-lived credential is exchanged over a private server-to-server channel, where it can be paired with a secret that never appears in the browser. If Slack just put the real token straight in the redirect, anyone who could see the browser's address bar or history could steal it.