จาก Basic Auth ถึง JWT

go version go1.26.5 darwin/arm64
github.com/golang-jwt/jwt/v5 v5.3.1
openssl / base64 ของ macOS   # ใช้ตอนถอด token ด้วยมือ
swag v1.16.4                 # ใช้เฉพาะหัวข้อ 9 (Swagger)

1 · Authentication ต่างจาก Authorization ยังไง

สองคำนี้ขึ้นต้นด้วย Auth เหมือนกัน ย่อเหมือนกันว่า "auth" และคนใช้ปนกันตลอด
แต่มันตอบคนละคำถาม และเกิดคนละเวลา:

ทั้งบทนี้อยู่ฝั่ง authentication ล้วน ๆ — เรากำลังหาวิธีที่ดีที่สุดที่เซิร์ฟเวอร์จะรู้ว่า request ที่วิ่งเข้ามาเป็นของใคร
ส่วน authorization (เช็คว่า role นี้ทำอะไรได้) เป็นเรื่องของบทถัดไป แต่มันจะโผล่มาแวบหนึ่งในหัวข้อ 5 ตอนที่เราเห็นคำว่า "admin":true อยู่ใน token

2 · Basic Auth ทำงานยังไง

Basic Auth คือวิธีล็อกอินที่เก่าที่สุดของ HTTP กติกาสั้นมาก:
ทุก request ที่ยิงไปหาเซิร์ฟเวอร์ ให้แนบ header ชื่อ Authorization ที่มีหน้าตาแบบนี้

Authorization: Basic <base64 ของสตริง "username:password">

คำว่า "ทุก request" ในประโยคข้างบนคือหัวใจของทั้งบท — ไม่ใช่แค่ตอนล็อกอินครั้งแรก แต่คือทุกครั้ง ที่คุยกับเซิร์ฟเวอร์
ผมเขียนเซิร์ฟเวอร์เล็ก ๆ ด้วย httptest (เซิร์ฟเวอร์จำลองที่รันอยู่ในหน่วยความจำ ไม่ต้องเปิดพอร์ตจริง — รายละเอียดอยู่ในบทเรียน 40) ที่พิมพ์ header ทุกอันที่ได้รับ แล้วให้ client ยิงไปสามครั้งด้วย req.SetBasicAuth("somchai", "p@ssw0rd"):

req, _ := http.NewRequest("GET", url+"/foods", nil)
req.SetBasicAuth("somchai", "p@ssw0rd")   // ฝั่ง client — ใส่ header ให้
res, err := http.DefaultClient.Do(req)

// ---- ฝั่ง server ----
user, pass, ok := r.BasicAuth()               // แกะ header กลับมาเป็น user/pass

ผลรันจริง — ดูค่า Authorization ของทั้งสาม request ให้ดี:

$ go run ./cmd/basic

>>> request #1
[server] GET /foods  Authorization: "Basic c29tY2hhaTpwQHNzdzByZA=="
[server] r.BasicAuth() -> user="somchai" pass="p@ssw0rd" ok=true
[client] status=200 body=hello somchai

>>> request #2
[server] GET /foods  Authorization: "Basic c29tY2hhaTpwQHNzdzByZA=="
[server] r.BasicAuth() -> user="somchai" pass="p@ssw0rd" ok=true
[client] status=200 body=hello somchai

>>> request #3
[server] GET /foods  Authorization: "Basic c29tY2hhaTpwQHNzdzByZA=="
[server] r.BasicAuth() -> user="somchai" pass="p@ssw0rd" ok=true
[client] status=200 body=hello somchai

สตริงเดิมเป๊ะ ๆ ถูกส่งซ้ำทั้งสามครั้ง — ไม่มี session ไม่มี cookie ไม่มีอะไรจำ เซิร์ฟเวอร์ไม่รู้จักคุณเลยจนกว่าคุณจะบอกใหม่ทุกครั้ง
แปลว่ารหัสผ่านของคุณเดินทางข้ามเน็ตเวิร์กทุก request ตลอดอายุการใช้งานแอป ไม่ใช่แค่ตอนล็อกอิน

และเวลารหัสผิด เซิร์ฟเวอร์ตอบแบบนี้ — สังเกต header WWW-Authenticate ที่พูดถึงในหัวข้อ 1:

>>> request รหัสผิด
[server] GET /foods  Authorization: "Basic c29tY2hhaTp3cm9uZw=="
[server] r.BasicAuth() -> user="somchai" pass="wrong" ok=true
[client] status=401 WWW-Authenticate="Basic realm=\"wongnok\"" body=unauthorized

user, pass, ok := r.BasicAuth()
if ok {                       // ❌ ช่องโหว่เต็ม ๆ — ok ไม่ได้แปลว่ารหัสถูก
    // ให้ผ่าน
}

