โดย Matt Connor 2026-10-25

วิธีติดตั้ง Authentik ด้วย Docker Compose สำหรับระบบ SSO

Q: จำเป็นต้องใช้ Traefik เพื่อใช้งาน Authentik หรือไม่?

ไม่จำเป็น Forward auth สามารถทำงานร่วมกับ nginx ผ่าน auth_request และกับ Caddy ผ่าน forward_auth ได้ รูปแบบการทำงานจะเหมือนกันในทุกกรณี คือ reverse proxy จะสอบถาม Authentik เกี่ยวกับคำขอแต่ละรายการ และ path prefix /outpost.goauthentik.io/ บน hostname ที่ได้รับการป้องกันจะต้องส่งคำขอไปยัง Authentik แทนที่จะส่งไปยังแอปพลิเคชันโดยตรง

เรียนรู้วิธีติดตั้ง Authentik บน Docker Compose เพื่อทำระบบ SSO สำหรับแอปพลิเคชันของคุณ ครอบคลุมการตั้งค่า env การใช้ akadmin bootstrap และการทำ forward auth ผ่าน Traefik อย่างละเอียด

การล็อกอินครั้งเดียวสำหรับทุกแอปที่คุณโฮสต์

Authentik คือเซิร์ฟเวอร์ SSO (single sign-on) แบบ self-hosted: ผู้ใช้ของคุณจะล็อกอินเพียงครั้งเดียว และทุกแอปที่อยู่เบื้องหลังจะยอมรับ session นั้นแทนการถามรหัสผ่านของตัวเอง การติดตั้งใช้ไฟล์ Docker Compose อย่างเป็นทางการและ secret ที่สร้างขึ้นสองรายการ ส่วนที่ต้องใช้การวางแผนอย่างจริงจังคือขั้นตอนหลังจากนั้น ได้แก่ การชี้ reverse proxy ไปที่ Authentik และการนำแอปที่มีอยู่มาไว้เบื้องหลัง forward auth

Authentik ประกอบด้วยสามบริการในไฟล์ Compose นั้น: ฐานข้อมูล PostgreSQL, กระบวนการ server และกระบวนการ worker คอนเทนเนอร์ของเซิร์ฟเวอร์ยังรัน embedded outpost ซึ่งเป็นคอมโพเนนต์ที่ทำหน้าที่ตอบคำถามว่า "คำขอนี้ได้รับการล็อกอินแล้วหรือไม่" สำหรับทุกแอปที่ได้รับการป้องกัน เวอร์ชัน 2026.8.5 คือรุ่นปัจจุบัน ณ วันที่ 25 ตุลาคม 2026 โดยถูกเผยแพร่เมื่อวันที่ 21 ตุลาคม 2026 ในฐานะ patch ล่าสุดของซีรีส์ 2026.8 ซึ่งเริ่มต้นด้วย 2026.8.0 เมื่อวันที่ 18 สิงหาคม และเข้ามาแทนที่ 2026.8.4 จากวันที่ 14 ตุลาคม ในฐานะ image tag เริ่มต้นในไฟล์ Compose อย่างเป็นทางการ โครงการแนะนำให้ใช้โฮสต์ที่มี CPU อย่างน้อย 2 คอร์และ RAM 2 GB ให้ถือว่านี่คือค่าขั้นต่ำ ทั้ง PostgreSQL และ worker จะใช้หน่วยความจำเพิ่มขึ้นหลังจากเครื่องเปิดใช้งานมาแล้วหนึ่งวัน

สิ่งที่ต้องเตรียมก่อนเริ่มต้น

คุณต้องติดตั้ง Docker Engine พร้อมปลั๊กอิน Compose v2 ซึ่งสามารถตรวจสอบได้ด้วยคำสั่ง docker compose version หากคำสั่งดังกล่าวแสดงข้อผิดพลาดแทนที่จะเป็นเวอร์ชัน ให้ติดตั้งปลั๊กอินให้เรียบร้อยก่อนดำเนินการต่อ โดยสามารถดูพื้นฐานได้ที่ การรันแอปพลิเคชันด้วย Docker Compose บน VPS นอกจากนี้ คุณต้องมี DNS A record ที่ชี้มายังเซิร์ฟเวอร์ของคุณ ซึ่งในตัวอย่างด้านล่างจะใช้ auth.example.com เนื่องจาก Authentik จะสร้าง URL สำหรับ redirect โดยอ้างอิงจาก hostname ที่เบราว์เซอร์ใช้งาน

