OAuth 2.0 กับ Authorization Code Grant

Keycloak 26.7.2      # image quay.io/keycloak/keycloak:26.7 (tag นี้ตอนนี้ชี้ไป 26.7.2)
Docker client 29.6.2 / server 29.5.2   # ผ่าน colima ไม่ใช่ Docker Desktop
docker-compose 5.3.1 # เครื่องนี้ใช้ `docker-compose` (มีขีด) ไม่ใช่ `docker compose`
curl 8.13.0
go1.26.5 darwin/arm64 + github.com/gin-gonic/gin v1.12.0   # ใช้เฉพาะหัวข้อ 6 ตอนทำ callback server

1 · ปัญหาที่ OAuth เกิดมาเพื่อแก้

สมมติ Wongnok อยากมีฟีเจอร์ "ดึงรูปโปรไฟล์กับอีเมลจากบัญชี Google ของคุณมาใช้ตอนสมัคร"
ถ้าไม่มี OAuth วิธีเดียวที่ทำได้คือ ทำช่องสองช่องบนเว็บเรา แล้วขออีเมลกับรหัสผ่านของ Google จากผู้ใช้ตรง ๆ แล้วเราเอาไปล็อกอินแทนเขา
วิธีนี้มีชื่อเรียกในวงการว่า password anti-pattern และมันแย่ทุกทางพร้อมกันสี่ทาง

แย่ข้อ 1 — เราเห็นรหัสผ่านของเขา

ไม่ใช่ "อาจจะเห็น" แต่คือเห็นแน่นอน เพราะค่ามันวิ่งผ่านเซิร์ฟเวอร์เรา
ใน บทเรียน 49 เราพิสูจน์ไปแล้วกับ Basic Auth ว่ารหัสผ่านที่ส่งมาแบบนั้น ไม่ได้เข้ารหัส แค่ base64 ใครดัก header ได้ก็อ่านได้ทันทีโดยไม่ต้องมีกุญแจอะไรเลย:

Authorization: Basic c29tY2hhaTpwQHNzdzByZA==

# decode กลับได้ทันทีโดยไม่ต้องมี key:
somchai:p@ssw0rd

พอเราเห็นรหัสผ่าน เราก็กลายเป็นที่เก็บรหัสผ่านของ Google เพิ่มขึ้นอีกที่หนึ่ง ทั้งที่เราไม่ได้อยากรับผิดชอบเรื่องนี้เลย · แล้ววันที่ฐานข้อมูลเราหลุด รหัสผ่าน Google ของผู้ใช้ก็หลุดตามไปด้วย

แย่ข้อ 2 — จำกัดขอบเขตไม่ได้

เราอยากได้แค่ "ชื่อกับอีเมล" แต่รหัสผ่านที่ได้มาเปิดได้ทุกอย่าง — Gmail ทั้งกล่อง · Google Drive ทั้งไดรฟ์ · ปฏิทิน · YouTube · การตั้งค่าบัญชี
รหัสผ่านไม่มีช่องให้เขียนว่า "ใช้ได้แค่เรื่องนี้" มันเป็นสวิตช์เปิด-ปิดตัวเดียวที่คุมทุกอย่าง

แย่ข้อ 3 — ถอนสิทธิ์ทีหลังไม่ได้

วันหนึ่งผู้ใช้เลิกใช้ Wongnok แล้วอยากตัดสิทธิ์เรา — เขาทำยังไง?
ทางเดียวคือไปเปลี่ยนรหัสผ่าน Google ซึ่งแปลว่า...

แย่ข้อ 4 — เปลี่ยนรหัสผ่านทีเดียว พังหมดทุกที่

...ทุกเว็บที่เขาเคยให้รหัสผ่านไว้พังพร้อมกันหมด ไม่ใช่แค่ Wongnok
และในทางกลับกัน ถ้าเราอยาก "จำ" ให้เขา เราต้องเก็บรหัสผ่านไว้ในรูปที่เอากลับมาใช้ได้ แปลว่าเราเก็บแบบ hash ไม่ได้ ต้องเก็บแบบถอดกลับได้ ซึ่งแย่ยิ่งกว่าเดิม