user, pass, ok := r.BasicAuth()
okUser := subtle.ConstantTimeCompare([]byte(user), []byte("somchai")) == 1
okPass := subtle.ConstantTimeCompare([]byte(pass), []byte("p@ssw0rd")) == 1
if !ok || !okUser || !okPass {
    w.Header().Set("WWW-Authenticate", `Basic realm="wongnok"`)
    w.WriteHeader(http.StatusUnauthorized)   // 401
    return
}

3 · base64 ไม่ใช่การเข้ารหัส

สไลด์เขียนไว้ตรง ๆ ว่า "Base64 ไม่ใช่การเข้ารหัส — ถอดกลับได้ง่ายมาก" แต่พูดเฉย ๆ ไม่พอ ต้องเห็นด้วยตา
ก่อนอื่นนิยามให้ชัด: base64 คือวิธีเขียนข้อมูลใหม่ให้เหลือแค่ตัวอักษร 64 ตัว (A–Z a–z 0–9 + /) เกิดมาเพื่อให้ข้อมูลที่มีอักขระแปลก ๆ เดินทางผ่าน HTTP header ได้ปลอดภัย
มันไม่ต้องใช้กุญแจ ไม่มีความลับอะไรในตัวมันเลย — ใครก็แปลงกลับได้

Authorization: Basic c29tY2hhaTpwQHNzdzByZA==

$ printf '%s' 'somchai:p@ssw0rd' | base64
c29tY2hhaTpwQHNzdzByZA==

$ echo 'c29tY2hhaTpwQHNzdzByZA==' | base64 -d
somchai:p@ssw0rd

Authorization: Basic c29tY2hhaTpwQHNzdzByZA==  (45 byte ทั้ง header)
decode กลับได้ทันทีโดยไม่ต้องมี key: somchai:p@ssw0rd

4 · ทำไม Basic Auth ไม่เหมาะกับระบบจริง

สไลด์ลิสต์ไว้สี่ข้อ ผมจะอธิบายทีละข้อว่าทำไมมันเป็นปัญหาจริง ไม่ใช่แค่ข้อเสียบนกระดาษ
และทั้งสี่ข้อมีต้นเหตุเดียวกัน ซึ่งเห็นได้จากสิ่งที่เรา decode มาแล้วในหัวข้อ 3:

Basic: somchai:p@ssw0rd            // ทั้งหมดที่ header ตัวนี้บอกได้ มีแค่ 2 field

1 · ไม่มีวันหมดอายุ

ดูสตริงข้างบนอีกรอบ — ไม่มีที่ไหนให้ใส่วันหมดอายุเลย มันมีแค่ชื่อกับรหัส คั่นด้วย : จบ
ผลคือ header ที่หลุดออกไปวันนี้ ยังใช้ได้พรุ่งนี้ · สัปดาห์หน้า · ปีหน้า ตราบใดที่รหัสผ่านยังไม่ถูกเปลี่ยน
เทียบกับบัตรเข้าออฟฟิศแบบชั่วคราวที่หมดอายุเอง 6 โมงเย็น — Basic Auth ไม่มีกลไกแบบนั้นให้ใช้

2 · Revoke ยาก

Revoke แปลว่า "ยกเลิกสิทธิ์ที่ให้ไปแล้ว" เช่นพนักงานลาออก หรือรู้ตัวว่ารหัสหลุด แล้วอยากตัดการเข้าถึงทันที
ปัญหาคือสิ่งเดียวที่ใช้ยืนยันตัวตนได้คือรหัสผ่าน ดังนั้นวิธีเดียวที่จะยกเลิกคือ เปลี่ยนรหัสผ่าน
ซึ่งลากทุกอย่างของคน ๆ นั้นไปด้วยหมด: มือถือ · แล็ปท็อป · script ที่ตั้งไว้ · CI · ตัดขาดทุกเครื่องพร้อมกัน ทั้งที่คุณอยากตัดแค่เครื่องที่หาย
ในระบบที่ออกแบบมาดี คุณควรจะ "เตะเครื่องนี้ออกเครื่องเดียว" ได้ — Basic Auth ทำไม่ได้เลย

3 · ไม่มี claims

Claim (อ่านว่า เคลม) แปลตรงตัวว่า "ข้อกล่าวอ้าง" — ในโลก auth หมายถึงข้อมูลชิ้นหนึ่งที่ token กล่าวอ้างเกี่ยวกับผู้ถือ เช่น "คนนี้ id 42" · "คนนี้เป็น admin" · "ใบนี้หมดอายุ 6 โมงเย็น"
ลองเทียบสิ่งที่ Basic Auth บอกได้ กับสิ่งที่ JWT บอกได้ (ทั้งสองบรรทัดนี้ผม decode มาจากของจริง):