ให้รัน stack ในฐานะผู้ใช้ทั่วไปที่อยู่ในกลุ่ม docker แทนการใช้ root การเป็นสมาชิกของกลุ่มนี้มีสิทธิ์เทียบเท่ากับ root บนโฮสต์ ดังนั้นควรให้สิทธิ์นี้แก่บัญชีสำหรับ deploy เพียงบัญชีเดียวเท่านั้น โดยสามารถดูแนวทางได้ที่ บัญชีผู้ใช้แบบจำกัดสิทธิ์บน VPS

การติดตั้งด้วยไฟล์ Compose อย่างเป็นทางการ

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps ควรแสดงรายการคอนเทนเนอร์สามรายการที่ทำงานอยู่ทั้งหมด โดย postgresql จะรายงานสถานะ healthy เมื่อผ่านการตรวจสอบ การเริ่มทำงานครั้งแรกจะดำเนินการ database migration ดังนั้นควรรอประมาณหนึ่งนาทีก่อนที่เว็บอินเทอร์เฟซจะตอบสนอง

ค่าที่สร้างขึ้นทั้งสองรายการมีความสำคัญด้วยเหตุผลที่ต่างกัน PG_PASS คือรหัสผ่านของ PostgreSQL เอกสารการติดตั้งของ Authentik ระบุว่าไม่รองรับรหัสผ่านที่ยาวเกิน 99 ตัวอักษร ดังนั้นให้รหัสผ่านที่คุณกำหนดเองมีความยาวไม่เกินนี้ ส่วนรหัสผ่านที่ระบบสร้างให้จะสั้นกว่านั้นมาก AUTHENTIK_SECRET_KEY คือคีย์ที่ Authentik ใช้สำหรับลงนามในคุกกี้ และเอกสารการกำหนดค่าระบุว่าการเปลี่ยนคีย์นี้จะทำให้ session ที่ใช้งานอยู่ทั้งหมดสิ้นสุดลง ดังนั้นการใช้คีย์ใหม่ในภายหลังจะทำให้ผู้ใช้ทุกคนที่ล็อกอินอยู่ถูกออกจากระบบ ให้ตั้งค่า .env เป็นโหมด 600 และเก็บสำเนาไว้ในที่ปลอดภัยพร้อมกับข้อมูลสำรองของคุณ เพื่อให้การกู้คืนระบบสามารถกลับมาทำงานด้วยคีย์เดิมที่เคยใช้

ไฟล์ Compose กำหนดให้ค่าทั้งสองรายการเป็นค่าบังคับด้วยรูปแบบ ${VAR:?message}: ${PG_PASS:?database password required} ในบริการ PostgreSQL และ ${AUTHENTIK_SECRET_KEY:?secret key required} ในเซิร์ฟเวอร์และ worker ซึ่งหมายความว่า Compose จะปฏิเสธการเริ่มทำงานหากไฟล์ดังกล่าวหายไป การรัน docker compose up -d จากไดเรกทอรีที่ไม่ถูกต้องจะแสดงบรรทัดข้อความเช่น required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required แล้วหยุดทำงาน ข้อความนั้นเป็นปัญหาเรื่อง path ไม่ใช่ปัญหาเรื่องการกำหนดค่า

ตัวแปรสภาพแวดล้อมที่สำคัญ

การตั้งค่าส่วนที่เหลือทั้งหมดจะอยู่ในไฟล์ .env เดียวกัน Authentik จะแปลงเครื่องหมายขีดล่างคู่ให้เป็นคีย์การตั้งค่าแบบซ้อนกัน ดังนั้น AUTHENTIK_EMAIL__HOST จึงเป็นการกำหนดค่า email.host ส่วนเครื่องหมายขีดล่างเดี่ยวจะไม่ถูกแปลงเป็นคีย์แบบซ้อน ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การตั้งค่าดูเหมือนไม่มีผลใดๆ