2 · ตัวละครสี่ตัว

ก่อนอ่าน flow ต้องรู้จักตัวละครก่อน ไม่งั้นจะงงว่าใครส่งอะไรให้ใคร
OAuth 2.0 กำหนดบทบาทไว้ สี่บทบาท (RFC 6749 §1.1) และเกือบทุกคนที่งง OAuth งงเพราะแยกสี่ตัวนี้ไม่ออก:

3 · Authorization Code Grant ทีละขั้น

ชื่อยาว ๆ นี้แปลได้ว่า "วิธีขอสิทธิ์แบบเอารหัสชั่วคราวมาแลก" — grant แปลว่า "วิธีที่ client ใช้ขอ token" · authorization code คือรหัสชั่วคราวที่ Authorization Server ส่งกลับมาแทน token (ย้ำว่าไม่ใช่รหัสผ่าน และไม่ใช่ token — เป็นแค่ตั๋วไว้ไปแลก)
นี่คือภาพรวมทั้งรอบ ตัวเลขในวงเล็บคือค่าจริงที่ผมรันได้ (ย่อบางส่วนให้พอดีจอ):

4 · คำถามใหญ่ของบทนี้ — ทำไมต้องมี code คั่นกลาง

มาถึงจุดที่ผมอยากให้คิดจริง ๆ ก่อนอ่านต่อ
ดู flow ข้างบนแล้วมันดูอ้อมมาก: ขั้นที่ [6] Keycloak รู้แล้วว่าผู้ใช้เป็นใครและอนุญาตแล้ว มันจะส่ง access_token กลับมาใน URL เลยก็ได้ จบใน 6 ขั้น ไม่ต้องมีขั้น [8] ให้เมื่อยเลย

HTTP/1.1 302 Found
Location: http://localhost:3000/callback?access_token=eyJhbGciOiJSUzI1NiI…

$ cat gin-access.log
[GIN] 2026/08/22 - 11:38:44 | 200 |  2.458µs |       127.0.0.1 | GET      "/callback
  ?state=st-3c715c27cc5d
  &session_state=lG20JnTV9jXGYuYSn9cTF4hw
  &iss=http%3A%2F%2Flocalhost%3A8081%2Frealms%2Fwongnok
  &code=76a08add-6f8c-79b1-af2a-39097022f3d5.lG20JnTV9jXGYuYSn9cTF4hw.dc8e45a5-…"

5 · เดินของจริงทีละคำสั่ง

ตรงนี้คือของจริงทั้งหมด — ผมใช้ curl แสดงบทเป็น browser (เก็บ cookie ไว้ในไฟล์ แล้ว POST ฟอร์ม login เอง) เพื่อให้เห็น HTTP ทุกบรรทัดที่ปกติ browser ซ่อนไว้

ขั้น [2] — พา browser ไปหา Authorization Server

$ curl -s -c cookies.txt -o login.html -w "HTTP %{http_code}  content-type=%{content_type}  bytes=%{size_download}\n" \
  "http://localhost:8081/realms/wongnok/protocol/openid-connect/auth\
?response_type=code\
&client_id=wongnok-web\
&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback\
&scope=openid%20profile%20email\
&state=xyz-997d202f5a9a1f92"

HTTP 200  content-type=text/html;charset=utf-8  bytes=6837

ได้ หน้า HTML ของ Keycloak กลับมา 6837 byte — คือหน้า login นั่นเอง
สังเกตพารามิเตอร์ห้าตัวที่ส่งไป มันคือ "ใบคำขอ" ที่บอกครบว่า ใครขอ · ขออะไร · ให้ส่งกลับที่ไหน:

ขั้น [4] — ผู้ใช้กรอกรหัสผ่านที่บ้านของ Keycloak