Basic: somchai:p@ssw0rd            // มีแค่ 2 field ไม่มี exp ไม่มี role
JWT  : {"sub":"1234567890","name":"John Doe","admin":true,"iat":1516239022}

บรรทัดล่างบอกได้ว่า เป็นใคร · ชื่ออะไร · เป็น admin ไหม · ออกให้เมื่อไร ทั้งหมดนี้อยู่ในตัว token เอง
บรรทัดบนบอกได้แค่ชื่อกับรหัส — เซิร์ฟเวอร์จึงไม่มีทางรู้อะไรมากกว่านั้น นอกจากไปถามฐานข้อมูล ซึ่งพาเราไปสู่ข้อสุดท้ายพอดี

4 · ต้องเช็ค DB ทุก request

เพราะ header ไม่มีข้อมูลอะไรที่เชื่อถือได้เลย ทุก request เซิร์ฟเวอร์จึงต้อง:
1. เอา username ไปหาแถวในตาราง users → 2. เอา password ที่ได้มาเข้าฟังก์ชัน hash แล้วเทียบกับที่เก็บไว้ → 3. ค่อยตัดสินใจ
ข้อ 2 คือตัวปัญหา — ฟังก์ชัน hash รหัสผ่านที่ใช้กันจริง (เช่น bcrypt) ถูกออกแบบมาให้ช้าโดยตั้งใจ เพื่อกันคนไล่เดารหัส
ปกติจึงจงใจตั้งให้ใช้เวลาระดับหลักสิบถึงร้อยมิลลิวินาทีต่อครั้ง ซึ่งดีมากตอนล็อกอินวันละครั้ง แต่ถ้าต้องทำทุก request คุณเพิ่งแปะเวลานั้นลงบนทุกการกดปุ่มของผู้ใช้ และ CPU ของเซิร์ฟเวอร์ก็หมดไปกับการ hash แทนที่จะไปทำงานจริง

5 · JWT คืออะไร — ถอดของจริงในสไลด์ให้ดู

JWT ย่อมาจาก JSON Web Token (คนส่วนใหญ่อ่านว่า "จ็อต") คือสตริงยาว ๆ ก้อนหนึ่งที่ประกอบด้วย สามส่วนคั่นด้วยจุด:

header . payload . signature

สองส่วนแรกเป็นแค่ JSON ที่เอาไปเขียนด้วย base64url (base64 รุ่นที่เปลี่ยน + เป็น - และ / เป็น _ เพื่อให้ใส่ใน URL ได้ และมักตัด = ท้ายทิ้ง)
ย้ำอีกครั้งจากหัวข้อ 3: base64 ไม่ใช่การเข้ารหัส — ซึ่งแปลว่าเรื่องที่กำลังจะเกิดขึ้นข้างล่างนี้เป็นเรื่องปกติ ไม่ใช่การแฮ็ก

// ส่วนที่ 1 — header
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
// ส่วนที่ 2 — payload
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
// ส่วนที่ 3 — signature
KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

$ echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' | tr '_-' '/+' | base64 -d
{"alg":"HS256","typ":"JWT"}

$ echo 'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0=' \
    | tr '_-' '/+' | base64 -d
{"sub":"1234567890","name":"John Doe","admin":true,"iat":1516239022}

claims := jwt.MapClaims{}
tok, parts, err := jwt.NewParser().ParseUnverified(demo, claims)

=== 1) ParseUnverified (ไม่ส่ง secret เข้าไปเลย) ===
err=<nil>
alg=HS256 typ=JWT
claims=map[admin:true iat:1.516239022e+09 name:John Doe sub:1234567890]
จำนวนส่วนของ token=3

$ echo 'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0' | tr '_-' '/+' | base64 -d
{"sub":"1234567890","name":"John Doe","admin":true,"iat":151623902     ← หายไป 2 ตัว!

$ echo $?
0                                ← exit code บอกว่าสำเร็จ

secret ของ token ตัวนี้ไม่ใช่ค่าที่คนส่วนใหญ่เขียนกัน

token ตัวข้างบนเป็นตัวอย่าง default ของเว็บ jwt.io ซึ่งคนก๊อปไปใช้กันทั้งโลก และตำราเก่าเกือบทุกเล่มบอกว่า secret ของมันคือ "your-256-bit-secret"
ผมลองแล้วไม่ผ่าน — ผมคำนวณ HMAC ด้วย openssl ตรง ๆ เทียบกับ signature ในสไลด์:

$ SIGNING=<header>.<payload>
$ printf '%s' "$SIGNING" | openssl dgst -sha256 -hmac "$s" -binary \
    | base64 | tr '+/' '-_' | tr -d '='

your-256-bit-secret                      reGQzG3OKdoIMWLDKOZ4TICJit3EW69cQE72E2CfzRE
a-string-secret-at-least-256-bits-long   KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30
target:                                  KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

ยืนยันซ้ำด้วย jwt.Parse ของ golang-jwt/jwt/v5 v5.3.1:

=== 2) ลอง secret หลายตัวกับ token ของ jwt.io ===
secret="your-256-bit-secret"                      -> FAIL: token signature is invalid: signature is invalid
secret="secret"                                   -> FAIL: token signature is invalid: signature is invalid
secret="a-string-secret-at-least-256-bits-long"   -> OK (signature ผ่าน)

