用第三方登入快速做出安全的註冊與登入，不用自己從零管密碼。
←→ 切換章節 · 上方兩顆按鈕切換檢視 · 網址會記住你停在哪一章，可以直接分享 · 目前：互動單元 · 1／5
大部分人想到「做登入」，想的是那個表單。但表單是最簡單的部分。先看看一個真的能上線的密碼系統，你要長期養多少東西。
「用 Google 登入」按下去之後發生了六件事。它們現在是亂的 —— 拖動卡片，或用右邊的箭頭，把它排成正確的順序。
回頭看第 3 步：使用者輸入密碼的那個畫面，在 Google 的網域上，不在你的網站上。從頭到尾，使用者的密碼沒有經過你的伺服器一次。
這就是「低門檻」的真正意思 —— 不是少寫幾行程式，是你的資料庫裡根本沒有密碼可以外洩。你把風險移走了，不是把風險藏起來。
第 4 步裡 Google 要「把使用者導回你的網站」。它不會亂導 —— 只導到你事先登記過的網址。而它的比對方式是一字不差的字串比對。
這不是 Google 龜毛。如果它願意「差不多就好」，攻擊者就能登記一個像你的網址，把使用者的授權碼導到自己手上 —— 這條規則嚴格，是因為它在擋人。
順帶一提：這是新手第一天最常卡住的地方。看到 redirect_uri_mismatch，永遠先去逐字比對這兩個字串，不要去改程式邏輯。
前端的程式碼，任何人按 F12 都看得到 —— 包含你以為藏起來的環境變數。下面四樣東西在流程裡都會出現，判斷一下它們能不能出現在瀏覽器裡。
分辨方法很簡單：問「這東西是用來宣告我是誰，還是用來證明我是我？」宣告身分的（client_id、redirect_uri）本來就會公開；用來證明的（client_secret、token）進了前端就等於送出去。
所以流程的第 5 步 —— 拿 code 去換 token —— 一定發生在你的後端。整個 OAuth 的設計，就是繞著這一條線在切。
Amy 週一用 Google 登入你的網站。週三她忘了，改點 GitHub 登入 —— 兩邊的 email 都是 amy@gmail.com。你的資料庫該怎麼認？
email 不能當身分。使用者會改 email、有些平台根本不給你 email、還有平台給的是每次都不同的轉發地址。唯一穩定的識別是 provider 給的那組 ID（Google 叫它 sub）。
正確做法是兩張表：一張 users 是「人」，一張 identities 是「這個人有哪些登入方式」，一對多。要合併帳號時，讓使用者在已登入狀態下主動綁定第二個 provider —— 而不是你在後端偷偷憑 email 幫他合併。
redirect_uri 是逐字比對，差一個斜線就會擋下來 —— 而它擋的是攻擊者client_secret 和 token 只能待在後端；client_id 本來就是公開的這個單元不是單點發想。它落在我三條長期主張的交會處 —— 三條線各自解決互動教材的一個失敗模式，少一條就會做出「好玩、但學完帶不走判斷力」的東西。
學習的瓶頸從來不是資訊量，是學員腦中有沒有一個能自己往下推演的模型。HCI 給的核心啟示是：回饋延遲愈短，因果連結愈強。所以我不把互動放在「講完之後練習」的位置，而是放在「概念還沒講之前」—— 先讓他動手撞到牆，解釋才有地方掛。
AI 十分鐘就能接好 OAuth，門檻確實降了 —— 但如果沒人看得懂那段程式碼、出事沒人知道往哪裡找，那不是低門檻，是把人踢出了迴圈。所以這個單元的目標不是教他寫，是讓他有資格當那個 human in the loop：能驗收、能定位錯誤、能說出邊界在哪。
而這個主題剛好給了一個罕見的雙層對位 —— 教學層的 HITL 和產品層的 HITL 是同一個動作。
我在講座與專欄裡一貫主張的是揭露與問責：一份產出要能說清楚誰供料、模型做了什麼、誰核准、哪些結論不能外推。搬到教學上就是 —— 每一條安全規則都必須附上它的攻擊情境。不解釋動機的規則，學員會當成 AI 的怪癖繞過去；解釋了，他才會在 AI 給出一段繞過它的程式碼時停下來。
單元在世界地圖上的位置是「已經做得出畫面、開始要碰真實使用者」。學員的痛點不是不會接 SDK（AI 十分鐘就幫他接好了），是接完之後看不懂它在幹嘛、出錯時不知道往哪裡找。所以目標不是「教會他寫 OAuth」，是建立一組能拿去驗收 AI 產出的判斷力。
redirect_uri_mismatch 是這個主題的第一名求助關鍵字。改一個字元、畫面立刻變紅並指出差在哪 —— 這是「即時回饋」最該用在的地方：把 debug 的因果關係壓縮到 0.1 秒。這三條不是這個單元專用的。它們是我做任何一堂互動課都會先立的規矩，也是我判斷別人的課有沒有效時實際在看的東西。
這是一份為徵才表單製作的提案，不是可上架的成品。以下是我知道還缺什麼 —— 我認為「說得出自己漏了什麼」比多做一個功能更能說明專業程度。