前言

很多前後分離專案的認證一路都是 JWT：後台管理員登入後拿到 Token，之後每個請求都帶 Authorization: Bearer ...。
用久了容易有個錯覺，好像 ASP.NET Core 的認證就只有 JWT 這條路。

其實不是。ASP.NET Core 的認證系統是可插拔的 Scheme 架構，JWT 只是其中一種掛上去的 Scheme。
這次剛好有個需求可以拿來示範：ERP 廠商要打我們的 API，但他們不是「會登入的使用者」，給不了帳密，也不適合走 JWT 換 Token 那一套。
這種機器對機器、長期有效的靜態金鑰，用 API Key 才對。

這篇想做兩件事：

1. 說明框架不是只能 JWT，同一個專案裡同時跑好幾種認證方式很正常。
2. 把我自己寫的這版實作記下來。網路上 API Key 的文章不少，但很多不是繞太遠，就是沒講清楚怎麼跟既有 JWT 並存而不打架，這版盡量寫得好懂一點。

前言

前後端分離寫久了，總會遇到那個熟悉的紅字：

Access to fetch at 'https://api.example.com' from origin 'https://www.example.com'
has been blocked by CORS policy.

前端工程師看到這行，第一反應通常是轉頭問後端：「你 CORS 開了沒？」
後端工程師則是一臉無辜：「我本機明明可以啊。」

問題就在這裡：CORS 是瀏覽器的安全機制，本機用 Postman、Swagger 打都不會擋，
只有真的從另一個網域用瀏覽器發請求才會觸發。所以「我本機可以」這句話在 CORS 面前完全沒意義。

這篇就把 ASP.NET Core 的 CORS 設定一次講清楚，並把它封裝成一個擴充方法，
搭配設定檔的允許清單，讓 Program.cs 只剩乾淨的一行。

前言

JWT 大家都在用，但「怎麼產生」這件事其實有不只一種寫法。

早期我手刻過一版——自己組 header、payload，自己做 Base64Url 編碼，自己用 HMACSHA256 算簽名。
能動是能動，但每次要加個 claim、換個演算法都得回去改一堆字串拼接，心裡總是毛毛的。

後來改用套件，又面臨一個選擇題：
要用微軟官方的 Microsoft.IdentityModel，還是社群很受歡迎的 jwt-dotnet？

這篇就把這兩套放在一起比。重點是它們在我的專案裡實作的是同一份介面 IJsonWebTokenService，
所以可以靠 DI 一行切換引擎，呼叫端完全無感。