後端可以透過解析cookie的方式獲取到token，但這種方式有很多限制和安全隱患，因此不建議直接從cookie中獲取token。

首先，cookie是由瀏覽器管理的，而token是由伺服器生成和驗證的。如果直接從cookie中獲取token，那麼就需要在後端程式碼中呼叫瀏覽器的API來讀取cookie，這樣會讓後端和瀏覽器的職責發生混淆，導致程式碼不夠清晰。此外，如果使用cookie儲存token，還需要處理cookie的過期時間和域名等問題，這增加了系統的複雜度。

其次，直接從cookie中獲取token存在一定的安全隱患。如果token儲存在cookie中，那麼它可以被竊取、篡改或偽造。例如，如果網站存在跨站指令碼漏洞（XSS），攻擊者就可以透過注入惡意指令碼的方式竊取cookie中的token。而將token儲存在Authorization頭中，可以避免這些安全問題，因為Authorization頭中的token只能在HTTP請求頭中進行傳輸，無法透過惡意指令碼或其他攻擊手段進行篡改或偽造。

因此，建議在前端將token設定到Authorization頭中，然後在後端透過解析HTTP請求頭獲取token，這樣既能保證系統的安全性，又能使程式碼更加清晰和易於維護。

雖然後端可以從 cookie 中取出 token，但是從安全和可靠性的角度考慮，建議將 token 設定到請求頭的 Authorization 欄位中。

將 token 放在 Authorization 欄位中是一種標準的做法，這樣能夠讓伺服器更方便地從請求頭中獲取 token，同時也可以透過設定 CORS（跨域資源共享）來限制只有來自特定域名的請求才能夠獲取到 token，增加了安全性。

另外，從前端的角度來看，將 token 設定到 Authorization 欄位中也可以讓前端程式碼更加清晰易懂，方便開發人員在開發過程中進行除錯和維護。如果將 token 直接放在 cookie 中，可能會導致程式碼邏輯更加混亂，不利於程式碼的可維護性和可讀性。

因此，雖然後端可以直接從 cookie 中取出 token，但是為了安全和可靠性的考慮，建議將 token 設定到 Authorization 請求頭中。

雖然後端可以直接從cookie裡取到token，但是從安全性和可維護性考慮，前端通常還是需要將token設定到Authorization header中，而不是直接將token儲存在cookie中。

首先，將token儲存在cookie中可能存在一些安全風險。例如，如果你的應用程式使用了不安全的傳輸協議（例如HTTP而不是HTTPS），那麼透過cookie傳輸的token可能會被攔截和竊取。此外，如果您將token儲存在cookie中，那麼它將在所有應用程式請求中自動包含，而不僅僅是您希望它包含的那些請求。這可能會增加您的應用程式被攻擊的風險。

另外，將token儲存在Authorization header中可以使程式碼更具可維護性。當您的應用程式需要向不同的API傳送請求時，您只需要在程式碼中的單個位置設定Authorization header，而不需要在每個請求中都設定cookie。

最後，將token儲存在Authorization header中還使得您的應用程式可以更輕鬆地與其他認證方案整合，例如OAuth2或JWT。這些方案通常都需要將token儲存在Authorization header中，因此將token儲存在此位置可以使您的應用程式更易於擴充套件和維護。

首先，傳遞 token 的方式有很多，如 cookie、請求頭、請求引數等。將 token 放在請求頭中是一種常見的做法。把 token 放在請求頭中，可以將 token 與具體的請求資料隔離開來，方便後端程式的解析。

其次，放在請求頭中的 token 可以很好的進行安全性的保護。如果把 token 放在請求引數中，那麼 token 就會在 URL 中體現，如果 URL 被截獲，則 token 就洩漏了。而請求頭中的資料不會出現在 URL 中，因此更加安全。

此外，請求頭中的資料是不經過快取的，因此更加安全。在 cookie 中儲存的資料是會被快取的，如果有惡意指令碼對 cookie 進行了篡改，那麼後端就很難發現問題。

同時，透過請求頭傳遞的 token 更加靈活。在前後端分離的架構中，可能會出現多種請求方式，例如 RESTful API 請求、websocket 請求等，在這些請求中，使用請求頭傳遞的 token 更加方便。

最後，透過請求頭傳遞的 token 更加符合 HTTP

前端和後端通訊時，前端通常將token設定到Authorization請求頭中，是因為在HTTP協議中，Authorization請求頭是用於標識使用者身份的。使用這種方法，後端可以方便地讀取Authorization請求頭中的token，並驗證它的有效性。

然而，Cookie也是用於儲存使用者會話資料的常見方法，因此後端也可以直接從Cookie中讀取token。不過，將token儲存在Cookie中有一些安全隱患，因為Cookie可能被直接在客戶端訪問，並在瀏覽器或代理伺服器中被記錄，因此它們可能更容易遭受攻擊。

因此，使用Authorization請求頭是一種更安全的做法，並且在前端與後端通訊時是推薦的做法。

前端將token設定到Authorization欄位可以防止跨站請求偽造(CSRF)攻擊。