AUTHENTIK_BOOTSTRAP_PASSWORD ใช้กำหนดรหัสผ่านสำหรับผู้ใช้ akadmin ที่มีมาให้ในตัวเมื่อเริ่มระบบครั้งแรก เพื่อให้คุณไม่ต้องกรอกรหัสผ่านลงในแบบฟอร์มบนเว็บสาธารณะ AUTHENTIK_BOOTSTRAP_EMAIL และ AUTHENTIK_BOOTSTRAP_TOKEN ใช้กำหนดที่อยู่อีเมลและ API token ของผู้ใช้ดังกล่าวในลักษณะเดียวกัน
COMPOSE_PORT_HTTP และ COMPOSE_PORT_HTTPS ใช้เปลี่ยนพอร์ตที่เปิดใช้งานจากค่าเริ่มต้นคือ 9000 และ 9443
AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS และ AUTHENTIK_EMAIL__FROM ใช้กำหนดค่าการส่งอีเมลขาออก หากไม่มีการตั้งค่าเหล่านี้ Authentik จะพยายามใช้ localhost ที่พอร์ต 25 ส่งผลให้อีเมลรีเซ็ตรหัสผ่านเกิดข้อผิดพลาดในการเชื่อมต่อใน log ของ worker
AUTHENTIK_LOG_LEVEL=debug ใช้เปิดการแสดงรายละเอียดที่คุณต้องการในขณะที่ flow การเข้าสู่ระบบทำงานผิดพลาด อย่าลืมเปลี่ยนกลับเป็น info หลังจากเสร็จสิ้น
AUTHENTIK_ERROR_REPORTING__ENABLED มีค่าเริ่มต้นเป็น false ให้ตั้งค่าเป็น true ก็ต่อเมื่อคุณยินยอมที่จะส่งรายงานข้อผิดพลาดไปยังผู้พัฒนา

ข้อมูลเหล่านี้เป็นความลับที่อยู่ในไฟล์ข้อความธรรมดา ดังนั้นควรจัดการไดเรกทอรีดังกล่าวเช่นเดียวกับที่เก็บข้อมูลรับรองอื่นๆ การใช้โปรแกรมจัดการรหัสผ่าน เช่น instance ของ Vaultwarden ที่คุณโฮสต์เอง เป็นที่เก็บสำรองข้อมูลที่ปลอดภัยกว่าการจดบันทึกไว้ในแล็ปท็อปของคุณ

การล็อกอินครั้งแรกและบัญชีผู้ดูแลระบบ

เปิด http://SERVER_IP:9000 ในเบราว์เซอร์ Authentik จะแสดงขั้นตอนการตั้งค่าเริ่มต้นและขอให้คุณกำหนดรหัสผ่านสำหรับผู้ใช้เริ่มต้น akadmin หากคุณได้ตั้งค่า AUTHENTIK_BOOTSTRAP_PASSWORD ไว้แล้ว ขั้นตอนนี้จะเสร็จสิ้นและคุณจะเข้าสู่หน้าล็อกอินโดยตรง

สร้างผู้ใช้ระดับผู้ดูแลระบบปกติสำหรับตัวคุณเองภายใต้ Directory และ Users จากนั้นเพิ่มผู้ใช้ดังกล่าวลงในกลุ่ม authentik Admins และล็อกอินด้วยบัญชีนั้น ให้คง akadmin ไว้เป็นบัญชีฉุกเฉิน (break-glass) โดยใช้รหัสผ่านที่ยาวและเก็บไว้แบบออฟไลน์ หากขั้นตอนหรือ stage ใดๆ เกิดข้อผิดพลาดจนทำให้คุณเข้าใช้งานไม่ได้ docker compose run --rm server create_recovery_key 10 akadmin ซึ่งรันจาก /opt/authentik จะแสดงลิงก์ที่ช่วยให้คุณล็อกอินในฐานะ akadmin ได้โดยตรง ใครก็ตามที่ถือลิงก์นั้นจะมีสิทธิ์เข้าถึงเช่นเดียวกัน ดังนั้นให้ปฏิบัติต่อลิงก์นั้นเหมือนกับรหัสผ่าน การทำงานประจำวันด้วยบัญชีที่สร้างมาพร้อมระบบจะทำลายความน่าเชื่อถือของ audit log เนื่องจากทุกเหตุการณ์จะระบุว่าเป็น akadmin โดยไม่มีการระบุตัวตนที่แท้จริง ข้อโต้แย้งนี้ยังส่งผลต่อระบบที่อยู่เบื้องหลัง Authentik ด้วยเช่นกัน เช่น เครื่องมือ OneCLI แบบ self-hosted ที่ให้แต่ละคนมี agent ของตนเอง จะทิ้งร่องรอยที่ตรวจสอบได้ก็ต่อเมื่อตัวตนที่เข้าถึงระบบนั้นเป็นของบุคคลหนึ่งคน ไม่ใช่บัญชีล็อกอินที่ทั้งทีมใช้ร่วมกัน