ในหน้า HTML ที่ได้มามี <form id="kc-form-login" action="…"> อยู่ ผมดึง action ออกมาแล้ว POST ไปตรง ๆ เหมือนที่ browser ทำเวลาผู้ใช้กดปุ่ม Sign In:

# ดึง action ของฟอร์มออกมาก่อน (นี่คือสิ่งที่ browser ทำให้เราตอนกดปุ่ม)
$ ACTION=$(grep -o 'id="kc-form-login"[^>]*action="[^"]*"' login.html \
    | sed -n 's/.*action="\([^"]*\)".*/\1/p' | sed 's/&/\&/g')

$ curl -s -b cookies.txt -c cookies.txt -o /dev/null -D headers.txt -X POST "$ACTION" \
    --data-urlencode "username=chef1" \
    --data-urlencode "password=chef1234"

$ grep -i '^HTTP/\|^location:' headers.txt
HTTP/1.1 302 Found
Location: http://localhost:3000/callback
    ?state=xyz-997d202f5a9a1f92
    &session_state=y92Kwwzlv0CgQdv64G400Txv
    &iss=http%3A%2F%2Flocalhost%3A8081%2Frealms%2Fwongnok
    &code=9016d08d-9cd2-a75a-7e34-58bbba3815d6.y92Kwwzlv0CgQdv64G400Txv.dc8e45a5-9139-48de-bbdf-a0398af573bb

รหัสผ่าน chef1234 ถูกส่งไปที่ localhost:8081 ซึ่งคือ Keycloak — ไม่ได้ผ่านเว็บเราที่ localhost:3000 เลยแม้แต่นิดเดียว นี่คือหัวใจของ delegated authorization
และสิ่งที่กลับมาคือ code ยาว 98 ตัวอักษร ไม่มีคำว่า access_token อยู่ในบรรทัดนี้เลย

ขั้น [8] — เอา code ไปแลก token ทาง back channel

# ดึง code ออกจากบรรทัด Location ที่เพิ่งได้มา
$ CODE=$(grep -i '^location:' headers.txt \
    | sed -n 's/.*[?&]code=\([^&]*\).*/\1/p' | tr -d '\r')

$ curl -s -X POST "http://localhost:8081/realms/wongnok/protocol/openid-connect/token" \
    -d grant_type=authorization_code \
    -d client_id=wongnok-web \
    -d client_secret=web-secret-123 \
    -d redirect_uri=http://localhost:3000/callback \
    --data-urlencode "code=$CODE"

HTTP 200
access_token       = eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwi... [len 1377]
expires_in         = 300
refresh_expires_in = 1800
refresh_token      = eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwi... [len 694]
token_type         = Bearer
id_token           = eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwi... [len 1067]
not-before-policy  = 0
session_state      = y92Kwwzlv0CgQdv64G400Txv
scope              = openid email profile

สังเกตสามอย่าง:
· เป็น POST และค่าทุกตัวอยู่ใน body ไม่ใช่ query string — code กับ client_secret จึงไม่ไปโผล่ใน access log ของใครทั้งนั้น
· expires_in = 300 คือ access token อยู่ได้ 5 นาที (ค่า default ของ Keycloak 26.7 · ไม่ใช่ 1 ชั่วโมงตามที่หลายคนจำ)
· ได้ id_token แถมมาด้วยเพราะเราขอ scope=openid — ตัวนี้เป็นของ OpenID Connect ไม่ใช่ OAuth แกน

นี่คือ payload ของ access_token ที่ได้จริง (แกะ base64 ส่วนกลางออกมา):

{
  "iss": "http://localhost:8081/realms/wongnok",
  "aud": "account",
  "sub": "7d93f608-bcc4-4d06-b082-8b0553a4777a",
  "typ": "Bearer",
  "azp": "wongnok-web",
  "scope": "openid email profile",
  "preferred_username": "chef1",
  "email": "chef1@wongnok.dev"
}
// header alg = RS256 · exp - iat = 300 วินาที

