【認證與授權】JWT(JSON Web Token)簡介

2020/08/01閱讀時間約 5 分鐘

上一個篇章我們有介紹了「【認證與授權】Authentication、Authorization，傻傻分不清楚？」，相信對於兩者個區別已經有一定的認知了，那麼這次的主軸在於介紹Authentication(認證)的其中一個技術JWT(Json Web Token), 為什麼說這項技術很重要?

隨著系統越來越複雜，雲端模式的興起，我們傳統的驗證機制已經無法負荷現今的大量使用情境，因此才衍生出「無狀態」的「令牌」機制，主要讓我們在有限的時間內得到可以通行的「通行證」。

在這段期間內我們是認證通過的狀態，因此可以隨意進出系統，而對於伺服端來說也不用去特別記住來的是誰，只認令牌不認人，看到這邊想必心中難免會有疑惑，這樣不是很危險嗎，的確，單純的通行證當然不行，所以我們才要搭配授權、更新令牌...的機制，這留在我們後面的章節會逐一介紹。

那就讓我們先來了解一下JWT(Json Web Token)這們技術吧！

概念: 有限時間內可使用通行證來要求對應的操作權限。

JWT 的組成內容有三個部分，由 . 做區隔，最後透過這三個部分，串成一個 Jwt 字串

[HEADER].[PAYLOAD].[SIGNATURE]

1. Header:

主要記載認證的方法

{
    "typ": "JWT",
    "alg": "HS256" # 加密的方法(HS384、RS256、ES256...)
}

2. Payload:

這部分可以裝載一些比較不敏感的資訊，通常建議裝載以下資訊(但不強制)。

- iss (Issuer) — jwt簽發者

- sub (Subject) — jwt所面向的用戶

- aud (Audience) — 接收jwt的一方

- exp (Expiration Time) — jwt的過期時間，這個過期時間必須要大於簽發時間

- nbf (Not Before) — 定義在什麼時間之前，該jwt都是不可用的

- iat (Issued At) — jwt的簽發時間

- jti (JWT ID) — jwt的唯一身份標識，主要用來作為一次性token,從而迴避重放攻擊

{
     "displayName": "John Doe",
     "roles": ["$roleId", "roleId", ...]
     "iat": 1516239022,
     "exp": 1516239022
}

我們也可以利用payload來裝載其它的資訊。

3. Signature

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret')

簽名後得到Signature的字串，最後組成為

$base64Str(header).$base64Str(payload).$signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT範例網站

JWT的驗證流程

優點

- 採用JSON的形式，大部分的程式語言皆支援。

- 可存放一些使用者資訊，但並非是敏感的資訊。

- 不用在Server端實做Session機制，特別適合多台Server的情境下，使得擴展性容易，因為多台Server要使用Session的話，會有共享Session的問題產生。

- 因為是透過header夾帶，因此不會有傳統用Cookie進行跨域請求等問題。

缺點

- JWT沒辦法主動被失效，也就是說不能像Session一樣被強制無效，只能等到過期。

如何拿jwt token去存取API?

curl -X GET "http://192.168.1.222:5002/users/me" -H "accept: application/json" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI1ZThkOWUyYWQ0OWU2MzMzOTBiZWExYTgiLCJpYXQiOjE1ODg4MTE0MzksImV4cCI6MTU4ODgxNDQzOX0.LqgFDdMWXf_nYC3a4_wn8WV3BLqXaklwgGjXVRp2i3I"

為什麼會看到廣告