การนำ Authentik ไปไว้หลัง reverse proxy

การเปิดพอร์ต 9000 สู่สาธารณะสามารถใช้งานได้ แต่คุณควรใช้ TLS (transport layer security) และชื่อโฮสต์จริง หากคุณใช้งานการตั้งค่าจาก Traefik ในฐานะ reverse proxy สำหรับแอป Compose หลายตัว ให้เพิ่ม Authentik เข้าไปในเครือข่ายภายนอก proxy เดียวกันโดยใช้ไฟล์ override สร้างไฟล์ docker-compose.override.yml ไว้ข้างๆ compose.yml ดังนี้:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

ปรับใช้การตั้งค่าด้วย docker compose up -d ระบบ Compose จะรวมไฟล์ override เข้าด้วยกันโดยอัตโนมัติ ทำให้บริการ server ยังคงการตั้งค่าทั้งหมดจากไฟล์หลักและได้รับ labels เพิ่มเติม ตรวจสอบด้วย curl -I https://auth.example.com/if/user/ ซึ่งควรจะตอบกลับด้วย HTTP/2 200 หากได้รับ 404 page not found จาก Traefik หมายความว่าไม่มี router ใดตรงกับคำขอนั้น ให้ตรวจสอบว่า labels ถูกนำไปใช้กับ container แล้ว, กฎ Host() ตรงกับชื่อโฮสต์อย่างถูกต้อง และคำขอถูกส่งมายัง entry point แบบ HTTPS ที่ router กำลังฟังอยู่

เมื่อชื่อโฮสต์ทำงานได้แล้ว ให้ผูกพอร์ตที่เปิดใช้งานไว้กับ 127.0.0.1 ในไฟล์ override เพื่อให้ช่องทางเดียวในการเข้าถึงคือผ่านทาง proxy เท่านั้น

การปกป้องแอปพลิเคชันด้วย forward auth

Proxy provider ของ Authentik มี 3 โหมด และการเลือกโหมดผิดอาจทำให้เสียเวลาไปเป็นชั่วโมง Proxy หมายถึงตัว outpost จะเป็นผู้ส่งต่อ traffic ไปยังแอปพลิเคชันต้นทางโดยตรง Forward auth (single application) หมายถึง reverse proxy ของคุณยังคงเป็นผู้จัดการ traffic และเพียงแค่สอบถาม Authentik ว่าคำขอนั้นผ่านการลงชื่อเข้าใช้แล้วหรือไม่ Forward auth (domain level) จะปกป้องทุกแอปภายใต้โดเมนหลักด้วย provider เดียว แต่ต้องแลกมาด้วยการที่ตั้งค่ากฎการอนุญาตสิทธิ์แยกรายแอปพลิเคชันไม่ได้ หากคุณใช้ Traefik อยู่ข้างหน้า คุณควรเลือกใช้ forward auth (single application) หากคุณต้องการแอปพลิเคชันตัวอย่างเพื่อฝึกฝน a self-hosted AFFiNE workspace เป็นตัวเลือกเริ่มต้นที่ดี เนื่องจากเป็นเครื่องมือภายในที่คุณต้องการให้เข้าถึงได้จากอุปกรณ์ของคุณเองเท่านั้น และยิ่งจำเป็นมากขึ้นสำหรับเครื่องมือที่ใช้ในทีม: หากคุณนำ a self-hosted Chatwoot support desk ไปไว้หลัง provider เดียวกัน ทุกคนที่ตอบแชทจะลงชื่อเข้าใช้เพียงครั้งเดียวต่อวัน แทนที่จะต้องแชร์รหัสผ่านเพิ่มอีกหนึ่งชุด

ในหน้าเว็บอินเทอร์เฟซ ให้เปิด Applications แล้วไปที่ Providers จากนั้นสร้าง Proxy Provider เลือกโหมด forward auth single application และตั้งค่า external host เป็น https://app.example.com สร้าง Application ที่ชี้ไปยัง provider นั้น จากนั้นเปิด Outposts แก้ไข authentik Embedded Outpost และย้ายแอปพลิเคชันใหม่เข้าไปในรายการ selected applications ของ outpost นั้น ตัว outpost จะตอบสนองเฉพาะแอปพลิเคชันที่ได้รับมอบหมายเท่านั้น ดังนั้นการข้ามขั้นตอนสุดท้ายนี้จึงเป็นสาเหตุที่ทำให้ provider ที่ตั้งค่าไว้อย่างถูกต้องยังคงไม่แสดงผลใดๆ