สี่ด่านที่ทำให้ code ที่หลุดไปไร้ประโยชน์

ทั้งสี่เคสนี้ผมยิงจริงทีละเคส ใช้ code ที่เพิ่งได้มาสด ๆ ทุกครั้ง:

# A) ไม่ส่ง client_secret เลย (เหมือน attacker ที่ขโมย code จาก log ไป)
{"error":"unauthorized_client","error_description":"Invalid client or Invalid client credentials"}
HTTP 401

# B) ส่ง client_secret ที่เดามั่ว
{"error":"unauthorized_client","error_description":"Invalid client or Invalid client credentials"}
HTTP 401

# C) redirect_uri ไม่ตรงกับตอนขอ (ขอไว้ /callback แต่มาแลกด้วย /evil)
{"error":"invalid_grant","error_description":"Incorrect redirect_uri"}
HTTP 400

# D) เอา code เดิมมาแลกซ้ำเป็นครั้งที่สอง
{"error":"invalid_grant","error_description":"Code not valid"}
HTTP 400

ฝั่ง Keycloak ก็จดเหตุผลไว้ในล็อกของมันด้วย บรรทัดนี้ของเคส C อธิบายชัดที่สุด:

type="CODE_TO_TOKEN_ERROR" realmName="wongnok" clientId="wongnok-web"
  error="invalid_redirect_uri"
  reason="Parameter 'redirect_uri' did not match originally saved redirect URI
          used in initial OIDC request. Saved redirectUri: http://localhost:3000/callback,
          redirectUri parameter: http://localhost:3000/evil"
  grant_type="authorization_code" client_auth_method="client-secret"

แล้วเรื่อง "หมดอายุใน 60 วินาที" ผมก็วัดจริง — ค่าที่ตั้งอยู่ใน realm อ่านได้จาก admin API:

accessCodeLifespan  = 60   วินาที   # อายุของ authorization code
accessTokenLifespan = 300  วินาที   # อายุของ access token

# ขอ code มาแล้วนั่งรอ 65 วินาที ค่อยเอาไปแลก:
{"error":"invalid_grant","error_description":"Code not valid"}
HTTP 400

บทพิสูจน์ว่า token ไม่เคยผ่าน browser จริง ๆ

หลังรันครบทุกเคส ผม grep หาคำว่า access_token ในทุกอย่างที่ browser มองเห็น:

Location header ทั้งหมดที่ Keycloak ส่งกลับมา = 3 อัน
  บรรทัดที่มีคำว่า access_token = 0

access log ของเว็บเราเอง (gin-access.log)
  บรรทัดที่มีคำว่า access_token = 0
  บรรทัดที่มีคำว่า code=        = 2

ศูนย์ — ไม่ใช่ "น้อย" แต่คือไม่มีเลย
ทุกใบของ access_token เกิดขึ้นในขั้น [8] ซึ่งเป็น server-to-server ล้วน ๆ

6 · state — พารามิเตอร์ที่ดูไร้สาระที่สุด แต่ตัดออกไม่ได้

state คือค่าสุ่มที่ client สร้างเอง ส่งไปกับใบคำขอในขั้น [2] แล้ว Authorization Server จะส่งกลับมาเหมือนเดิมเป๊ะ ๆ ในขั้น [6]
ฟังดูเหมือนของไร้ประโยชน์ — ส่งไปแล้วได้กลับมาเท่าเดิม จะมีไว้ทำไม

# การทดลอง 1: ส่ง state ที่ไม่ได้สุ่มเลย เดาง่ายสุด ๆ
&state=AAAA-not-random-1234

# การทดลอง 2: ไม่ส่ง state เข้าไปเลยสักตัว
(ตัดพารามิเตอร์ state ออกจาก URL ทั้งอัน)

# การทดลอง 1 — ส่ง state ที่เดาง่ายมาก
Location = http://localhost:3000/callback?state=AAAA-not-random-1234&session_state=…
ได้ code มาด้วยไหม = True

