如果你有在用 AWS S3、Google Cloud Storage、Azure Blob Storage 這類雲端儲存服務，或是用 CloudFront 這類 CDN 來放圖片和影片。
那你一定會遇到一個問題：怎麼控制誰可以存取這些檔案？
這篇文章會用最簡單的方式，帶你了解 Signed URL（簽名網址）和 Signed Cookie（簽名 Cookie）這兩個機制。
為什麼需要 Signed URL？
當你把一張圖片上傳到雲端儲存服務後，你會拿到一組 URL（網址）。
這組 URL 就是這張圖片在網路上的地址，而且這個地址永遠不會變。
聽起來很方便，但這其實是一個問題。
因為任何人只要拿到這個連結，就可以一直存取這張圖片，即使你已經不希望別人看到它了。
舉個例子，假設你開發了一個付費課程平台，課程影片放在 S3 上。
如果你用的是固定不變的 URL，那只要有一個人把連結分享出去，所有人都可以免費看影片了。
這就是為什麼我們需要 Signed URL。
Signed URL 的基本概念
Signed URL（簽名網址）是一種經過特殊處理的 URL，它可以讓某個人存取你儲存空間裡的某個檔案，但有時間限制。
時間一到，這個 URL 就會失效，沒辦法再用了。
Instagram 就是一個很好的例子。
如果你在 Instagram 的網頁版上，對一張圖片按右鍵檢查它的網址，你會發現那個 URL 很長、很複雜。
那就是一個 Signed URL。
這代表這個 URL 會根據「是誰在看」而改變，而且過一段時間就會過期。
Signed URL 怎麼產生的？
要產生 Signed URL，你的伺服器需要先準備一組金鑰（Key）。
金鑰其實就是一串很長的隨機字串，由數字和英文字母組成。
電腦會用這串字串做數學運算，來產生「簽名」。
那什麼是簽名？
簽名（Signature）也是一串字串，它是根據「要保護的資訊」（例如圖片網址、過期時間）加上伺服器上的那串秘密字串（也就是金鑰），透過數學運算算出來的結果。
簽名有兩個很重要的特性：
- 獨一無二：只要輸入的資訊或金鑰有一點點不同，算出來的簽名就會完全不一樣。
- 無法偽造：沒有正確的金鑰，就算不出正確的簽名。
所以簽名可以用來證明一件事：「這個 URL 真的是伺服器發出來的，沒有被別人偽造或竄改」。
剛剛說的金鑰，其實叫做「私鑰」
到目前為止，我們一直用「金鑰」這個詞。
其實更精確一點，這把放在伺服器上、用來產生簽名的金鑰，有個正式的名字叫做「私鑰」（Private Key）。
為什麼叫「私」？因為它必須保密，絕對不能外洩給別人。
只要有人拿到你的私鑰，就可以偽造出一模一樣的簽名，整個機制就失效了。
還有另一把，叫做「公鑰」
接下來要說明一個新的概念。
在 Signed URL 的機制裡，金鑰其實是兩把一組、配對使用的。
除了剛剛介紹的「私鑰」，還有另一把叫做「公鑰」（Public Key）。
公鑰也是一串隨機字串。
它不是另外單獨產生的，而是和私鑰一起被算出來、成對出現。
也就是說，當電腦產生一把私鑰的時候，會同時算出一把專屬於這把私鑰的公鑰，兩把一組，互相對應。
這兩把金鑰之間有一個特別的關係：
- 用私鑰產生的簽名，只能用對應的公鑰才能驗證。
- 公鑰沒辦法拿來產生新的簽名，它只能做驗證用。
所以整個機制的分工變成這樣：
- 私鑰（Private Key）：放在你自己的伺服器上，用來「產生簽名」，絕對不能外洩。
- 公鑰（Public Key）：交給雲端儲存服務（例如 AWS S3）保管，用來「驗證簽名」。
為什麼要分成兩把？因為這樣就算公鑰被別人看到也沒關係，它只能驗證簽名，不能產生新的簽名。
真正的安全關鍵在於「私鑰」，只要私鑰沒外洩，別人就沒辦法偽造 Signed URL。
接下來，伺服器會用私鑰，根據以下資訊產生一個獨特的「簽名」（Signature）：
- 圖片的識別碼（哪一張圖片）
- 過期時間（這個 URL 什麼時候失效）
- 其他存取限制（例如只允許特定 IP 存取）
最後，這個簽名會被加到圖片的 URL 後面，變成一個 Signed URL。
當使用者的瀏覽器拿著這個 Signed URL 去跟雲端儲存服務要圖片時，雲端服務會用對應的公鑰來驗證簽名。
如果簽名沒問題，而且還沒過期，就會放行，讓使用者看到圖片。
Signed URL 的完整運作流程
讓我們一步一步來看，從使用者打開網頁到看到圖片，整個流程是怎麼跑的。
第一步：使用者發出請求
使用者在瀏覽器上打開一個頁面，瀏覽器向你的伺服器發出請求。
這個請求可能是要看某一張圖片，也可能是要看一整頁包含很多圖片的頁面。
第二步：伺服器產生 Signed URL
伺服器收到請求後，會判斷這個頁面需要哪些圖片。
然後，伺服器會用私鑰，幫每一張圖片都產生一個 Signed URL。
第三步：Signed URL 回傳給瀏覽器
伺服器把這些 Signed URL 放在回應裡，傳回給使用者的瀏覽器。
第四步：瀏覽器直接向雲端儲存要圖片
瀏覽器拿到 Signed URL 後，會直接用這些 URL 去跟雲端儲存服務（例如 AWS S3 或 CloudFront）要圖片。
注意，這一步是瀏覽器直接跟雲端儲存溝通，不會再經過你的伺服器。
第五步：雲端儲存驗證簽名
雲端儲存服務收到請求後，用公鑰驗證 URL 裡的簽名。
確認簽名有效、沒有過期，就把圖片傳給瀏覽器顯示。
Signed Cookie 是什麼？
了解了 Signed URL 之後，接下來看看 Signed Cookie（簽名 Cookie）。
Signed Cookie 跟 Signed URL 的概念很像，但最大的差別在於：Signed URL 一次只保護一個檔案，而 Signed Cookie 可以一次保護一整批檔案。
例如保護整個資料夾，或是整個網站的某一個區域。
Signed Cookie 的運作方式
Signed Cookie 的原理跟 Signed URL 很像，只是簽名放的位置不同。
Signed URL 是把簽名放在網址裡面。
Signed Cookie 則是把簽名放在 Cookie 裡面，隨著 HTTP 請求一起送出。
具體來說，流程是這樣的：
第一步：伺服器產生簽名 Cookie
伺服器根據「使用者要存取什麼資源」、「存取的規則（Policy）」以及其他參數，產生一個簽名。
這個簽名連同存取規則，一起被包進一個 Cookie 裡面。
第二步：Cookie 傳給瀏覽器
伺服器把這個 Cookie 傳給使用者的瀏覽器，瀏覽器會自動儲存起來。
第三步：瀏覽器自動帶上 Cookie
之後，每當使用者要存取受保護的資源時，瀏覽器會自動把這個 Cookie 附在請求裡一起送出。
使用者不需要做任何事，瀏覽器會自己處理。
第四步：伺服器驗證 Cookie
伺服器收到請求後，會檢查 Cookie 裡的簽名和存取規則，決定要不要讓這個使用者存取。
什麼時候用 Signed URL？什麼時候用 Signed Cookie？
這兩個機制各有各的適用場景，選錯工具的話，實作起來會很麻煩。
適合用 Signed URL 的情境：
- 你只需要保護單一檔案，例如一張圖片、一部影片。
- 你想要更精細的控制，例如針對每個檔案設定不同的過期時間或存取條件。
適合用 Signed Cookie 的情境：
- 你需要保護一整批檔案，例如一整個資料夾的內容。
- 你想提供某個區域的臨時存取權限，例如付費會員專區。
當然，這兩個機制也可以同時使用，來達到更高的安全性。
小結
- 雲端儲存的固定 URL 會有安全風險，因為任何人拿到連結就能一直存取。
- Signed URL 透過簽名機制，讓 URL 有時間限制，適合保護單一檔案。
- 簽名的產生靠的是一對金鑰：私鑰在伺服器上產生簽名，公鑰在雲端服務上驗證簽名。
- Signed Cookie 把簽名放在 Cookie 裡，適合一次保護一整批檔案或整個網站區域。
- 依照你的需求選擇合適的方式，也可以兩者搭配使用。