กำหนด middleware ไว้ที่เดียวในคอนเทนเนอร์ของ Authentik และอ้างอิงจากทุกแอปพลิเคชันที่ต้องการปกป้อง:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-entitlements,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders คือรายการ header ที่ Traefik จะคัดลอกจากคำตอบของ Authentik ไปยังคำขอที่ส่งไปยังแอปพลิเคชันต้นทาง หากละเว้นส่วนนี้ แอปพลิเคชันจะยังคงถูกปกป้องอยู่ แต่จะไม่ทราบว่าผู้ใช้คือใคร ดังนั้นแอปพลิเคชันใดก็ตามที่อ่านค่า X-authentik-username เพื่อลงชื่อเข้าใช้อัตโนมัติจะยังคงอยู่ในสถานะไม่ได้ลงชื่อเข้าใช้ ช่องว่างนี้จะเห็นได้ชัดเจนที่สุดเมื่ออยู่หน้าแอปพลิเคชันที่มีระบบลงชื่อเข้าใช้ของตนเอง เช่น a self-hosted openGym workout tracker และระบบ passkey login ของมัน ซึ่ง header เหล่านี้คือสิ่งที่ตัดสินว่าคุณจะต้องกรอกข้อมูลเพียงครั้งเดียวหรือสองครั้งสำหรับหน้าเดิม

ตัวแอปพลิเคชันที่ถูกปกป้องจำเป็นต้องมี router สองตัว ไม่ใช่ตัวเดียว:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

router ตัวที่สองคือส่วนที่ทุกคนมักลืม หลังจากลงชื่อเข้าใช้แล้ว Authentik จะส่งเบราว์เซอร์กลับไปยัง path ภายใต้ /outpost.goauthentik.io/ บน hostname ของ แอปพลิเคชัน ไม่ใช่บน auth.example.com หากไม่มี router ที่ส่ง path prefix นั้นไปยังบริการของ Authentik คำขอจะไปตกที่แอปพลิเคชันของคุณ ซึ่งจะตอบกลับเป็น 404 และการลงชื่อเข้าใช้จะไม่เสร็จสมบูรณ์ ค่า priority ที่สูงกว่าคือสิ่งที่ทำให้กฎของ path เฉพาะเจาะจงนี้มีลำดับความสำคัญเหนือกว่ากฎ Host() ทั่วไปบนโดเมนเดียวกัน

ทดสอบในหน้าต่างเบราว์เซอร์แบบส่วนตัว คุณควรถูกส่งไปยัง auth.example.com เพื่อลงชื่อเข้าใช้ และกลับมายังแอปพลิเคชัน docker compose logs -f server ในฝั่งของ Authentik จะแสดงเหตุการณ์การอนุญาตสิทธิ์ในทุกความพยายาม ซึ่งจะบอกคุณว่าคำขอนั้นมาถึง Authentik หรือไม่

ข้อผิดพลาดที่คุณจะพบจริง

เกิดวงจรการ redirect ไม่สิ้นสุดระหว่างแอปพลิเคชันกับหน้าล็อกอิน โฮสต์ภายนอกที่ตั้งค่าไว้ในผู้ให้บริการไม่ตรงกับที่เบราว์เซอร์ใช้งาน โดยปกติเกิดจาก http:// ในผู้ให้บริการไม่ตรงกับ https:// ในแถบที่อยู่ของเบราว์เซอร์ ทำให้ session cookie ถูกตั้งค่าสำหรับ origin ที่ต่างออกไป ทุกครั้งที่วนกลับมาจึงดูเหมือนเป็นคำขอใหม่จากผู้ใช้ที่ไม่ระบุตัวตน ให้แก้ไขโฮสต์ภายนอกและล้างคุกกี้ของทั้งสองโดเมนก่อนทดสอบใหม่

เกิดข้อผิดพลาด 404 ที่ /outpost.goauthentik.io/start ตัว outpost router หายไป หรือมีลำดับความสำคัญต่ำกว่า catch-all router ของโฮสต์นั้น