# การทดลอง 2 — ไม่ส่ง state เลย
HTTP/1.1 302 Found
Location: http://localhost:3000/callback
    ?session_state=8yUy2W06g5Hh6A2FeXqObSrQ
    &iss=http%3A%2F%2Flocalhost%3A8081%2Frealms%2Fwongnok
    &code=0d9e8ae3-2129-e1be-9fcb-f5f70dad4ca7.…     ← ได้ code ปกติ ไม่มีคำเตือนอะไรเลย

แล้ว state กันอะไร

กัน CSRF (Cross-Site Request Forgery) — การโจมตีที่ attacker หลอกให้ browser ของเหยื่อยิง request ที่ attacker เป็นคนแต่งขึ้น
ในบริบทของ OAuth มันมีหน้าตาแบบนี้ ซึ่งกลับหัวจากที่คนส่วนใหญ่คิด:

RFC 6749 §10.12 อธิบายเรื่องนี้ไว้ตรง ๆ ว่า CSRF ที่ redirection URI ทำให้ attacker "inject its own authorization code or access token" ได้ และสรุปเป็นข้อบังคับว่า "The client MUST implement CSRF protection for its redirection URI" โดยแนะนำให้ทำผ่านพารามิเตอร์ state

วิธีที่ถูกต้องมีสามบรรทัด และต้องครบทั้งสาม:

หน้าตาในโค้ด Go

สามบรรทัดข้างบนแปลเป็น Go ได้สั้นมาก — ที่สำคัญคือใช้ crypto/rand ไม่ใช่ math/rand เพราะ math/rand เดาลำดับถัดไปได้ถ้ารู้ค่าก่อนหน้า
ข้างล่างนี้เป็นไฟล์เต็ม ๆ ไม่ใช่เศษโค้ด — ก๊อปทั้งก้อนไปวางเป็น main.go แล้ว go run main.go ได้เลย (ใช้แต่ของใน standard library จึงไม่ต้องมี go.mod และไม่ต้อง go get อะไรเลย):

// state/main.go
package main

import (
	"crypto/rand"
	"crypto/subtle"
	"encoding/base64"
	"fmt"
)

// [1] สุ่ม — เรียกก่อนพา browser ไปหา Authorization Server
func newState() string {
	b := make([]byte, 32)
	rand.Read(b) // doc ของ crypto/rand.Read เขียนว่า "It never returns an error"
	return base64.RawURLEncoding.EncodeToString(b)
}

// [3] เทียบ — เรียกตอน callback ก่อนเอา code ไปแลก
func sameState(a, b string) bool {
	return subtle.ConstantTimeCompare([]byte(a), []byte(b)) == 1
}

// main() มีไว้ให้เห็นผลเท่านั้น — ของจริงเรียกสองฟังก์ชันข้างบนจาก handler
func main() {
	saved := newState() // ขั้น [1] สุ่มแล้วเก็บลง session ของผู้ใช้คนนี้
	fmt.Println("state ที่สุ่มได้ =", saved)
	fmt.Println("ความยาว =", len(saved), "ตัวอักษร")
	fmt.Println("สุ่มอีกรอบ =", newState())
	fmt.Println()
	fmt.Println("callback ส่งค่าเดิมกลับมา   -> sameState =", sameState(saved, saved))
	fmt.Println("callback ส่งค่าอื่นกลับมา   -> sameState =", sameState(saved, newState()))
	fmt.Println("callback ไม่ส่ง state กลับมา -> sameState =", sameState(saved, ""))
}

ผมก๊อปไฟล์นี้ไปวางในโฟลเดอร์เปล่า ๆ แล้วรันจริง ได้แบบนี้:

$ go run main.go
state ที่สุ่มได้ = 6YGcX2cU5S2uyIM7BF3tqImtqK3CLJY978uKvaQlOUA
ความยาว = 43 ตัวอักษร
สุ่มอีกรอบ = i596gzZwOl6c3gROb9tJPrlcsTj5tYPMhGAYVbkYLdQ