將token儲存在cookie中，駭客可以透過在相同的域中的惡意網站上傳送請求來獲取並使用該token。例：駭客可以使用跨站請求偽造 (CSRF) 攻擊來獲取並使用令牌。在這種攻擊中，駭客利用惡意網站上的漏洞來向受害者的網站傳送請求，並在請求中包含該令牌。如果受害者已經登入到該網站，並且未採取預防措施，則該請求將被視為有效，併為駭客提供了對受害者賬戶的訪問許可權。為了防止這種攻擊，網站開發人員可以採取一些預防措施。其中之一是在表單或請求中新增一個驗證令牌，該令牌僅在客戶端和伺服器之間傳遞，並用於驗證請求的來源。還可以使用同源策略 (same-origin policy) 來限制網站上的 JavaScript 程式碼只能與來自同一域的網站通訊。

除此之外，使用 HTTPS 也有助於防止 CSRF 攻擊，因為它會加密資料傳輸，並防止攻擊者篡改請求。

另外，設定在請求頭的token更加安全，因為它不會被快取到瀏覽器或代理伺服器的歷史記錄中，並且在透過 HTTPS 傳送的請求中不會被攔截。

一個具體的例子是，當用戶登入成功後，伺服器會返回一個JWT（JSON Web Token）。前端可以將JWT儲存在請求頭的Authorization欄位中。

當前端傳送請求到後端時，將會在請求頭中攜帶有JWT，後端可以根據這個JWT來驗證使用者的身份。如果JWT有效，則後端會返回請求的資料，否則返回錯誤資訊。這樣，後端就不需要再次驗證使用者的身份，因為JWT已經驗證過了。

這樣，前端就可以在每次請求中攜帶JWT，而不需要在每次請求中都將使用者名稱和密碼傳送給後端。這樣既提高了使用者的體驗，又提高了系統的安全性。

總之，將token設定到Authorization欄位中更安全，方便前端管理，保證了客戶端與服務端之間的安全性。

http是無狀態協議，取完資料連線維持30－120秒就就斷掉了，要想確認授權狀態就要在http頭加入authorization欄位

兩種方案：

將 token 放在 cookie 裡；將 token 放在請求頭裡，用 Authorization 欄位。

無論對於前端還是後端而言，這兩種方案都是各有利弊的，下面稍微講幾點，實際開發中根據需求來選用即可。

將 token 放在 cookie 裡：

前端可以完全不寫程式碼，設定 cookie 可以依賴後端的 Set-Cookie 響應頭，同域名的情況下發送所有請求的時候 cookie 也是自動帶上的（也有壞處，這樣經常會造成網路流量和頻寬的浪費，所以 CDN 的域名都是和主站不同的，避免請求帶上 cookie 浪費流量）；

在安全性方面，cookie 可以設定 HttpOnly 來保護 cookie 無法被 JS 程式碼捕獲，避免 XSS 等攻擊，還可以設定 Secure 來確保只在 https 環境下傳輸 token；這些能力由瀏覽器提供，Authorization 無法實現；

但是，cookie 會存在 CSRF 攻擊的問題，雖然瀏覽器廠商在逐步禁止第三方 cookie（似乎推遲到 2024 年了），但是這個問題還是不得不防（如果想使用第三方 cookie，可以在後端響應中設定 cookie 的 SameSite 屬性）；

在一級域名相同的情況下，cookie 可以實現跨子域名互通，比如 a.example.com 和 b.example.com 之間可以實現 cookie 互通（設定 cookie 時提供 Domain=example.com 屬性），這個能力也是 Authorization 不具備的；

網頁中的圖片 <img /> 請求時也會自動帶上 cookie，好處是便於控制網路圖片的訪問許可權，例如網路相簿的許可權控制可以精確到使用者級，這個是 Authorization 做不到的，它必須把 token 放在 url 查詢裡面才行；缺點：如果網頁中的背景圖、icon 等資源圖片放在相同的域名下，每次請求這些資源圖片都會帶上 cookie，很浪費頻寬和伺服器的流量， 所以 CDN 的域名一定要和主域名區分開。

大多數站點為了更好的使用者體驗，都會使用 cookie 來儲存一些使用者的資訊，一些站點是預設啟用的，而一些網站在使用者首次訪問時，會提示使用者是否允許啟用 cookie。因此使用者是可以控制是否使用 cookie 的。cookie 是不支援跨域的，站點 A 訪問站點 B 時， 是不能自動將站點 A 的cookie帶上的。這在公司間的資料介面訪問時，是普遍存在的，這種介面大多都是採用 Authorization header 來實現 auth 認證的。避免 CSRF ( Cross-site request forgery ), 使用者在站點 B上登入了，惡意的網站 A在自己的網站上嵌入了惡意的程式碼，比如偽造了一個領取紅包的按鈕，但是按鈕點選時，卻呼叫的網站的轉賬介面，因為訪問 B時，會自動帶上網站 B的cookie, 如果將授權token，放在cookie中，上面的轉賬請求就變成了合法的請求。

API 不一定僅僅是設計給瀏覽器用的，還可能給非瀏覽器的客戶端使用，非瀏覽器的客戶端表示「cookie 是什麼？」