氛圍學院
身份驗證› 低門檻身份驗證與第三方登入 7 分 2 秒

先看一次:自己做的帳號密碼系統,前後端在做什麼

在講「使用 Google 登入」之前,先看清楚如果什麼都自己來,一套帳號密碼系統長什麼樣子。有了這個基準,才看得出第三方登入到底幫你省掉了什麼。

下面左邊是使用者的手機,右邊是你的後端。整套流程只有四個動作:註冊、登入、拿著通行證做事、通行證失效。跟著做一次。

使用者的瀏覽器閒置
9:41▮▮▮ ᯤ
我的
🔑 尚未登入
電子郵件
密碼
我的訂單
無線耳機NT$ 2,480 · 已出貨
手沖咖啡壺NT$ 890 · 準備中
庫存查詢
無線耳機38 件
手沖咖啡壺12 件
保溫隨行杯0 件
帳戶設定
電子郵件meimei0613@gmail.com
密碼••••••••
登入方式帳號密碼
資料往來
閒置
你的後端你自己的伺服器閒置
🗄 資料庫users
emailpassword
——
📜 執行紀錄server.log
// 還沒有請求進來
🎫 瀏覽器保管的通行證
🎫還沒有通行證
通行證存在瀏覽器裡,不是手機畫面上的東西。登入成功後它才會出現。

除了註冊登入,你還得自己處理這些

剛才那四個動作,是這套系統會動起來的最低要求。但要能真的上線,還有一串事情得自己扛。下面這六張卡都只是先簡單提一下,每一件展開來都夠講一整堂課,這裡不深入。

點上面任一張卡,看它是什麼
這六件事,全部都是為了保管一個你其實不需要知道的秘密。那有沒有辦法,乾脆不要保管它?

更方便的選擇:「Google 登入」

承上一段:與其自己保管密碼,不如把「證明你是你」這一步交給 Google。

使用者按下那顆按鈕之後,畫面背後會依序經過這幾個階段:

  1. 導向 Google 授權頁:你的網站把使用者帶到 Google 的授權頁,並說明網站是誰、想要什麼資料。
  2. 使用者授權:輸入你的 Google 帳號與密碼,並在授權頁面上決定要不要同意網站取得你的資訊。
  3. 拿回授權碼:Google 把使用者送回你的網站,並帶著一張只能用一次的授權碼,通常會附在網址上。
  4. 後端換資料:你的後端拿授權碼去跟 Google 換使用者資料,這一步在兩台伺服器之間進行。
  5. 建立登入狀態:後端在自己的資料庫建好帳號,發出你自己的通行證。

下面把每個階段拆開,看它們各自由誰發起、帶了什麼。

🔑 開始之前,你要先做一件事
到 Google 的開發者後台把這個網站登記起來。登記完 Google 會給你一組 client_id 和 client_secret,你也要在那裡先填好「授權完成後要把人送回哪個網址」。這三樣東西是下面整個流程的前提。
使用者的瀏覽器閒置
9:41▮▮▮ ᯤ
VibeShop
登入以查看你的訂單
或
電子郵件
密碼
正在前往 Google…
等你的後端回應
🙋‍♀️
歡迎回來,小美
使用 Google 帳戶登入
我的訂單近 30 天 2 筆
會員資料m****6@gmail.com
資料往來
你的後端
Google
你的後端你自己的伺服器閒置
// 還沒有請求進來
伺服器之間 使用者看不到
Google 伺服器身分提供者閒置
// 還沒有請求進來
⏱ 三方之間的往來順序
使用者的瀏覽器看得到
你的後端你自己的伺服器
Google身分提供者
① 帶著 client_id、redirect_uri、scope
client_id是哪個網站在問。Google 後台發給你的公開編號,Google 靠它認出請求是誰送來的81726354-vibeshop.apps.googleusercontent.com
redirect_uri辦完把人送回哪裡。使用者授權後,Google 要把授權碼送回這個網址;這個網址必須事先登記過,臨時改沒有用https://vibeshop.tw/callback
scope想跟使用者拿什麼。這一次只要姓名和 Email,不是要通行證,也不是要密碼email profile
② Google 自己的授權畫面
使用者是在 Google 的頁面上打密碼,不是在 VibeShop 上
③ 使用者按下「允許」
同意之後,Google 才會發出授權碼
④ 授權碼
授權碼不是直接送到後端:Google 先把使用者的瀏覽器重新導向回你登記的網址,授權碼掛在網址參數上;瀏覽器再帶著它請求你的後端。
正因為它經過網址列、有被看到的風險,才設計成只能用一次、幾分鐘就過期,而且光有它還換不到資料——還得配上只有後端知道的 client_secret。
⑤ 授權碼 + client_secret
你的後端帶著這些資訊向 Google 索取使用者的身分資料。
client_secret 只能放在後端,因為前端的程式碼是公開的。
⑥ id_token + access_token
回來的不是現成的欄位,而是兩張 token。使用者資料包在 id_token 這串字裡,解開才看得到。
access_token拿去呼叫 Google 其他服務用的鑰匙,這一課用不到ya29.a0AfH6SMBx…
id_token使用者資料就在這串裡。它是一段 Google 簽好的 JWT,跟第一段那張通行證同一種東西eyJhbGciOiJSUzI1NiIsImtpZCI6…
解開 id_token 之後:
sub永久編號。Google 給這個人的固定 ID,不會變104829173650284917362
email電子郵件地址meimei0613@gmail.com
email_verifiedtrue 已經驗證過
name小美picture: https://lh3.googleusercontent.com/…
⑦ 寫進自己的資料庫
帳號建好了,登入方式記成 Google
⑧ 你自己發的通行證
跟第一段那張證一模一樣,至此便完成註冊與初次登入

