Keycloak — Authorization Server ที่รันเอง

quay.io/keycloak/keycloak:26.7      # tag ลอย · ตอนที่ผมรันมันชี้ไป 26.7.2
Keycloak 26.7.2 on JVM (powered by Quarkus 3.33.3.1)
Docker  client 29.6.2 · server 29.5.2   # รันผ่าน colima ไม่ใช่ Docker Desktop
docker-compose v5.3.1                   # เรียกด้วยขีดกลาง (เหตุผลอยู่ในกล่องเตือนหัวข้อ 4)
go version go1.26.5 darwin/arm64        # ใช้ตอนพิสูจน์ verify ลายเซ็นในหัวข้อ 7

1 · Keycloak คืออะไร

หน้าปกของสไลด์เขียนไว้สี่บรรทัด ผมยกมาทั้งหมดเพราะทุกคำมีความหมาย:

ก่อนไปต่อ ต้องแยกสองคำนี้ให้ขาดก่อน เพราะทั้งบทนี้วางอยู่บนมัน:

Identity and Access Management (IAM) คือระบบที่ดูแลทั้งสองเรื่องรวมกัน — เก็บบัญชีผู้ใช้ · ตรวจรหัสผ่าน · เก็บว่าใครมีสิทธิ์อะไร · แล้วออกใบรับรอง (token) ให้แอปเอาไปใช้ต่อ
Keycloak เป็น IAM แบบ open source ที่คุณรันเองบนเครื่องตัวเองได้ ไม่ต้องสมัครบริการใคร ไม่ต้องจ่ายรายเดือน
ในภาษาของบทที่แล้ว Keycloak ก็คือกล่อง Authorization Server ในแผนภาพ OAuth2 นั่นเอง

2 · ทำเองทั้งหมด vs ให้ Keycloak ทำ

สไลด์หน้า 39 เป็นตารางเทียบสองคอลัมน์ ผมยกมาครบทั้งหกแถว — ซ้ายคืองานที่คุณต้องเขียนเองถ้าไม่ใช้ IAM ขวาคือสิ่งที่ Keycloak มีมาให้:

คำใหม่ในตารางนี้มีสองคำ นิยามไว้ก่อน:

• RBAC (Role-Based Access Control) = ระบบสิทธิ์ที่ผูกสิทธิ์ไว้กับ "บทบาท" ไม่ใช่กับตัวคน
  แทนที่จะเขียนว่า "สมชายลบสูตรได้" คุณเขียนว่า "role admin ลบสูตรได้" แล้วค่อยแปะ role admin ให้สมชาย — วันที่สมชายลาออก คุณถอด role ออกที่เดียวจบ
• Token signing / rotation = การเซ็นลายเซ็นดิจิทัลลงบน token เพื่อให้ผู้รับตรวจได้ว่าไม่มีใครแก้ระหว่างทาง · ส่วน rotation คือการเปลี่ยนกุญแจที่ใช้เซ็นเป็นระยะ ซึ่งถ้าทำเองต้องคิดเรื่อง "แล้ว token ใบเก่าที่เซ็นด้วยกุญแจเก่าจะยังใช้ได้ไหม" ให้ครบ

3 · compose.yml ของสไลด์ ทีละบรรทัด

สไลด์หน้า 40 ให้ compose มาทั้งไฟล์ (ส่วน postgres กับ redis เขาย่อเป็น ... เพราะสอนไปแล้วใน บทเรียน 32):

services:
  postgres:
    ...

  redis:
    ...

  keycloak:
    image: quay.io/keycloak/keycloak:26.7
    container_name: wongnok-keycloak
    restart: always
    command: ["start-dev", "--import-realm"]
    environment:
      KC_BOOTSTRAP_ADMIN_USERNAME: admin
      KC_BOOTSTRAP_ADMIN_PASSWORD: admin
      KC_HOSTNAME_STRICT: "false"
      KC_HTTP_ENABLED: "true"
    ports:
      - "8081:8080"
    volumes:
      # เก็บข้อมูลของ embedded database (dev-file) ไว้
      - wongnok-keycloak-data:/opt/keycloak/data

volumes:
  wongnok-pgdata:
  wongnok-keycloak-data:

ทีนี้มาไล่ทีละบรรทัดว่ามันทำอะไร — และบรรทัดไหนไม่ทำอะไร:

ทำไมต้อง 8081:8080 ไม่ใช่ 8080:8080