6 · สร้างและ verify JWT ด้วย golang-jwt/jwt/v5

สไลด์หน้า 33 บอกแค่บรรทัดเดียวว่าให้ลง library ตัวไหน:

$ go get github.com/golang-jwt/jwt/v5
go: added github.com/golang-jwt/jwt/v5 v5.3.1

โค้ดสร้าง token มีแค่สองบรรทัดจริง ๆ — ที่เหลือคือการเตรียม claims
ข้างล่างนี้คือ cmd/mine/main.go ฉบับย่อ (ตัดเหลือเฉพาะส่วนที่ 3 กับ 3b) แต่เป็นไฟล์เต็มที่ก๊อปทั้งก้อนไปวางแล้ว go run ได้เลย — มีทั้งบรรทัด package และ import ครบ ไม่ต้องเติมอะไรเพิ่ม:

// cmd/mine/main.go
package main

import (
    "fmt"
    "time"

    "github.com/golang-jwt/jwt/v5"
)

var secret = []byte("a-string-secret-at-least-256-bits-long")

func keyfunc(t *jwt.Token) (any, error) { return secret, nil } // ใช้ตอน parse ในหัวข้อถัดไป

func main() {
    now := time.Now()
    mine := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
        "sub":  "42",                        // subject = ผู้ใช้คนนี้เป็นใคร
        "name": "somchai",
        "role": "admin",
        "iat":  now.Unix(),                 // issued at = ออกให้เมื่อไร
        "exp":  now.Add(time.Hour).Unix(), // expires = หมดอายุเมื่อไร
    })
    s, err := mine.SignedString(secret)      // secret เป็น []byte

    fmt.Println("=== 3) สร้าง JWT เอง (HS256) ===")
    fmt.Println("SignedString err =", err)
    fmt.Println("token =", s)
    fmt.Println("len   =", len(s))
}

ผลรันจริง:

=== 3) สร้าง JWT เอง (HS256) ===
SignedString err = <nil>
token = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODczNzI0MjksImlhdCI6MTc4NzM2ODgyOSwibmFtZSI6InNvbWNoYWkiLCJyb2xlIjoiYWRtaW4iLCJzdWIiOiI0MiJ9.1JpaiixbPQRhCTZEcNwFMJbEZSJVVw6xej3cSqg_nSc
len   = 185   # 185 ตัวอักษร = 185 byte เพราะ JWT เป็น ASCII ล้วน

ฝั่งตรวจ ใช้ jwt.Parse ซึ่งขอสองอย่าง: ฟังก์ชันที่คืน key (เรียกว่า keyfunc) และ รายชื่อ alg ที่เรายอมรับ
keyfunc เราประกาศไว้ในไฟล์ข้างบนแล้ว เหลือแค่เติมบรรทัดพวกนี้ต่อท้าย main() (ก้อนนี้เป็นส่วนที่เติมเข้าไป ไม่ใช่ไฟล์เดี่ยว ๆ — ไม่ต้องใส่ package/import ซ้ำ):

    back, err := jwt.Parse(s, keyfunc, jwt.WithValidMethods([]string{"HS256"}))

    fmt.Println("\n--- 3b) parse กลับ + verify ---")
    if err != nil {
        fmt.Println("FAIL", err)
        return
    }
    c := back.Claims.(jwt.MapClaims)
    fmt.Printf("OK  valid=%v claims=%v\n", back.Valid, c)
    fmt.Printf("ชนิดจริงของ c[\"exp\"] = %T\n", c["exp"])
    fmt.Printf("ชนิดจริงของ c[\"sub\"] = %T\n", c["sub"])

--- 3b) parse กลับ + verify ---
OK  valid=true claims=map[exp:1.787372429e+09 iat:1.787368829e+09 name:somchai role:admin sub:42]
ชนิดจริงของ c["exp"] = float64
ชนิดจริงของ c["sub"] = string