callback ส่งค่าเดิมกลับมา   -> sameState = true
callback ส่งค่าอื่นกลับมา   -> sameState = false
callback ไม่ส่ง state กลับมา -> sameState = false

# ค่าสุ่มของคุณจะไม่ตรงกับของผมแน่นอน — ที่ต้องตรงคือ 43 กับ true/false สามบรรทัดล่าง

สังเกตบรรทัดสุดท้าย: ถ้า callback ไม่มี state ติดมาเลย (ซึ่งคือสิ่งที่ลิงก์ปลอมของ attacker เป็น) sameState ก็คืน false ให้เอง — ตราบใดที่โค้ดคุณเรียกมัน จริง ๆ
ส่วน subtle.ConstantTimeCompare ใช้แทน a == b เพราะการเทียบ string ปกติ จะหยุดทันทีที่เจอตัวอักษรต่างกัน ทำให้เวลาที่ใช้บอกใบ้ได้ว่าเดาถูกไปกี่ตัวแล้ว — เป็นนิสัยที่ควรติดไว้กับทุกค่าลับ ไม่ใช่แค่ state

7 · scope กับหน้า consent

scope คือรายการสิทธิ์ที่ client ขอ เขียนเป็นคำ ๆ คั่นด้วยช่องว่าง
นี่คือส่วนที่ทำให้คำว่า "จำกัดขอบเขต" ในสไลด์หน้า 35 มีความหมายจริง — รหัสผ่านเปิดได้ทุกอย่าง แต่ token เปิดได้แค่ที่เขียนไว้ใน scope

พอ client ขอ scope มา Authorization Server ก็เอาไปแปลงเป็นภาษาคนแล้วถามเจ้าของบัญชี นี่คือข้อความจริงบนหน้า consent ของ Keycloak ที่ผมเปิดใช้แล้วรันจนเห็น:

Grant Access to Wongnok Web
Do you grant these access privileges?
  · Email address        ← มาจาก scope "email"
  · User roles           ← มาจาก scope "roles"
  · User profile         ← มาจาก scope "profile"
[ Yes ]   [ No ]

และถ้าผู้ใช้กด No — ผมกดจริงแล้วได้แบบนี้:

HTTP/1.1 302 Found
Location: http://localhost:3000/callback?error=access_denied&state=consent-demo&iss=…

ไม่มี code กลับมา มีแต่ error=access_denied — นี่คือเคสที่โค้ดฝั่ง callback ของเราต้องรองรับด้วย ไม่ใช่สมมติว่าจะได้ code เสมอ

กับดักที่ต้องรู้: scope ที่ขอ ≠ scope ที่ได้

ผมลองขอแค่ scope=openid อย่างเดียว แล้วดูว่า token ที่ได้มีอะไรบ้าง:

# ขอไป:      scope=openid
# ได้กลับมา:  scope = openid email profile     ← ได้เกินที่ขอ!
claim เกี่ยวกับตัวตนที่ติดมาใน id_token ทั้งที่ขอแค่ openid =
    sub, preferred_username, name, given_name, family_name, email, email_verified
# (id_token ก้อนนี้มี claim ทั้งหมด 18 ตัว ที่เหลือเป็นของระบบ เช่น iss, aud, exp, iat, jti, sid, typ, azp, acr, at_hash, auth_time)

สาเหตุอยู่ที่ Keycloak แบ่ง scope เป็นสองกอง และกองแรกใส่ให้เองทุกครั้งไม่ว่าจะขอหรือไม่:

และถ้าขอ scope ที่ไม่มีอยู่จริง มันจะไม่เงียบ:

# ขอ scope=openid banana
Location: http://localhost:3000/callback
    ?error=invalid_scope&error_description=Invalid+scopes%3A+openid+banana&state=sc-bad&iss=…