แอปพลิเคชันโหลดขึ้นมาโดยไม่ถามหาการล็อกอิน ป้ายกำกับ middlewares ระบุชื่อ middleware ที่ไม่มีอยู่จริง Traefik จะไม่แจ้งเตือนเกี่ยวกับเรื่องนี้ ดังนั้นการพิมพ์ผิดใน authentik@docker จึงหมายความว่าไม่มี middleware ใดทำงาน ให้เปิด Traefik dashboard แล้วตรวจสอบว่า router แสดงรายการ middleware นั้นอยู่หรือไม่

เกิดข้อผิดพลาด 403 จาก Authentik หลังจากล็อกอินสำเร็จ ผู้ใช้ผ่านการยืนยันตัวตนแล้วแต่ไม่ได้รับอนุญาต: แอปพลิเคชันมีการผูกนโยบาย (policy binding) หรือข้อกำหนดกลุ่มที่ผู้ใช้รายนี้ไม่ผ่านเกณฑ์ บันทึก Events ในหน้าอินเทอร์เฟซผู้ดูแลระบบจะระบุชื่อนโยบายที่ปฏิเสธการเข้าถึงนั้นไว้

เมื่อ Keycloak เป็นตัวเลือกที่เหมาะสมกว่า

Keycloak เป็นโครงการที่มีมานานกว่าและได้รับการสนับสนุนจาก Red Hat จึงเป็นตัวเลือกที่แข็งแกร่งกว่าสำหรับงานด้านการจัดการตัวตนในระดับองค์กรแบบดั้งเดิม เช่น การทำ SAML federation ขนาดใหญ่, การทำ brokering เพื่อล็อกอินจากผู้ให้บริการตัวตนภายนอกหลายแห่งพร้อมกัน และการส่งออกหรือนำเข้า realm ซึ่งมีเส้นทางการย้ายข้อมูลที่ชัดเจน การมีบริการสนับสนุนเชิงพาณิชย์รองรับเป็นสิ่งที่องค์กรบางแห่งให้ความสำคัญในเชิงเอกสาร อย่างไรก็ตาม ข้อแลกเปลี่ยนคือ Keycloak ไม่มี proxy ในตัว ดังนั้นการปกป้องแอปพลิเคชันที่ไม่รองรับทั้ง OIDC (OpenID Connect) และ SAML จึงจำเป็นต้องใช้งานเครื่องมืออย่าง oauth2-proxy ควบคู่ไปด้วย ในขณะที่ Authentik มี proxy provider ในตัวซึ่งรวมมาให้พร้อมใช้งานแล้ว นี่จึงเป็นเหตุผลที่ผู้ใช้งานแบบ self-host ส่วนใหญ่ที่มีแอปพลิเคชันหลากหลายประเภทเลือกใช้ Authentik

การสำรองข้อมูลและการอัปเกรด

สามสิ่งที่ทำให้การกู้คืนระบบเป็นไปได้คือ: ฐานข้อมูล PostgreSQL, ไดเรกทอรี ./data และ .env

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

จัดเก็บไฟล์ dump นั้นและ .env ไว้ด้วยกัน ไฟล์ dump ไม่มีสำเนาของ AUTHENTIK_SECRET_KEY และการกู้คืนด้วยคีย์ที่ต่างออกไปจะทำให้ทุก session ที่ใช้งานอยู่สิ้นสุดลง ดังนั้นการเก็บคีย์เดิมไว้จะช่วยให้เซิร์ฟเวอร์ที่กู้คืนมาทำงานต่อได้เหมือนเดิม

การอัปเกรดคือการเปลี่ยน tag ตั้งค่า AUTHENTIK_TAG ใน .env เป็นรุ่นที่คุณต้องการ จากนั้นรัน docker compose pull ตามด้วย docker compose up -d หากคุณไม่เคยตั้งค่า AUTHENTIK_TAG เวอร์ชันจะถูกดึงมาจากค่าเริ่มต้นที่เขียนไว้ใน compose.yml เอง ดังนั้นการดาวน์โหลดไฟล์เวอร์ชันใหม่มาแทนที่คือวิธีการอัปเกรด ซึ่งเป็นเส้นทางที่เอกสารการอัปเกรดอย่างเป็นทางการระบุไว้ โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อน Authentik ใช้เวอร์ชันตามวันที่ และ ณ เดือนตุลาคม 2026 เอกสารระบุว่าการอัปเกรดต้องเป็นไปตามลำดับของรุ่นหลัก: ให้ย้ายไปยัง patch ล่าสุดของซีรีส์ที่คุณใช้งานอยู่ จากนั้นค่อยๆ อัปเกรดผ่านแต่ละซีรีส์ถัดไปตามลำดับโดยไม่ข้ามรุ่น Authentik ไม่รองรับการดาวน์เกรด ดังนั้นให้ทำ database dump ก่อนการ pull ไม่ใช่หลังจากนั้น