c := back.Claims.(jwt.MapClaims)

// สองบรรทัดนี้เป็น "ตัวเลือก" ให้เทียบกัน — เอาไปใช้จริงให้เลือกบรรทัดเดียว
exp := c["exp"].(int)              // ❌ panic: interface conversion: interface {} is float64, not int
exp := int64(c["exp"].(float64))   // ✅ ถูกต้อง

7 · สามเคสที่ token ใช้ไม่ได้ — พร้อม error จริง

ทั้งสามเคสข้างล่างผมรันด้วยฟังก์ชันตัวเดียวกัน คือ jwt.Parse(tokenStr, keyfunc, jwt.WithValidMethods([]string{"HS256"})) แล้วพิมพ์ทั้งข้อความ error และผลของ errors.Is สามตัวออกมาเทียบกัน

7.1 · token หมดอายุ

--- 4.1 token หมดอายุ (exp ผ่านไป 1 ชม.) ---
err  = token has invalid claims: token is expired
errors.Is(err, jwt.ErrTokenExpired)          = true
errors.Is(err, jwt.ErrSignatureInvalid)      = false
errors.Is(err, jwt.ErrTokenSignatureInvalid) = false
valid= false

7.2 · signature ผิด (แก้ token ไปหนึ่งตัวอักษร)

(แก้ตัวอักษรสุดท้าย "c" -> "Q")
--- 4.2 signature ผิด ---
err  = token signature is invalid: signature is invalid
errors.Is(err, jwt.ErrTokenExpired)          = false
errors.Is(err, jwt.ErrSignatureInvalid)      = true
errors.Is(err, jwt.ErrTokenSignatureInvalid) = true
valid= false

แก้แค่ตัวอักษรเดียวจาก 185 ตัวก็พังทันที — นี่คือหลักฐานว่า signature ทำหน้าที่ของมันจริง: มันกันการแก้ไข (แต่ยังไม่ได้กันการอ่าน ตามที่พิสูจน์ไปในหัวข้อ 5)

7.3 · alg ไม่ตรงกับที่เรายอมรับ

--- 4.3 alg ไม่ตรง (token=HS256 แต่ยอมรับแค่ RS256) ---
err  = token signature is invalid: signing method HS256 is invalid
errors.Is(err, jwt.ErrTokenExpired)          = false
errors.Is(err, jwt.ErrSignatureInvalid)      = false
errors.Is(err, jwt.ErrTokenSignatureInvalid) = true

7.4 · เคสที่สไลด์ไม่ได้พูด แต่เจอบ่อยกว่า

ผมรันเพิ่มอีกชุด เพราะสามเคสข้างบนยังไม่ครบกับที่เจอจริงตอน debug:

$ go run ./cmd/extra

nbf อยู่อนาคต (ยังใช้ไม่ได้)                         err = token has invalid claims: token is not valid yet
aud ไม่ตรง (คาด mobile-app)                          err = token has invalid claims: token has invalid audience
iss ไม่ตรง (token มี iss=evil, คาด wongnok)          err = token has invalid claims: token has invalid issuer
iss ไม่มีเลย + WithIssuer()                          err = token has invalid claims: token is missing required claim: iss claim is required
token มีแค่ 2 ส่วน (ตัด signature ทิ้ง)              err = token is malformed: token contains an invalid number of segments
token เป็นข้อความมั่ว                                err = token is malformed: token contains an invalid number of segments
token ว่าง                                           err = token is malformed: token contains an invalid number of segments

สังเกตสองอย่างจากผลรัน: token ว่าง · token มั่ว · token ขาดส่วน ได้ error เดียวกันหมด คือ invalid number of segments — ดังนั้นถ้าเจอ error นี้อย่าไปไล่หา secret ให้เสียเวลา ปัญหาอยู่ที่ตัว token ไม่ครบสามส่วน (สาเหตุยอดฮิต: ลืมตัดคำว่า "Bearer " ออกจาก header ก่อนส่งเข้า jwt.Parse)
อีกอย่าง: สังเกตสองบรรทัด iss ให้ดี — jwt.WithIssuer("wongnok") ทำงานสองหน้าที่ในตัวเดียว และให้ error คนละตัวกัน:
· ถ้า token มี iss แต่ค่าไม่ตรง → token has invalid issuer (jwt.ErrTokenInvalidIssuer)
· ถ้า token ไม่มี iss เลย → token is missing required claim: iss claim is required (jwt.ErrTokenRequiredClaimMissing) เพราะการใส่ WithIssuer() ทำให้ iss กลายเป็น claim ที่บังคับต้องมีไปด้วยเลย
ถ้าคุณเจอ invalid issuer แปลว่า token มี iss อยู่แล้ว — ไปไล่ดูว่าใครออก token ให้ ไม่ใช่ไปไล่ดูว่าลืมใส่ claim