8 · กลับไปดูข้อ "ถอนสิทธิ์ไม่ได้" อีกที

หัวข้อ 1 บอกว่าปัญหาข้อ 3 ของ password anti-pattern คือถอนสิทธิ์ไม่ได้ ผมทดสอบว่า OAuth แก้ได้จริงไหม — เดิน flow จนได้ refresh_token มา แล้วยิงไปที่ revocation endpoint ของ Keycloak (นี่คือปุ่ม "ถอนสิทธิ์" ในรูปแบบ HTTP):

1) มี refresh_token อยู่ในมือ (len=694)

2) ลอง refresh ครั้งแรก:
   HTTP 200  keys = ['access_token', 'expires_in', 'refresh_expires_in', 'refresh_token',
                     'token_type', 'id_token', 'not-before-policy', 'session_state', 'scope']

3) ผู้ใช้กด "ถอนสิทธิ์" → POST /realms/wongnok/protocol/openid-connect/revoke
   HTTP 200

4) ลอง refresh อีกครั้งหลังถอนสิทธิ์:
   {"error":"invalid_grant","error_description":"Session not active"}
   HTTP 400

5) รหัสผ่านของ chef1 ยังใช้ล็อกอินได้เหมือนเดิมไหม:
   ล็อกอินใหม่แล้วได้ code ยาว 98 ตัวอักษร → ยังล็อกอินได้ปกติ ไม่ต้องเปลี่ยนรหัสผ่าน

9 · แล้ว grant แบบอื่นล่ะ ทำไมต้องเป็น Authorization Code

OAuth 2.0 (RFC 6749, ปี 2012) นิยาม grant ไว้หลายแบบ และสองแบบในนั้นถูกเลิกแนะนำไปแล้ว — ตรงนี้สำคัญเพราะ tutorial เก่า ๆ ในอินเทอร์เน็ตยังสอนสองตัวนั้นอยู่เยอะมาก

อ้างอิงตรงตัวสำหรับข้ออ้างเรื่อง OAuth 2.1

ข้ออ้างว่า "OAuth 2.1 ตัด Implicit กับ Password grant ออก" ไม่ควรเชื่อเพราะมีคนพูดต่อ ๆ กันมา
เอกสารตัวจริงคือ draft-ietf-oauth-v2-1-15 (The OAuth 2.1 Authorization Framework · Hardt, Parecki, Lodderstedt · 2 มีนาคม 2026)
ในหัวข้อ 10 มีบรรทัดพวกนี้อยู่ตรงตัว:

*  The Implicit grant (response_type=token) is omitted from this
   specification as per Section 2.1.2 of [RFC9700]

*  The Resource Owner Password Credentials grant is omitted from this
   specification as per Section 2.4 of [RFC9700]

   [... ตัด bullet อีก 4 ข้อออก — bearer token ใน query string, refresh token
    ของ public client, redirect_uri ที่ token endpoint, client credentials ใน request body ...]

10.1.  Removal of the OAuth 2.0 Implicit grant

   The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was
   deprecated in [RFC9700].

   The intent of removing the Implicit grant is to no longer issue
   access tokens in the authorization response, as such tokens are
   vulnerable to leakage and injection, and are unable to be sender-
   constrained to a client.

และ RFC 9700 (Best Current Practice for OAuth 2.0 Security · BCP 240 · มกราคม 2025) ที่ถูกอ้างถึงนั้น §2.4 เขียนไว้แรงกว่านั้นอีก:

2.4.  Resource Owner Password Credentials Grant

   The resource owner password credentials grant [RFC6749] MUST NOT be
   used.  This grant type insecurely exposes the credentials of the
   resource owner to the client.

ผมลองขอแบบ Implicit ดูจริง ๆ

ตอนสร้าง client wongnok-web ผมตั้ง implicitFlowEnabled: false ไว้ตั้งแต่แรก พอลองขอ response_type=token ได้ผลแบบนี้:

HTTP/1.1 302 Found
Location: http://localhost:3000/callback#error=unauthorized_client
    &error_description=Client+is+not+allowed+to+initiate+browser+login+with+given
      +response_type.+Implicit+flow+is+disabled+for+the+client.
    &state=s5&iss=…

สังเกตตัวอักษรตัวเดียวที่สำคัญมาก: # ไม่ใช่ ?
Implicit flow ตอบกลับทาง URL fragment (ส่วนหลัง #) ไม่ใช่ query string และfragment ไม่ถูกส่งไปหาเซิร์ฟเวอร์ — browser ตัดทิ้งก่อนยิง request
แปลว่าถ้าเป็น Implicit จริง ๆ token จะไม่โผล่ใน access log ของเรา (ต่างจาก code ที่โผล่) แต่มันจะไปโผล่ในประวัติ browser และโค้ด JavaScript ทุกตัวบนหน้านั้นอ่านได้ ซึ่งคือสิ่งที่ RFC 9700 §4.3.2 พูดถึงพอดี

10 · สรุปทั้งบทเป็นตารางเดียว

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

ก. ไม่มี client_secret  -> HTTP 401  {"error":"unauthorized_client",
                              "error_description":"Invalid client or Invalid client credentials"}
ข. client_secret มั่ว    -> HTTP 401  {"error":"unauthorized_client", …ข้อความเดียวกันเป๊ะ}
ค. redirect_uri ไม่ตรง   -> HTTP 400  {"error":"invalid_grant",
                              "error_description":"Incorrect redirect_uri"}

11 · บทถัดไป

อ้างอิง

• RFC 6749 — The OAuth 2.0 Authorization Framework — ต้นฉบับของทุกอย่างในบทนี้ · อ่านสามหัวข้อนี้พอ: §1.1 (บทบาททั้งสี่) · §4.1 (Authorization Code Grant ทีละขั้น) · §10.12 (CSRF กับ state)
  ประโยคที่ควรจำจาก §4.1.2: "The client MUST NOT use the authorization code more than once" และ "A maximum authorization code lifetime of 10 minutes is RECOMMENDED"
• RFC 9700 — Best Current Practice for OAuth 2.0 Security (BCP 240 · มกราคม 2025) — เอกสารที่บอกว่าอะไรเลิกใช้แล้วและเพราะอะไร
  §2.1.2 Implicit Grant · §2.4 Resource Owner Password Credentials Grant (ที่เขียนว่า MUST NOT be used) · §4.3.1 Authorization Code in Browser History · §4.3.2 Access Token in Browser History
• draft-ietf-oauth-v2-1 — The OAuth 2.1 Authorization Framework — ฉบับที่ผมอ้างในบทนี้คือ -15 (2 มีนาคม 2026) · อ่าน §1.8 กับ §10 ซึ่งเป็นที่มาของประโยคว่า Implicit และ Password grant ถูก omitted ออกไป
  ⚠️ ยังเป็น Internet-Draft ไม่ใช่ RFC — เลขฉบับเปลี่ยนได้ ให้เข้าหน้านี้แล้วกดฉบับล่าสุดเสมอ
• RFC 6750 — Bearer Token Usage — ที่มาของ header Authorization: Bearer <token> ในขั้น [10]
• RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification — ที่มาของพารามิเตอร์ iss ที่ Keycloak แถมกลับมาใน callback
• Keycloak — OpenID Connect endpoints — รายชื่อ endpoint ทั้งหมดที่บทนี้ยิง (auth, token, revoke)
• บทเรียน 43 — API Detective Workshop — หลักฐานว่า query string ลง access log ที่หัวข้อ 4 อ้างถึง (เคส POST /createUser?name=Alice&password=123456)
• บทเรียน 49 — จาก Basic Auth ถึง JWT — ที่มาของหลักฐานว่า Basic c29tY2hhaTpwQHNzdzByZA== decode กลับได้โดยไม่ต้องมีกุญแจ