兩種做法的取捨

看完兩條路,該回答的問題是:什麼時候用哪一個。點下面每一個項目,看兩種做法各自的答案。

比較項目 🔧自己做帳號密碼 🅖用 Google 登入
⚠️ 關於「帳號分裂」
這個問題只有在網站同時提供兩種登入/註冊方式時才會發生。如果你只放 Google 登入,或只放帳號密碼,就沒有這回事。但實務上多數產品兩種都會放,所以幾乎一定會遇到。
email登入方式訂單狀態
meimei0613@gmail.comgoogle1 筆重複
meimei0613@gmail.com密碼1 筆重複
同一個信箱、同一個人,卻在資料庫裡變成兩列。她用 Google 登入時買的東西,改用密碼登入就看不到了。要不要把兩邊併起來、怎麼併,都得你自己決定。
實務上怎麼選
大多數面向一般使用者的產品是兩種一起放:主推 Google 登入降低門檻,同時留一條帳號密碼的路,給沒有 Google 帳號、或不想把服務綁在 Google 上的人。企業內部系統和需要實名的服務則是另一套規則,不在這堂課的範圍。

重點回顧

這一課把「為什麼第三方登入比較省事、又省在哪裡」講完了。帶走這三個重點:

1
登入這件事的骨架,兩條路都一樣
驗明身份、發一張通行證、之後每個請求都要出示。第三方登入換掉的只有第一步,後面兩步還是你自己在做。
第 1 步
驗明身份
Google 換掉的是這一步
第 2 步
發一張通行證
還是你的後端發
第 3 步
每次請求都出示
還是你自己驗
2
你的網站從頭到尾沒看過密碼
使用者的密碼打在 Google 的頁面上,跳回來的只是一張只能用一次的授權碼。真正換資料那一趟發生在兩台伺服器之間——所以 client_secret 不能離開後端。
換句話說,你把密碼的保管風險,連同重設密碼、寄驗證信、防人一直猜密碼這一整套繁瑣的維護流程,都交給 Google 處理了。
3
它省掉的是密碼管理,不是身份設計
外洩風險、忘記密碼、寄驗證信這些你可以不用做了;但服務依賴、拿不到真實信箱、帳號分裂這些問題還是你的。

隨堂檢測

0 / 4
Q1使用 Google 登入時,使用者的密碼實際上是打在誰的網頁上?
Q2從 Google 跳回你的網站時,網址上帶回來的是什麼?
Q3為什麼 client_secret 不能寫在前端的程式碼裡?
Q4改用 Google 登入之後,下面這些工作還要不要自己做?
四題都對了。你已經能看懂一次第三方登入從頭到尾在做什麼,也知道哪些工作它幫你省掉、哪些還是你的。
0:00
7:02
100