token ไม่มี exp เลย (default)                        err = <nil>
token ไม่มี exp + WithExpirationRequired()           err = token has invalid claims: token is missing required claim: exp claim is required

หมดอายุ 20 วิ (default ไม่มี leeway)                 err = token has invalid claims: token is expired
หมดอายุ 20 วิ + WithLeeway(60s)                      err = <nil>

8 · การโจมตี alg=none และเหตุผลที่ต้องระบุ alg ตอน parse

ย้อนกลับไปดู header ของ JWT: {"alg":"HS256","typ":"JWT"}
ช่องนี้อยู่ในตัว token ซึ่งแปลว่าผู้โจมตีเป็นคนเขียนเองได้ — แล้วถ้าเขาเขียนว่า "alg":"none" ล่ะ?
มาตรฐาน JWT มีค่า none อยู่จริง หมายถึง "token นี้ไม่มีลายเซ็น" ซึ่งถ้าเซิร์ฟเวอร์เชื่อตามนั้น ก็เท่ากับให้ผู้โจมตีพิมพ์บัตรผ่านของตัวเองได้เลย

สร้าง token ปลอมแบบนี้ง่ายมาก ไม่ต้องมี library ด้วยซ้ำ — แค่ base64 สองก้อนแล้วปิดท้ายด้วยจุดเปล่า:

evil := b64(`{"alg":"none","typ":"JWT"}`) + "." +
        b64(`{"role":"admin","sub":"42"}`) + "."   // ← ส่วนที่ 3 ว่างเปล่า

$ go run ./cmd/algnone

=== 5) alg=none attack ===
evil token = eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJyb2xlIjoiYWRtaW4iLCJzdWIiOiI0MiJ9.

A) มี WithValidMethods([HS256]) -> err = token signature is invalid: signing method none is invalid
B) ไม่มี WithValidMethods    -> err = token signature is invalid: token is unverifiable: 'none' signature type is not allowed
C) คืน UnsafeAllowNoneSignatureType -> err = <nil>

algorithm confusion — เอา public key มาเซ็นแบบ HS256

Algorithm confusion คือการที่ผู้โจมตีสลับชนิดของอัลกอริทึมเพื่อหลอกให้เซิร์ฟเวอร์ เอาของที่เปิดเผยได้ มาใช้เป็นความลับ
ไอเดียคือ: ถ้าเซิร์ฟเวอร์ตั้งใจใช้ RS256 (private key เซ็น / public key ตรวจ) แล้ว public key เป็นของสาธารณะ ใครก็โหลดได้
ผู้โจมตีก็เอา public key นั้นมาใช้เป็น "secret" ของ HS256 แล้วเซ็น token เอง — ถ้าเซิร์ฟเวอร์ไม่ได้ล็อก alg ไว้ มันจะหยิบ public key ตัวเดียวกันมาตรวจ แล้วก็ตรงกันพอดี

จุดที่ต้องเห็นให้ชัดคือ "เอา public key รูปแบบไหนมาใช้เป็น secret" — ในโปรแกรมนี้ผมใช้ PEM ทั้งก้อน (ตัวเดียวกับที่เซิร์ฟเวอร์เอาไปแปะไว้ให้โหลด) ฝั่งผู้โจมตีมีแค่สามบรรทัด:
(โปรแกรมสุ่ม RSA key ใหม่ทุกครั้งที่รัน ตัว token ที่คุณได้เลยไม่เหมือนข้างล่าง — แต่สองบรรทัด error จะออกมาเหมือนกันเป๊ะ)

der, _ := x509.MarshalPKIXPublicKey(pub)                                  // public key → DER
pubPEM := pem.EncodeToMemory(&pem.Block{Type: "PUBLIC KEY", Bytes: der}) // DER → PEM
s, err := jwt.NewWithClaims(jwt.SigningMethodHS256, claims).SignedString(pubPEM)

$ go run ./cmd/confusion

attacker เซ็น HS256 ด้วย public key: err=<nil>
token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiYWRtaW4iLCJzdWIiOiI0MiJ9.BTBZcWv8rupZ27-xkP_c6coRiTpy4nT6fwb23UrkOo4

A) ไม่มี WithValidMethods -> err = token signature is invalid: key is of invalid type: HMAC verify expects []byte
B) มี WithValidMethods([RS256]) -> err = token signature is invalid: signing method HS256 is invalid

9 · บอก Swagger ว่า endpoint นี้ต้องใช้ JWT

