OAuth 2.0：現代網站常見的授權登入機制

你一定用過「用 Google 帳號登入」或「用 LINE 登入」這類功能。點下去，跳到 Google 的頁面，確認授權，回到原本的網站，登入完成。

這個流程背後的機制，就是 OAuth 2.0。

先釐清一個容易混淆的概念

OAuth 2.0 本身是「授權」協定，不是「身份驗證」協定。

這兩個聽起來很像，但意思不同。授權是「你同意讓這個服務存取你的某些資料」，身份驗證是「確認你是你」。

實際上，現在的第三方登入通常是在 OAuth 2.0 之上再加一層叫 OpenID Connect（OIDC）的協定，才能做到完整的身份驗證。但大多數人講「用 Google 登入」時說的 OAuth 2.0，理解成「一個允許你透過第三方帳號進行授權和登入的機制」，方向是對的。

想像一個情境：你在用某個第三方工具，它需要存取你 Google 日曆裡的行程。

最直接的方式是：直接把你的 Google 帳號和密碼給這個工具。問題很明顯——這等於把你的帳號完全交出去，那個工具想做什麼都行，而且如果它出了安全問題，你的 Google 帳號也跟著曝露。

OAuth 2.0 提供了一個更安全的方式：你不需要給密碼，只需要告訴 Google「我允許這個工具存取我的日曆（只有日曆，其他的不行）」，Google 發一個有限權限的 Token 給那個工具，它拿這個 Token 去操作，而不是直接用你的帳號。

這個設計的好處是：

以「用 Google 登入某個網站」為例，簡化後大概是這樣：

這個流程裡，你的 Google 密碼只在第三步輸入，而且是輸入給 Google 自己，網站完全看不到。

Token 可以理解成一張有期限的通行證。

Access Token：短效，通常幾小時到幾天就過期。用來實際存取資料。

Refresh Token：長效，用來在 Access Token 過期後重新取得新的 Access Token，不需要使用者再重新授權一次。

為什麼要設計成有期限？因為 Token 如果外洩，損害是有上限的——過期就失效了。密碼外洩的損害就很難控制。

如果你在做一個需要整合第三方服務的系統，或者要讓用戶可以用 Google、LINE、Facebook 登入，OAuth 2.0 幾乎是唯一的主流選擇。

現在的開發通常不需要從頭實作 OAuth 的細節——大多數框架和語言都有成熟的函式庫（如 NextAuth.js、Passport.js）可以處理這些流程。但理解它的設計邏輯，對你在設定權限範圍、處理 Token 存儲、判斷安全邊界的時候，還是有實際幫助的。

LINE Login 就是基於 OAuth 2.0 + OIDC 建立的。如果你做 LINE LIFF 應用，讓用戶用 LINE 帳號直接登入，背後走的就是這套機制——只是 LINE 把它包裝成更簡單的 SDK，讓你不需要直接處理底層流程。

OAuth 2.0 不等於「安全的登入」，它只是提供了一個標準化的授權框架。

實作上還是有很多細節要注意：Token 存在哪裡（不能存在 LocalStorage，容易被 XSS 攻擊）、HTTPS 是否全程加密、授權碼是否有防範 CSRF 攻擊的機制（state 參數）……

安全性最終取決於整個系統的設計，OAuth 2.0 是一個良好的起點，但不是終點。