API Key 是什麼？API Key（API 金鑰）是呼叫 API 時附在請求裡的一串字元，用來讓服務提供者知道請求來自哪個專案，以便計費、計算配額與限制用途；以 Google Cloud 為例，標準 API 金鑰不會驗證是哪一位使用者在呼叫。Token（權杖）則是授權的憑證，例如 OAuth 2.0 的存取權杖，代表使用者同意開放給應用程式的特定範圍與期限。企業要用 API，重點在分清楚兩者、照官方步驟申請，並把金鑰放在伺服器端、限制用途、定期輪替，合作廠商結束後一併收回。
API Key 與 Token：識別專案和代表授權的差別
API Key 回答「這個請求屬於哪個專案」：Google Cloud 文件說明，API 金鑰能將要求與專案建立關聯，以利帳單和配額管理，而標準 API 金鑰不會驗證主體。存取權杖回答「誰授權這個應用程式做哪些事」：OAuth 2.0 規格（RFC 6749）把存取權杖定義為存取受保護資源的憑證，帶有特定範圍、有效期間等屬性。API 本身的運作方式，可先參考API 是什麼與請求回應的基本概念。
| 比較項目 | API Key | 存取權杖（Access Token） |
|---|---|---|
| 代表什麼 | 呼叫端所屬的專案或應用程式 | 使用者授予應用程式的特定權限 |
| 怎麼取得 | 在服務商的管理介面建立 | 經授權流程，由授權伺服器核發 |
| 權限範圍 | 靠 API 限制與應用程式限制縮小 | 由授權時要求的範圍決定 |
| 適合情境 | 不需存取使用者私人資料的呼叫 | 代表使用者讀寫其帳號內的資料 |
另外，有些平台核發給應用程式本身的憑證也叫 Token，例如 LINE 的頻道存取權杖，性質接近 API Key，保管方式應比照辦理。
OAuth 2.0 授權流程的大意
傳統做法是由使用者把密碼交給第三方應用程式，讓它代為讀取資料。RFC 6749 指出這種做法的問題：第三方必須保存密碼、取得的權限過大、使用者無法只撤銷其中一個應用程式，任何一個第三方被入侵，密碼就跟著外洩。OAuth 改用授權層，讓應用程式拿到範圍與期限有限的存取權杖。規格中的四個角色是資源擁有者（通常是使用者）、資源伺服器、用戶端（你的應用程式）與授權伺服器，流程大意如下：
- 應用程式向使用者請求授權，常見做法是導到授權伺服器的登入與同意畫面。
- 使用者同意後，應用程式向授權伺服器證明自己的身分並出示授權結果，換取存取權杖。
- 應用程式帶著權杖向資源伺服器請求資料，資源伺服器驗證權杖有效後回應。
以 Google 的說明為例，scope 參數控管權杖允許的資源與作業，權杖透過 HTTP 授權要求標頭傳送。存取權杖的生命週期有限，到期後可用更新權杖換新；更新權杖也可能因使用者撤銷存取權等原因失效，程式要預先處理。
在 Google Cloud 控制台申請 API 金鑰的步驟
- 在 Google Cloud 控制台建立專案，或從專案清單選取要使用的專案。
- 到 API 程式庫啟用要使用的 API；依 API 而定，可能要先替專案啟用帳單。
- 前往「憑證」頁面，按一下「建立憑證」，從選單選取「API 金鑰」。
- 新增至少一項 API 限制，指定金鑰能呼叫哪些 API，這是在控制台建立金鑰的必要步驟。
- 視需要設定應用程式限制，點選「建立」，複製對話方塊顯示的金鑰字串並妥善保管。
應用程式限制分成網站（HTTP 參照網址）、IP 位址、Android 應用程式與 iOS 應用程式，一次只能套用一種；官方提醒，未設應用程式限制的金鑰可從任何位置使用。從伺服器呼叫的金鑰可限制 IP 位址，嵌在網頁的金鑰則限制網站。需要使用者授權時，改在控制台取得 OAuth 2.0 憑證，也就是用戶端 ID 與用戶端密鑰，密鑰同樣不可公開。
保管金鑰與權杖的六個原則
- 不放進前端與程式碼存放區：Google Cloud 建議不要在用戶端程式碼加入金鑰，也不要提交到程式碼存放區，以免被攔截或竊取；改由自家伺服器附上憑證後再呼叫 API。
- 不放在網址裡：金鑰放在查詢參數會出現在網址中，可能透過網址掃描遭竊，呼叫 Google API 時官方建議改用 x-goog-api-key 標頭。
- 限制來源與用途：地圖這類在瀏覽器或 App 端直接呼叫的服務，Google 地圖平台建議把金鑰限制在特定網站或應用程式，並限制可用的 API。
- 一個用途一把金鑰：官方建議為各團隊成員提供各應用程式專屬的金鑰，出事時只需處理受影響的那一把。
- 定期輪替：建立新金鑰、更新應用程式後刪除舊金鑰，只保留使用中的金鑰。
- 妥善存放並監控：更新權杖存放在安全的長期儲存空間，API 用量也要監控，才能及早發現未經授權的使用。
外包合作與人員異動時的金鑰交接
不少企業的金鑰是外包廠商用自己的帳號申請，合作結束後才發現無法控管。建議從一開始就這樣做：
- 雲端專案、開發者帳號與相關頻道以公司帳號建立，廠商以成員身分加入，權限只開到需要的範圍。
- 替廠商建立專用金鑰，並用清冊記錄每一把金鑰與權杖的用途、建立者、存放位置與限制設定。
- 結束合作或負責人離職時，移除對方的帳號權限，輪替或停用對方接觸過的金鑰與密鑰。
- 刪除舊金鑰前先確認沒有用在正式環境。
權杖也要一併處理。LINE 官方說明，頻道存取權杖若外洩，第三方可能使用該頻道，例如對所有好友群發訊息，懷疑外洩時應撤銷權杖。交接時可參考API串接的規劃流程，把金鑰管理寫進串接規格。
金鑰外洩時的處理順序
- 立即撤銷或輪替：停用外洩的金鑰或權杖，建立新的並更新程式。GitHub 的秘密掃描說明也建議立即輪替受影響的憑證；憑證已撤銷時，從版本紀錄清除通常耗時，也不一定必要。
- 檢查用量與帳單：比對外洩期間的呼叫量、來源與費用，確認是否有異常呼叫。
- 找出外洩途徑：例如寫死在原始碼、上傳到公開的程式碼存放區，或貼進共用文件與聊天訊息。
- 修正存放方式並擴大檢查：把金鑰移到伺服器端設定、補上限制，同一專案裡的其他金鑰與密碼也一併確認。
常見問題
API Key 和帳號密碼有什麼不同？
密碼用來證明登入者的身分，API Key 則是讓程式呼叫 API 時標示所屬專案，用於計費與配額。兩者都不能公開，金鑰外流後，他人可能以你的專案名義呼叫 API，用量與費用都算在你的帳上。
使用者撤銷授權後，系統會怎樣？
應用程式原本取得的權杖可能無法再使用，呼叫會失敗。程式應能辨識這種情況並提示使用者重新授權，而不是一直重試；後台也要記錄是哪位使用者的授權失效，方便客服說明。
API Key 要多久換一次？
官方建議定期輪替，但沒有規定固定的間隔。企業可以在資安規範中自訂週期，另外在負責人離職、廠商結束合作或懷疑外洩時立即更換，並更新金鑰清冊。
測試環境和正式環境可以共用同一把金鑰嗎？
不建議。分開建立金鑰，可以分別設定限制、分開觀察用量，測試程式出錯或金鑰外流時，也不會波及正式服務；正式環境的金鑰只交給少數負責人保管。
不會寫程式，可以自己申請 API Key 嗎？
可以在控制台照步驟建立，但金鑰要放在哪裡、限制哪些網站或伺服器，需要配合實際的程式設定。建議以公司帳號建立後，再和負責串接的工程師一起完成限制與存放設定。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先盤點公司目前使用中的 API 金鑰與權杖：誰建立、放在哪裡、設定了哪些限制、哪些廠商持有。京采的網頁設計服務可以協助需求釐清、檢查官網與後台的金鑰存放方式，並開發由伺服器端呼叫 API 的串接；需要整理既有串接的，歡迎與我們聯繫。