สไลด์หน้า 34 เขียนสั้น ๆ ว่า "เพิ่ม Swagger annotation เกี่ยวกับ Security Definition เพื่อระบุการใช้งาน JWT"
ของชิ้นนี้เราทำไปแล้วใน บทเรียน 41 ตอนนี้แค่มาดูอีกครั้งว่ามันเชื่อมกับ JWT ตรงไหน — มันทำงานเป็นคู่ สองจุด ขาดจุดใดจุดหนึ่งก็ไม่เกิดผล

จุดที่ 1 — ประกาศ "วิธีล็อกอิน" ไว้เหนือ func main() มีที่เดียวในทั้งโปรเจกต์:

//	@securityDefinitions.apikey	BearerAuth
//	@in							header
//	@name						Authorization
//	@description				ใส่ค่าเป็น "Bearer {token}"
func main() { ... }

จุดที่ 2 — ติดป้ายบน handler ที่ต้องล็อกอิน (ใส่เฉพาะตัวที่ต้องการ):

//	@Security		BearerAuth
//	@Router			/users/{id} [get]
func (handler *Handler) FindByID(ctx *gin.Context) { ... }

สั่ง swag init (v1.16.4) แล้วเปิด docs/swagger.json ดู จะได้สองก้อนนี้คนละที่:

// ระดับเอกสาร มาจากจุดที่ 1
"securityDefinitions": {
  "BearerAuth": {
    "description": "ใส่ค่าเป็น \"Bearer {token}\"",
    "type": "apiKey",
    "name": "Authorization",
    "in": "header"
  }
}

// ระดับ endpoint มาจากจุดที่ 2 (อยู่ใต้ paths./users/{id}.get)
"security": [ { "BearerAuth": [] } ]

ผลที่เห็นบนหน้าจอ: มีปุ่ม Authorize มุมขวาบน · endpoint ที่ต้องล็อกอินมีรูปกุญแจ · ใส่ token ครั้งเดียวแล้วกด Try it out ได้ทุกอันโดยไม่ต้องเปิด Postman

10 · JWT ไม่ได้ดีกว่าทุกเรื่อง

ก่อนจบบท ต้องบอกฝั่งที่แลกมาด้วย ไม่งั้นคุณจะเอา JWT ไปใช้ผิดที่
อย่างแรกคือขนาด — JWT พก claims ไว้ในตัว แปลว่ามันใหญ่กว่า session id มาก และมันเดินทางไปกับทุก request เหมือน Basic Auth เป๊ะ ผมวัดมาให้ดู
สามก้อนที่เอามาวัดคือ claims พวกนี้ (cmd/size เซ็นทั้งสามก้อนด้วย HS256 เหมือนกันหมด):

minimal := jwt.MapClaims{"sub": "42", "exp": exp}

typical := jwt.MapClaims{
    "sub": "42", "name": "somchai", "role": "admin",
    "iss": "wongnok", "iat": now.Unix(), "exp": exp,
}

fat := jwt.MapClaims{
    "sub": "42", "name": "สมชาย ใจดี", "iss": "wongnok",
    "roles": []string{"admin", "editor", "reviewer"},
    "perms": []string{"food:read", "food:write", "food:delete"},
    "iat": now.Unix(), "exp": exp,
}

$ go run ./cmd/size

แบบ                              byte  ตัวอย่าง
JWT minimal (sub+exp)             120  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODczNzcxNDIsInN1YiI6IjQyIn0.XJ3SsW28hIV-mK16uXjbmZJUApKMs1X11wvM6_OM2W4
JWT typical (6 claims)            207  (ตัด token ออก)
JWT fat (roles+perms+ชื่อไทย)     331  (ตัด token ออก)
session id 128-bit hex             32  954aa83869ba92dfb8c586b374c221e3
session id 256-bit b64url          43  syv3gevNPL5wqDBV7Z-J0zGCYrBegP_3_W101-LKLGE

header ที่ส่งจริง Authorization: Bearer <typical> = 229 byte
header ที่ส่งจริง Cookie: sid=<hex>              = 44 byte
typical JWT ใหญ่กว่า session hex = 6.5 เท่า
fat JWT ใหญ่กว่า session hex     = 10.3 เท่า

ถ้าคุณรันเอง exp/iat กับ session id จะเป็นค่าอื่น แต่ตัวเลข byte จะเท่ากันเป๊ะ เพราะ unix timestamp ยาว 10 หลักเท่ากันทุกครั้ง และ signature ของ HS256 ยาว 43 ตัวอักษรเสมอ