FAQ

Authentik สามารถ self-host ได้ฟรีหรือไม่?

รุ่น open source นั้นเปิดให้ใช้งานได้ฟรีและครอบคลุมฟีเจอร์ทั้งหมดที่กล่าวมาข้างต้น ไม่ว่าจะเป็น proxy provider, forward auth, OIDC (OpenID Connect), SAML และ flows engine สำหรับรุ่น enterprise จะมีค่าใช้จ่ายเพิ่มเติมเพื่อแลกกับการสนับสนุนทางเทคนิคและฟีเจอร์เฉพาะสำหรับองค์กร แต่ฟีเจอร์ทั้งหมดที่กล่าวถึงในที่นี้ไม่จำเป็นต้องใช้ใบอนุญาต (licence)

จำเป็นต้องใช้ Traefik เพื่อใช้งาน Authentik หรือไม่?

ไม่จำเป็น Forward auth สามารถทำงานร่วมกับ nginx ผ่าน auth_request และกับ Caddy ผ่าน forward_auth ได้ รูปแบบการทำงานจะเหมือนกันในทุกกรณี คือ reverse proxy จะสอบถาม Authentik เกี่ยวกับคำขอแต่ละรายการ และ path prefix /outpost.goauthentik.io/ บน hostname ที่ได้รับการป้องกันจะต้องส่งคำขอไปยัง Authentik แทนที่จะส่งไปยังแอปพลิเคชันโดยตรง

ทำไมแอปพลิเคชันที่ป้องกันไว้ถึงวนลูปอยู่ระหว่างหน้าล็อกอินกับหน้าแจ้งเตือนข้อผิดพลาดตลอดเวลา?

สาเหตุเกิดจาก external host ที่กำหนดค่าไว้ใน proxy provider ไม่ตรงกับ URL ที่เบราว์เซอร์ใช้งานอยู่ ซึ่งมักเกิดจากการใช้ http เทียบกับ https ทำให้ session cookie ถูกออกให้สำหรับ origin หนึ่งแต่ถูกอ่านในอีก origin หนึ่ง Authentik จึงมองเห็นคำขอเป็นแบบไม่ระบุตัวตน (anonymous) อยู่ตลอดเวลา ให้แก้ไข external host ให้ถูกต้อง จากนั้นล้างคุกกี้ของทั้งสอง hostname ก่อนเริ่มทดสอบใหม่อีกครั้ง

Authentik ต้องการ RAM เท่าไร?

ข้อกำหนดขั้นต่ำอย่างเป็นทางการคือ CPU 2 คอร์ และ RAM 2 GB (ข้อมูล ณ เดือนตุลาคม 2026) ซึ่งครอบคลุมทั้ง PostgreSQL, ตัวเซิร์ฟเวอร์ และ worker หากใช้งานบนเครื่องที่มี RAM 2 GB แรงกดดันด้านหน่วยความจำอาจทำให้ OOM killer ของ kernel ทำงาน ซึ่งจะยุติกระบวนการที่มีค่า badness score สูงสุด โดยพิจารณาจากสัดส่วนหน่วยความจำที่ได้รับอนุญาตที่ใช้ไปรวมกับค่า oom_score_adj ของกระบวนการนั้น หากกระบวนการที่ถูกยุติคือ worker อาการที่พบคืองานเบื้องหลังและอีเมลขาออกจะหยุดทำงาน ในขณะที่หน้าล็อกอินยังคงใช้งานได้ตามปกติ แนะนำให้จัดสรร RAM 4 GB หากเซิร์ฟเวอร์เดียวกันนั้นต้องรันแอปพลิเคชันที่คุณต้องการป้องกันด้วย

บทความนี้มีประโยชน์หรือไม่

#authentik #sso #authentication #self-hosting #docker-compose #traefik