JWT認證方式目前已被廣泛使用，一直以來我們将token放在請求頭中的Authorization中，若通過此種方式，一旦token被惡意竊取，攻擊者可肆意對使用者可通路資源進行任意索取，我們大多都是通過登入成功後，響應AccessToken，然後由前端将token存儲在相關Storage中，然後每次将其放請求頭而認證請求，由于token是極其敏感資訊，是以我們不能将其交由前端去處理，而應由背景擷取對前端不可見。對安全有較高要求的平台，我們通過Http Only Cookie來解決token惡意竊取問題
Http Only Cookie簡言之則是将相關資訊響應時存儲在Cookie中，而用戶端腳本無法通路，每次請求時，則将自動攜帶所有資訊到伺服器。例如，京東存儲相關資訊
接下來我們看看在.NET Core中如何将AccessToken以Http Only方式存儲在Cookie中
如上，我們模拟登入成功，并不傳回AccessToken，而是将其寫入到響應頭中，上述Cookie選項HttpOnly為true即表示用戶端腳本不可通路
此時我們來通路如下需認證接口
用過JWT的童鞋都知道，标準模式則是将AccessToken寫入到Authorization中，即請求頭【Authorization: Bearer ......】，那麼上述是如何認證成功而請求到接口的呢？當我們添加JWT認證時，每次請求在其對應事件OnMessageReceived中将自動擷取請求頭Authorization中的值，将其指派給context.Token
你問我是怎麼知道的，我是猜的嗎，當然不是，丢出官方源碼就知道了，直接找到JWT如何處理認證則一目了然
到這裡我們知道了自動擷取Token的原理，我們修改了Token存儲方式，照葫蘆畫瓢就好，如此将覆寫預設标準模式，如下：
從分析自動擷取Token原理，我們也可知道，若與第三方對接，依然可以使用請求頭Authorization标準模式認證，因為Cookie為空，再次擷取Authorization值。注意：發現若将前端未置于wwwroot下，即完全前後分離，涉及到跨域的情況下，比如使用的是axios封裝請求，那麼應該必須在請求頭中添加【withCredentials:true 】，否則使用Http Only将無效，出現401
額外意外發現一個很有意思的問題，未深入研究，這裡當做小知識了解下就好，或許是我自以為發現新大陸了呢。
當我們建立AccessToken時，都會設定一個過期時間，我們知道此過期時間肯定不會設定過長，但是若在比如移動端微信小程式中，若設定時間不長，必然要考慮重新整理Token問題，為了懶一點，我們将Token設定為永不過期，那麼JWT支援嗎？
當然支援，隻不過根據我剛好嘗試了幾次，找到了JWT永不過期的上限，最大隻能是16年，若超過此臨界點，比如17年，如下：
将會出現401，具體錯誤如下：
好了，本節我們暫時讨論到這裡，再會啦~~~~
所有的選擇不過是為了下一次選擇做準備