ตัวที่บวมที่สุดคือ token ที่ยัด roles + perms + ชื่อภาษาไทย
เหตุผลเรื่องภาษาไทยคือจำนวนไบต์ ไม่ใช่การ escape — encoding/json ของ Go ไม่แปลงอักษรไทยเป็น \uXXXX (มัน escape แค่ < > & และตัวคั่นบรรทัดพิเศษ U+2028/U+2029) payload จึงเก็บภาษาไทยเป็น UTF-8 ดิบ ๆ อ่านออกได้ตรง ๆ ตอน decode
แต่อักษรไทยหนึ่งตัวกิน 3 ไบต์ ใน UTF-8 (ASCII กินตัวละ 1 ไบต์) แล้ว base64 ยังขยายอีก 4/3 เท่า → ชื่อไทยหนึ่งตัวกลายเป็น 4 ตัวอักษร ใน token ขณะที่ตัวอักษรอังกฤษสามตัวถึงจะกินที่เท่ากัน
ส่วนอย่างที่สองที่หนักกว่าเรื่องขนาด: JWT ที่ออกไปแล้ว เรียกคืนไม่ได้
เพราะจุดขายทั้งหมดของมันคือ "เซิร์ฟเวอร์ตรวจได้เองโดยไม่ต้องถาม DB" — ซึ่งแปลว่าเซิร์ฟเวอร์ก็ไม่รู้เหมือนกันว่ามีใครถูกแบนไปแล้ว
ถ้าผู้ใช้ถูกไล่ออกตอน 10 โมง แต่ token ของเขาหมดอายุ 11 โมง เขายังใช้งานได้อีกชั่วโมงเต็ม

ทดสอบความเข้าใจ

evil token = eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJyb2xlIjoiYWRtaW4iLCJzdWIiOiI0MiJ9.

A) มี WithValidMethods([HS256]) -> err = token signature is invalid: signing method none is invalid
B) ไม่มี WithValidMethods    -> err = token signature is invalid: token is unverifiable: 'none' signature type is not allowed
C) คืน UnsafeAllowNoneSignatureType -> err = <nil>

อ้างอิง

• pkg.go.dev — http.Request.BasicAuth — สังเกตว่า doc ไม่ได้อธิบายความหมายของ ok ไว้เลยสักคำ — มันเขียนแค่ว่าคืน username/password ที่ request "provides" มาใน header เท่านั้น · นั่นแหละคือกับดักในหัวข้อ 2: ok บอกว่าแกะ header ได้ ไม่ได้บอกว่ารหัสผ่านถูก
• pkg.go.dev — subtle.ConstantTimeCompare — ทำไมการเทียบรหัสผ่านด้วย == ธรรมดาถึงรั่วข้อมูลออกทางเวลาที่ใช้ตอบ
• RFC 7519 — JSON Web Token — อ่านหัวข้อ 4.1 ซึ่งเป็นรายชื่อ registered claims ทั้งเจ็ด (iss sub aud exp nbf iat jti) พร้อมนิยามทีละตัว
• RFC 7515 §4.1.1 — header alg · RFC 8725 — JWT Best Current Practices — RFC 8725 คือฉบับที่ควรอ่านที่สุดในลิสต์นี้ เขียนตรง ๆ ว่าต้องล็อกรายชื่อ alg ที่ยอมรับ และห้ามเชื่อ alg ที่มาจากตัว token
• pkg.go.dev — golang-jwt/jwt/v5 — รายชื่อ ParserOption ทั้งหมด (WithValidMethods · WithExpirationRequired · WithLeeway · WithAudience · WithIssuer) และค่า default ของแต่ละตัว
• golang-jwt — errors.go — ในไฟล์นี้มีแค่ ErrTokenSignatureInvalid (บรรทัด 15 — ไฟล์นี้ประกาศ error ไว้ 16 ตัวรวด บรรทัด 10–25 เช่น ErrTokenInvalidIssuer ที่เจอในหัวข้อ 7.4) · ส่วน ErrSignatureInvalid ไม่ได้อยู่ที่นี่ — มันอยู่ใน hmac.go บรรทัด 21 เพราะเป็น error เฉพาะของ SigningMethodHMAC · นี่คือเหตุผลจริงที่หัวข้อ 7.3 ได้ false: เคส alg ไม่ตรงถูกปฏิเสธก่อนถึงตัวตรวจ HMAC จึงไม่มีทางได้ error ตัวนี้เลย
• MDN — 401 Unauthorized · 403 Forbidden — หน้า 401 เขียนไว้เองว่าชื่อนี้หมายถึง "unauthenticated" ตามที่บทนี้บอกในหัวข้อ 1
• บทเรียน 41 — Swagger & swaggo — ที่มาของ annotation ทั้งชุดในหัวข้อ 9 · Swagger 2.0 Specification — ดูว่า securityDefinitions รองรับ type อะไรบ้าง (และทำไมไม่มี http)