รูปแบบของ ports คือ ข้างนอก:ข้างใน — ตัวหน้าคือพอร์ตบนเครื่องคุณ ตัวหลังคือพอร์ตข้างใน container
Keycloak ข้างใน container ฟังที่ 8080 เสมอ (ล็อกตอน start พิมพ์ยืนยัน: Listening on: http://0.0.0.0:8080) เราแก้ตัวหลังไม่ได้ถ้าไม่ตั้งค่าเพิ่ม
แต่ 8080 บนเครื่องคุณถูกจองไว้ให้ API ของเราแล้ว — ตั้งแต่ บทเรียน 37 เป็นต้นมา ทุกตัวอย่างรัน r.Run(":8080")
ถ้าแมปเป็น 8080:8080 คุณจะรัน Keycloak กับ API พร้อมกันไม่ได้ — ตัวที่ขึ้นทีหลังจะจองพอร์ตไม่ได้

Running the server in development mode. DO NOT use this configuration in production.

4 · รันขึ้นจริง — และสามบรรทัดในล็อกที่ต้องอ่าน

สั่งขึ้น — compose พิมพ์เป็นคู่ทุกอย่าง (Creating แล้วค่อย Created) ก้อนนี้คือ output เต็ม ๆ ไม่ได้ตัดบรรทัดไหนทิ้ง:

$ docker-compose up -d
 Network kc_default Creating
 Network kc_default Created
 Volume kc_wongnok-keycloak-data Creating
 Volume kc_wongnok-keycloak-data Created
 Container wongnok-keycloak Creating
 Container wongnok-keycloak Created
 Container wongnok-keycloak Starting
 Container wongnok-keycloak Started

ถ้าเครื่องคุณยังไม่มี image จะมีบรรทัด Image quay.io/keycloak/keycloak:26.7 Pulled โผล่เพิ่มมาข้างบนสุด และรอบแรกจะช้ากว่านี้มาก (เวลาหมดไปกับการ pull ไม่ใช่การ start)

แล้ววนถามจนกว่ามันจะตอบ ด้วยการยิงไปที่ discovery endpoint (จะอธิบายว่ามันคืออะไรในหัวข้อ 5) และดูแค่ HTTP status code
ใน URL มีคำว่า realms/master — ตอนนี้รู้แค่ว่า realm = พื้นที่ผู้ใช้/สิทธิ์แยกอิสระหนึ่งชุด ก็พอ ส่วน master คือชุดตั้งต้นที่ Keycloak แถมมาให้ (รายละเอียดเต็มอยู่ในตารางหัวข้อ 6):

$ for i in $(seq 1 60); do
    code=$(curl -s -o /dev/null -w '%{http_code}' \
      http://localhost:8081/realms/master/.well-known/openid-configuration)
    [ "$code" = "200" ] && { echo "READY (HTTP $code)"; break; }
    sleep 1
  done
READY (HTTP 200)   # ของผมได้ 200 ที่รอบที่ 5 (~5 วินาที)

ทีนี้เปิดล็อกดู — สามบรรทัดนี้คือทั้งหมดที่ต้องอ่าน:

$ docker logs wongnok-keycloak | tail
2026-08-22 03:13:34,745 INFO  [org.keycloak.services] (main)
    KC-SERVICES0077: Created temporary admin user with username admin
2026-08-22 03:13:34,883 INFO  [io.quarkus] (main)
    Keycloak 26.7.2 on JVM (powered by Quarkus 3.33.3.1) started in 5.582s.
    Listening on: http://0.0.0.0:8080
2026-08-22 03:13:34,883 INFO  [io.quarkus] (main) Profile dev activated.

อ่านได้สี่เรื่อง:
· tag 26.7 ให้เวอร์ชันจริง 26.7.2 — เพราะ 26.7 เป็น floating tag คือ tag ที่ชี้ไปเวอร์ชันย่อยล่าสุดของสาย 26.7 เรื่อย ๆ
· บัญชีแอดมินชั่วคราวถูกสร้างแล้ว ตามที่ KC_BOOTSTRAP_ADMIN_* สั่ง (เข้า UI ที่ http://localhost:8081 ด้วย admin/admin ได้เลย — หน้าตาแบบสไลด์หน้า 41)
· Listening on: http://0.0.0.0:8080 ยืนยันว่าข้างใน container คือ 8080 จริง
· Profile dev activated — คือผลของ start-dev

$ docker logs wongnok-keycloak | head -20
2026-08-25 12:35:29,898 INFO  [org.keycloak.url.HostnameV2ProviderFactory] (main)
    If hostname is specified, hostname-strict is effectively ignored

$ docker logs wongnok-keycloak 2>&1 | grep -i -E "import|realm"
2026-08-22 03:13:34,071 INFO  [org.keycloak.services] (main)
    KC-SERVICES0050: Initializing master realm

5 · OIDC discovery — ที่อยู่ของทุก endpoint มาจากไฟล์เดียว

ก่อนอื่นนิยามศัพท์: OIDC (OpenID Connect) คือมาตรฐานที่ต่อยอดจาก OAuth2 โดยเพิ่มเรื่อง "แล้วผู้ใช้คนนี้เป็นใคร" เข้าไป (OAuth2 เพียว ๆ ตอบแค่ "แอปนี้มีสิทธิ์ทำอะไร")
ของที่ OIDC เพิ่มเข้ามาและเราจะได้เห็นเดี๋ยวนี้คือ id_token กับ discovery endpoint

Discovery endpoint คือ URL มาตรฐานหนึ่งอันที่ทุก OIDC server ต้องมี — ตำแหน่งคือ /.well-known/openid-configuration ต่อท้าย realm
ยิงเข้าไปแล้วมันจะคืน JSON ที่บอกที่อยู่ของทุก endpoint ที่เหลือ แปลว่าคุณไม่ต้องจำ URL อะไรเลยนอกจากอันนี้อันเดียว:

$ curl -s http://localhost:8081/realms/master/.well-known/openid-configuration

issuer                 = "http://localhost:8081/realms/master"
authorization_endpoint = "http://localhost:8081/realms/master/protocol/openid-connect/auth"
token_endpoint         = "http://localhost:8081/realms/master/protocol/openid-connect/token"
jwks_uri               = "http://localhost:8081/realms/master/protocol/openid-connect/certs"
end_session_endpoint   = "http://localhost:8081/realms/master/protocol/openid-connect/logout"
userinfo_endpoint      = "http://localhost:8081/realms/master/protocol/openid-connect/userinfo"
introspection_endpoint = "http://localhost:8081/realms/master/protocol/openid-connect/token/introspect"

จับคู่กับแผนภาพ OAuth2 ในบทที่แล้วได้ตรง ๆ:

ในไฟล์เดียวกันยังบอกด้วยว่ารองรับวิธีขอ token แบบไหนบ้าง (grant_types_supported) — ผมยกมาเฉพาะที่จะใช้ในบทนี้:

grant_types_supported = ["authorization_code", "client_credentials", "implicit",
                         "password", "refresh_token",
                         "urn:ietf:params:oauth:grant-type:device_code",
                         "urn:ietf:params:oauth:grant-type:jwt-bearer",
                         "urn:ietf:params:oauth:grant-type:token-exchange",
                         "urn:ietf:params:oauth:grant-type:uma-ticket",
                         "urn:openid:params:grant-type:ciba"]

response_types_supported = ["code", "none", "id_token", "token", "id_token token",
                            "code id_token", "code token", "code id_token token"]

ลบ KC_HOSTNAME ทิ้งแล้วเกิดอะไรขึ้น — ผมรันเทียบสองตัวพร้อมกัน

ผมยกคอนเทนเนอร์ขึ้นมาสองตัว ต่างกันบรรทัดเดียว แล้วยิง discovery ด้วย Host: header คนละแบบ เพื่อดูว่า issuer ที่ประกาศออกมาเปลี่ยนตามไหม:

# ฉบับก่อนเรียน — ปักหมุด hostname ไว้
$ docker run -d --name kcpre  -p 8093:8080 \
    -e KC_HOSTNAME=localhost -e KC_HOSTNAME_STRICT=false -e KC_HTTP_ENABLED=true \
    quay.io/keycloak/keycloak:26.7 start-dev

# ฉบับ Post — ไม่ปักหมุด
$ docker run -d --name kcpost -p 8091:8080 \
    -e KC_HOSTNAME_STRICT=false -e KC_HTTP_ENABLED=true \
    quay.io/keycloak/keycloak:26.7 start-dev

$ curl -s -H "Host: <ที่ระบุในตาราง>" http://localhost:<พอร์ต>/realms/master/.well-known/openid-configuration \
    | jq -r .issuer

อ่านตารางนี้ให้ออกคือเข้าใจทั้งเรื่อง:
· KC_HOSTNAME = "ไม่ว่าใครจะเรียกฉันว่าอะไร ฉันจะตอบว่าฉันชื่อ localhost"
· ไม่มี KC_HOSTNAME = "ใครเรียกฉันว่าอะไร ฉันก็ตอบตามนั้น"

kcpre  (ปักหมุด)    http://kcpre:8080/...  -> issuer = http://localhost:8080/realms/master
kcpost (ไม่ปักหมุด)  http://kcpost:8080/... -> issuer = http://kcpost:8080/realms/master

oidc: issuer URL provided to client ("http://127.0.0.1:8093/realms/master")
did not match the issuer URL returned by provider ("http://localhost:8093/realms/master")

6 · Keycloak components — ห้ากล่องที่ต้องแยกให้ออก

สไลด์หน้า 42 วาดกล่องซ้อนกันไว้ ผมวาดใหม่ให้เห็นทิศทางความสัมพันธ์ชัดขึ้น:

┌── Realm: wongnok ─────────────────────────────────────────┐
│                                                           │   ← Realm = พื้นที่แยกอิสระ 1 ชุด
│   ┌── Clients ──────────────┐   ┌── Users ─────────────┐  │      ของใน realm หนึ่ง
│   │ client_id  wongnok-api  │   │ chef1                │  │      มองไม่เห็นอีก realm เลย
│   │ client_secret  ******   │   │ chef1@wongnok.dev    │  │
│   │ client scope = claims   │   │ + password           │  │   ← Clients = "แอปไหนขอ token"
│   └─────────────────────────┘   └──────────┬───────────┘  │      Users   = "คนไหนล็อกอิน"
│                                            │              │
│                          user เป็นสมาชิกของ │              │
│                                            ▼              │
│   ┌── Roles ────────────────┐   ┌── Groups ────────────┐  │
│   │ recipe:write            │◄──┤ chefs                │  │   ← ผูก role ไว้ที่ "group"
│   │ recipe:read             │   │ admins               │  │      ไม่ใช่ผูกทีละ user
│   └────────────┬────────────┘   └──────────────────────┘  │
│                │                                          │
└────────────────┼──────────────────────────────────────────┘
                 │
                 ▼
   access_token → realm_access.roles = ["recipe:write", ...]
                  ↑ role โผล่ที่นี่ ไม่ใช่ที่ resource_access

ก่อนพิสูจน์ — ขอ token จริงมาดูก่อน

# 1) ขอ token ของแอดมินไว้ใช้สั่งงาน admin API
KC=http://localhost:8081
AT=$(curl -s -X POST $KC/realms/master/protocol/openid-connect/token \
      -d client_id=admin-cli -d username=admin -d password=admin \
      -d grant_type=password | python3 -c 'import sys,json;print(json.load(sys.stdin)["access_token"])')
H="Authorization: Bearer $AT"

# 2) realm                                                        -> 201
curl -s -X POST $KC/admin/realms -H "$H" -H 'Content-Type: application/json' \
  -d '{"realm":"wongnok","enabled":true}'

# 3) client — publicClient + directAccessGrants ต้องเปิดทั้งคู่    -> 201
curl -s -X POST $KC/admin/realms/wongnok/clients -H "$H" -H 'Content-Type: application/json' \
  -d '{"clientId":"wongnok-api","enabled":true,"publicClient":true,
       "directAccessGrantsEnabled":true,"standardFlowEnabled":true,
       "webOrigins":["http://localhost:8080"],"redirectUris":["http://localhost:8080/*"]}'

# 4) user chef1 พร้อม password                                    -> 201
curl -s -X POST $KC/admin/realms/wongnok/users -H "$H" -H 'Content-Type: application/json' \
  -d '{"username":"chef1","enabled":true,"emailVerified":true,
       "firstName":"Chef","lastName":"One","email":"chef1@wongnok.dev",
       "credentials":[{"type":"password","value":"chef1234","temporary":false}]}'

# 5) realm role + group (เอาไปผูกกันในหัวข้อถัดไป)                 -> 201, 201
curl -s -X POST $KC/admin/realms/wongnok/roles  -H "$H" -H 'Content-Type: application/json' -d '{"name":"recipe:write"}'
curl -s -X POST $KC/admin/realms/wongnok/groups -H "$H" -H 'Content-Type: application/json' -d '{"name":"chefs"}'

{"error":"unauthorized_client","error_description":"Invalid client or Invalid client credentials"}

พอมีของครบแล้วก็ขอ token ด้วย password grant — คือการส่ง username/password ไปที่ token_endpoint ตรง ๆ ไม่ผ่านหน้าเว็บ ซึ่งใช้ได้เฉพาะตอนทดสอบ (ท่านี้ถูกถอดออกจาก OAuth 2.1 แล้ว และ RFC 9700 ซึ่งเป็น Best Current Practice แนะนำว่าไม่ควรใช้ — ที่ใช้ตรงนี้เพราะมันเป็นวิธีเดียวที่ขอ token ได้จาก command line โดยไม่ต้องเปิดเบราว์เซอร์ · ของจริงใช้ authorization code flow ซึ่งอยู่ในบทเรียน 52):

$ curl -s -X POST http://localhost:8081/realms/wongnok/protocol/openid-connect/token \
    -d client_id=wongnok-api -d username=chef1 -d password=chef1234 \
    -d grant_type=password -d scope=openid

access_token       = eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ3eXZLU2Zx...  [len 1346]
expires_in         = 300
refresh_expires_in = 1800
refresh_token      = eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJiMmZmZGIz...  [len 694]
token_type         = Bearer
id_token           = eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ3eXZLU2Zx...  [len 1037]
not-before-policy  = 0
session_state      = grEBoqUUX084tjH4AEFbI5aJ
scope              = openid profile email

เก็บ token สองใบลงไฟล์ไว้ก่อน — เดี๋ยวหัวข้อ 7 จะหยิบไปใช้ทั้งคู่ (at.txt เอาไป verify ลายเซ็น · rt.txt เอาไปแลก token ใบใหม่):

$ curl -s -X POST http://localhost:8081/realms/wongnok/protocol/openid-connect/token \
    -d client_id=wongnok-api -d username=chef1 -d password=chef1234 \
    -d grant_type=password -d scope=openid > tok.json

$ python3 -c "import json;d=json.load(open('tok.json'));open('at.txt','w').write(d['access_token']);open('rt.txt','w').write(d['refresh_token'])"

$ wc -c at.txt rt.txt
    1346 at.txt
     694 rt.txt
    2040 total

if claims.Audience != "wongnok-api" {
    return errors.New("wrong audience")
}

{
  "exp": 1787368745,
  "iat": 1787368445,
  "jti": "onrtro:f1adacbf-bd71-072f-c8c8-b8a6d666cc03",
  "iss": "http://localhost:8081/realms/wongnok",
  "aud": "account",
  "sub": "5da7f595-196f-44a6-8dfd-64306ce734d6",
  "typ": "Bearer",
  "azp": "wongnok-api",
  "sid": "grEBoqUUX084tjH4AEFbI5aJ",
  "acr": "1",
  "allowed-origins": ["http://localhost:8080"],
  "realm_access": { "roles": ["default-roles-wongnok", "offline_access", "uma_authorization"] },
  "resource_access": { "account": { "roles": ["manage-account", "manage-account-links", "view-profile"] } },
  "scope": "openid profile email",
  "email_verified": true,
  "name": "Chef One",
  "preferred_username": "chef1",
  "given_name": "Chef",
  "family_name": "One",
  "email": "chef1@wongnok.dev"
}

พิสูจน์ลูกศร "user ใน group ได้ role อัตโนมัติ"

นี่คือข้ออ้างที่วาดเป็นลูกศรไว้ในสไลด์หน้า 42 และมันเป็นข้ออ้างที่ตรวจได้ตรง ๆ
ผมทำสามขั้น: สร้าง role recipe:write · สร้าง group chefs · แล้วผูก role เข้า group (ไม่ใช่เข้า user) จากนั้นเอา chef1 ใส่ group

# 1. เอา role recipe:write ไปแปะที่ "group" ชื่อ chefs
POST /admin/realms/wongnok/groups/$GRP/role-mappings/realm

# 2. เอา user chef1 ใส่เข้า group ชื่อ chefs
PUT  /admin/realms/wongnok/users/$USR/groups/$GRP

== 3. map role recipe:write -> group chefs ==
HTTP 204
== 4. put user chef1 into group chefs ==
HTTP 204

== 5a. DIRECT realm roles of chef1 ==
['default-roles-wongnok']

== 5b. COMPOSITE/effective realm roles of chef1 ==
['default-roles-wongnok', 'offline_access', 'recipe:write', 'uma_authorization']

== 5c. groups of chef1 ==
['/chefs']

== access_token payload AFTER group->role ==
  "azp": "wongnok-api",
  "preferred_username": "chef1",
  "realm_access": { "roles": ["default-roles-wongnok", "recipe:write",
                              "offline_access", "uma_authorization"] }

7 · พิสูจน์แถวสุดท้าย — public key ใบเดียว verify ได้จริงไหม

กลับมาที่ข้ออ้างในตารางหัวข้อ 2: "ทุก service ใช้ public key เดียวกันจาก Keycloak verify ได้เลย ไม่ต้องแชร์ secret"
ทำไมข้อนี้ถึงเป็นเรื่องใหญ่: ถ้าจริง แปลว่า service ที่ 2, 3, 4 ในระบบคุณ ตรวจ token ได้เองโดยไม่ต้องถือความลับอะไรเลย และไม่ต้องยิงถาม Keycloak ทุก request

ที่อยู่ของ public key อยู่ในไฟล์ discovery แล้ว — คือ field jwks_uri
JWKS ย่อจาก JSON Web Key Set = ชุดกุญแจในรูปแบบ JSON

$ curl -s http://localhost:8081/realms/wongnok/protocol/openid-connect/certs

number of keys = 2

{'kid': 'wyvKSfqZdLBxEgiFH8uLjDWqHbA_HNNaoo7eusbO...', 'kty': 'RSA',
 'alg': 'RS256', 'use': 'sig',  'x5t': 'or42Mu3VYD2f5W9Av5ynyyZmCFs',
 'n': 'vJgLqZ6CjF23xnuZ3V8bOc9FP7iJqzE_QxTfQcjd...', 'e': 'AQAB'}

{'kid': 'Mf4wHVuGfb9hhl_aZu4jyayOm94BXmiUsDX413Re...', 'kty': 'RSA',
 'alg': 'RSA-OAEP', 'use': 'enc', 'x5t': 'roKarAk6jTub0Z7KvbZJ0f9eQWI',
 'n': 'rRa7SOuWAVLgWZmNK0qfzRuSK93hfN-ICNvDl8Kg...', 'e': 'AQAB'}

ทีนี้พิสูจน์ของจริง — ผมเขียนโปรแกรม Go ด้วย standard library ล้วน ๆ (ไม่ใช้ library JWT ตัวไหนเลย เพื่อให้เห็นว่าไม่มีอะไรซ่อนอยู่): ดึง JWKS → หาใบที่ kid ตรง → ประกอบเป็น rsa.PublicKey จากค่า n กับ e → เรียก rsa.VerifyPKCS1v15

นี่คือทั้งไฟล์ ไม่ได้ตัดอะไรออก — สร้างโฟลเดอร์ใหม่ verify/ ข้าง ๆ at.txt แล้ว go mod init kcverify ก่อน จากนั้นวางเป็น verify/main.go:

// verify/main.go — ตรวจลายเซ็น JWT ด้วย stdlib ล้วน ไม่มี dependency
package main

import (
	"crypto"
	"crypto/rsa"
	"crypto/sha256"
	"encoding/base64"
	"encoding/json"
	"fmt"
	"math/big"
	"net/http"
	"os"
	"strings"
)

type jwk struct {
	Kid string `json:"kid"`
	Alg string `json:"alg"`
	Use string `json:"use"`
	N   string `json:"n"`
	E   string `json:"e"`
}

// JWT ใช้ base64url แบบไม่มี padding
func b64(s string) []byte {
	b, err := base64.RawURLEncoding.DecodeString(s)
	if err != nil {
		panic(err)
	}
	return b
}

func main() {
	// arg 1 = ไฟล์ที่เก็บ access_token · arg 2 = jwks_uri
	raw, err := os.ReadFile(os.Args[1])
	if err != nil {
		panic(err)
	}
	parts := strings.Split(strings.TrimSpace(string(raw)), ".")

	var hdr struct{ Kid, Alg string }
	json.Unmarshal(b64(parts[0]), &hdr)
	fmt.Printf("token header kid = %s  alg = %s\n", hdr.Kid, hdr.Alg)

	resp, err := http.Get(os.Args[2])
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()
	var set struct{ Keys []jwk }
	json.NewDecoder(resp.Body).Decode(&set)

	// หาใบที่ kid ตรง — ห้ามใช้ Keys[0]
	var key *jwk
	for i := range set.Keys {
		if set.Keys[i].Kid == hdr.Kid {
			key = &set.Keys[i]
		}
	}
	if key == nil {
		fmt.Println("no matching kid in JWKS")
		os.Exit(1)
	}
	fmt.Printf("matched JWKS key: kid = %s use = %s alg = %s\n", key.Kid, key.Use, key.Alg)

	// ประกอบ rsa.PublicKey จาก n (modulus) กับ e (exponent) ที่เป็น base64url
	e := 0
	for _, c := range b64(key.E) {
		e = e<<8 | int(c)
	}
	pub := &rsa.PublicKey{N: new(big.Int).SetBytes(b64(key.N)), E: e}
	fmt.Printf("public key modulus bits = %d  exponent = %d\n", pub.N.BitLen(), pub.E)

	// ลายเซ็นเซ็นทับสตริง "header.payload" ตรง ๆ
	signed := parts[0] + "." + parts[1]
	sum := sha256.Sum256([]byte(signed))
	if err := rsa.VerifyPKCS1v15(pub, crypto.SHA256, sum[:], b64(parts[2])); err != nil {
		fmt.Println("VERIFY FAILED:", err)
		os.Exit(1)
	}
	fmt.Println("VERIFY OK  -> signature valid using ONLY the public key from jwks_uri (no client_secret used)")

	// แก้ token หนึ่งบิตแล้วตรวจซ้ำ — ต้องไม่ผ่าน
	bad := []byte(signed)
	bad[len(bad)-1] ^= 0x01
	badSum := sha256.Sum256(bad)
	err = rsa.VerifyPKCS1v15(pub, crypto.SHA256, badSum[:], b64(parts[2]))
	fmt.Println("tampered token correctly REJECTED:", err)
}

รันจากในโฟลเดอร์ verify/ โดยชี้ไปที่ at.txt ที่เก็บไว้ตอนหัวข้อ 6:

$ go run . ../at.txt http://localhost:8081/realms/wongnok/protocol/openid-connect/certs

token header kid = wyvKSfqZdLBxEgiFH8uLjDWqHbA_HNNaoo7eusbOGF4  alg = RS256
matched JWKS key: kid = wyvKSfqZdLBxEgiFH8uLjDWqHbA_HNNaoo7eusbOGF4 use = sig alg = RS256
public key modulus bits = 2048  exponent = 65537
VERIFY OK  -> signature valid using ONLY the public key from jwks_uri (no client_secret used)
tampered token correctly REJECTED: crypto/rsa: verification error

== JWT header of access_token ==
{ "alg": "RS256", "typ": "JWT", "kid": "wyvKSfqZdLBxEgiFH8uLjDWqHbA_HNNaoo7eusbOGF4" }

== refresh_token header ==
{ "alg": "HS512", "typ": "JWT", "kid": "b2ffdb37-5e0e-4ae7-b420-370b9638d5b1" }

ส่วนวิธีใช้ refresh_token ที่ถูกต้องคือแบบนี้ — ยิงกลับไปที่ Keycloak:

$ curl -s -X POST http://localhost:8081/realms/wongnok/protocol/openid-connect/token \
    -d client_id=wongnok-api -d grant_type=refresh_token \
    --data-urlencode refresh_token=$(cat rt.txt) \
  | python3 -c "import sys,json;d=json.load(sys.stdin);print('keys:',list(d.keys()));print('new access_token len:',len(d['access_token']))"

keys: ['access_token', 'expires_in', 'refresh_expires_in', 'refresh_token',
       'token_type', 'id_token', 'not-before-policy', 'session_state', 'scope']
new access_token len: 1366

8 · ข้อมูลรอด restart ไหม + เก็บกวาด

บรรทัด volumes: ใน compose มีไว้เพื่ออะไร — พิสูจน์ง่ายมาก
ก่อนอื่นเปิดดูว่าข้างในเก็บอะไรไว้จริง:

$ docker exec wongnok-keycloak ls -la /opt/keycloak/data/h2
total 1720
drwxr-xr-x 2 keycloak root    4096 Aug 22 04:41 .
drwxrwxr-x 4 keycloak root    4096 Aug 22 04:41 ..
-rw-r--r-- 1 keycloak root 1683456 Aug 22 04:42 keycloakdb.mv.db
-rw-r--r-- 1 keycloak root   69091 Aug 22 04:41 keycloakdb.trace.db

ตัวเลขขนาดไฟล์ของคุณจะไม่ตรงกับของผม — มันโตตามจำนวน realm/user/role ที่สร้างไว้ ที่ต้องตรงคือชื่อไฟล์สองไฟล์นี้

นี่คือฐานข้อมูล H2 — ฐานข้อมูลที่ฝังมากับตัว Keycloak ในโหมด start-dev ทั้ง realm ทั้ง user ทั้ง role อยู่ในไฟล์ keycloakdb.mv.db ไฟล์เดียวนี้
ทีนี้ restart แล้วขอ token ใหม่:

$ docker restart wongnok-keycloak && curl -s -o /dev/null \
    --retry 30 --retry-delay 2 --retry-all-errors --retry-connrefused \
    -w 'ready again (HTTP %{http_code})\n' \
    http://localhost:8081/realms/wongnok/.well-known/openid-configuration
ready again (HTTP 200)

$ curl -s -X POST http://localhost:8081/realms/wongnok/protocol/openid-connect/token \
    -d client_id=wongnok-api -d username=chef1 -d password=chef1234 \
    -d grant_type=password -d scope=openid \
  | python3 -c "import sys,json,base64; d=json.load(sys.stdin); p=json.loads(base64.urlsafe_b64decode(d['access_token'].split('.')[1]+'==')); print('preferred_username =',p['preferred_username']); print('realm_access.roles =',p['realm_access']['roles'])"
preferred_username = chef1
realm_access.roles = ['default-roles-wongnok', 'recipe:write', 'offline_access', 'uma_authorization']

realm · user · group · role · การผูก role ผ่าน group — รอดครบทุกอย่าง
ถ้าไม่ mount volume ไว้ ทุกอย่างที่คุณคลิกสร้างใน UI จะหายหมดทุกครั้งที่ container ถูกสร้างใหม่

เสร็จแล้วเก็บกวาด — -v คือสั่งให้ลบ volume ไปด้วย:

$ docker-compose down -v
 Container wongnok-keycloak Stopping
 Container wongnok-keycloak Stopped
 Container wongnok-keycloak Removing
 Container wongnok-keycloak Removed
 Network kc_default Removing
 Volume kc_wongnok-keycloak-data Removing
 Volume kc_wongnok-keycloak-data Removed
 Network kc_default Removed

$ docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
(ว่างเปล่า ไม่มีแถวเลย)

$ docker images quay.io/keycloak/keycloak
IMAGE                            ID             DISK USAGE   CONTENT SIZE   EXTRA
quay.io/keycloak/keycloak:26.7   831330513f55        756MB          266MB   U

สรุปสิ่งที่สไลด์บอกครบ และสิ่งที่ต้องเติมเอง

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

  "azp": "wongnok-api",
  "preferred_username": "chef1",
  "realm_access": { "roles": ["default-roles-wongnok", "recipe:write",
                              "offline_access", "uma_authorization"] }

อ้างอิง

• Keycloak — Getting started with Docker — อ่านย่อหน้าที่อธิบาย start-dev ซึ่งบอกตรง ๆ ว่าโหมดนี้มีไว้ทำอะไรและห้ามใช้ที่ไหน
• Keycloak — Server configuration (ทุกตัวแปร) — ที่มาของ KC_HOSTNAME, KC_HOSTNAME_STRICT, KC_HTTP_ENABLED · ค้นคำว่า hostname-strict แล้วอ่านหมายเหตุ จะเจอเหตุผลของบรรทัดที่เป็น no-op
• Keycloak — Importing and exporting realms — อ่านว่า --import-realm อ่านไฟล์จากโฟลเดอร์ไหน (/opt/keycloak/data/import) ซึ่งอธิบายว่าทำไม flag ในสไลด์ถึงเงียบ
• OpenID Connect Discovery 1.0 — ต้นทางของ /.well-known/openid-configuration และรายชื่อ field ทั้งหมดที่เห็นในหัวข้อ 5
• RFC 7519 — JWT Registered Claim Names — นิยามทางการของ iss, aud, exp, sub · สังเกตว่า azp ไม่ได้อยู่ในนี้ เพราะมันมาจากฝั่ง OIDC ไม่ใช่ JWT พื้นฐาน
• RFC 7517 — JSON Web Key (JWK) — ที่มาของ field kid, use, alg, n, e ที่เห็นในหัวข้อ 7
• quay.io — รายการ tag ทั้งหมดของ Keycloak — ใช้เช็คว่า tag ที่จะเขียนใน compose มีจริงไหม และตอนนี้ชี้ไปเวอร์ชันไหน
• บทเรียน 44 — Configuration & Environment Variables — ค่าใน environment: ของ compose ก็คือ env ตัวเดียวกับที่บทนั้นสอน