การรับรองความถูกต้อง CLI อย่างถูกวิธี: คู่มือฉบับสมบูรณ์สำหรับทั้ง 4 วิธี

นักพัฒนา CLI ทุกคนจะมี login เป็นคำสั่งแรก และแต่ละตัวก็แก้ปัญหาการรับรองตัวตนแตกต่างกัน

GitHub จะแสดงโค้ดพร้อมเปิดเบราว์เซอร์ให้คุณยืนยัน, AWS จะเปิดเบราว์เซอร์เพื่อใช้ PKCE-based SSO, Stripe ให้คุณยืนยัน pairing code ใน dashboard และเครื่องมือ AI รุ่นใหม่ (Claude Code, OpenAI Codex CLI, Cursor) ก็มีวิธีของตัวเองด้วย

ถ้าคุณกำลังสร้าง CLI ใหม่ เรื่อง auth เป็นสิ่งที่คุณต้องคิดก่อนเป็นอันดับต้น ๆ เลือกผิดอาจโดนผู้ใช้งานบ่น, โดนตรวจสอบความปลอดภัย หรือทั้งคู่ และยุค AI coding agent ที่เรียก CLI แบบอัตโนมัติ ยิ่งต้องระวังให้มากขึ้น: คุณไม่ได้แค่ยืนยันตัวคนแล้ว แต่อาจยื่นข้อมูลรับรองให้งานอัตโนมัติด้วย

นี่คือ 4 วิธีสำคัญในการรับรองความถูกต้อง, ตัวอย่างการนำไปใช้จากเครื่องมือยอดนิยม และข้อผิดพลาดที่ควรหลีกเลี่ยง

มองภาพรวมทั้งสี่วิธี#

ก่อนลงรายละเอียด มาดูตารางเปรียบเทียบสั้น ๆ กันก่อน:

แต่ละแบบมีข้อดีข้อเสียต่างกัน มาดูรายละเอียดกัน

1. OAuth device code flow (RFC 8628)#

แบบนี้ CLI จะโชว์โค้ดเช่น ABCD-1234 และ URL แล้วบอกให้คุณเปิด URL นี้บนอุปกรณ์ใดก็ได้ กรอกโค้ดนั้น

ใครใช้: GitHub CLI (ดีฟอลต์), Azure CLI (ผ่าน --use-device-code), Vercel CLI (เปลี่ยนมาเป็นดีฟอลต์ล่าสุด), OpenAI Codex CLI (เบต้า)

วิธีการทำงาน#

1. คุณรัน cli login
2. CLI ขอ device code จาก auth server, ส่ง client_id และ scope ที่ต้องการไปด้วย
3. Server ส่งกลับมาสามอย่าง: device_code (รหัสภายใน), user_code (โค้ดสั้นให้ผู้ใช้กรอก), และ verification_uri (URL สำหรับยืนยัน)
4. CLI แสดงโค้ดกับ URL แล้วเริ่ม polling ที่ auth server ทุก ๆ 5+ วินาที
5. คุณเปิด URL นั้นบนอุปกรณ์ ใดก็ได้ (มือถือ, แลปท็อป, คอมฯ อีกเครื่อง), กรอกโค้ด, login แบบไหนก็ได้ (พาสเวิร์ด, SSO, passkey, MFA)
6. เมื่อคุณกด approve, polling ครั้งถัดไปจะได้ access token กับ refresh token กลับมา
7. CLI เก็บ token เหล่านี้ไว้ เรียบร้อย

ข้อดีสำหรับนักพัฒนา#

จุดขาย: ใช้ได้กับทุกที่ SSH เข้าเซิร์ฟเวอร์? ได้ รันใน Docker? ได้ Cloud IDE ที่ไม่เปิดเบราว์เซอร์? ก็ได้ ไม่ต้องขอเบราว์เซอร์บนเครื่องเดียวกันกับ CLI

ยังรองรับ enterprise auth เต็มรูปแบบ (SAML, OIDC, MFA) เพราะทุกอย่างเกิดในเบราว์เซอร์ ไม่ใช่ในเทอร์มินัล CLI ไม่เห็นรหัสผ่านของคุณเลย

ช่องโหว่ที่นักพัฒนามักมองข้าม#

Device code flow คือเป้าของการ phishing ผู้ไม่หวังดีสามารถสร้าง request เพื่อ device code, ได้ user code แบบถูกต้อง แล้วหลอกให้คุณนำไปกรอก ซึ่งเท่ากับคุณ authorize session ของคนร้าย มีรายงานการโจมตีแบบนี้กับ AWS SSO device code แล้วจริง ๆ

จุดนี้ AWS เปลี่ยนนโยบาย โดยตั้งแต่ AWS CLI v2.22.0 ดีฟอลต์ของ aws sso login จะกลายเป็น PKCE-based authorization code flow แทน แต่ device code ยังมีอยู่ผ่าน --use-device-code แค่ไม่ใช่ default

ขณะที่ฝั่ง Microsoft เริ่ม block device code flow ผ่าน conditional access policy แล้ว แสดงว่าพวกเขามองว่านี่คือตัวเลือกความเสี่ยงสูง

สั้น ๆ คือ: Vercel นำ device code flow มาใช้เป็นดีฟอลต์ใน ก.ย. 2025 ส่วน AWS เลิกใช้ เป็นดีฟอลต์ เหมาะกับกรณีที่เปิดเบราว์เซอร์ local ไม่ได้จริง ๆ ถ้าเปิดได้ PKCE ปลอดภัยกว่าเยอะ

สำหรับฝั่งผู้ให้บริการ auth ตัวเลือกนี้กำลังนิยม Logto เพิ่งปล่อย OAuth 2.0 Device Authorization Grant ให้ใช้กับ native app แล้วใน v1.38.0 (open source) และ Logto Cloud ถ้าคุณกำลังสร้าง CLI อยู่ ให้ provider จัดการ logic ให้นั้นสะดวกกว่า เพราะการทำ RFC 8628 ให้ครบถ้วน (หมดอายุ, จำกัด rate, polling, UX ที่หน้า verification) ไม่ง่าย

รายละเอียดเทคนิคจาก RFC#

• expires_in ของ device code ถูกกำหนดโดย auth server ตัว RFC เสนอ 1800 วินาที (30 นาที) เป็นตัวอย่าง ไม่จำเป็นต้องยึดตามนี้
• ถ้า server ไม่บอก polling interval, client ควร default เป็น 5 วินาที
• ถ้าเจอ error slow_down, เพิ่ม interval อีก 5 วินาที
• device code ใช้ได้ครั้งเดียวและควรหมดอายุไว
• การแลกเปลี่ยน token ทั้งหมดต้องผ่าน HTTPS

2. OAuth ผ่านเบราว์เซอร์ (localhost redirect)#

นี่คือวิธีที่นิยมที่สุดสำหรับ CLI ที่รันบนเครื่องนักพัฒนาเอง คุณรัน login, แอปเปิดเบราว์เซอร์, login เสร็จ browser redirect กลับไปที่ localhost ที่ CLI เปิดไว้ สมัยนี้จะใช้ PKCE (อ่านว่า "pixie") เพิ่มเข้ามา ทำให้การโจมตีทำได้ยากขึ้นมาก

ใครใช้: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (ใช้ PKCE SSO เป็นดีฟอลต์)

วิธีการทำงาน#

1. คุณรัน cli login
2. CLI สปิน HTTP server ชั่วคราวบนพอร์ต local สุ่ม ๆ (เช่น http://127.0.0.1:8742)
3. มันจะเปิดเบราว์เซอร์ไปที่ authorization endpoint พร้อม redirect URI เป็น localhost URL นั้น
4. คุณ login ในเบราว์เซอร์ (SSO, พาสเวิร์ด, passkeys, ฯลฯ)
5. Auth provider redirect เบราว์เซอร์มาที่ http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
6. local server จับ authorization code ไว้, แลกเปลี่ยนเป็น token ผ่าน HTTPS
7. เบราว์เซอร์โชว์หน้า "Success! You can close this tab"
8. CLI เก็บ token แล้วปิด server

UX สมูธมาก ไม่ต้อง copy code ไม่ต้องพิมพ์ URL อะไรเลย

ข้อจำกัด#

วิธีนี้จะใช้ได้เฉพาะเมื่อ CLI เปิดเบราว์เซอร์และ bind localhost ได้เท่านั้น ซึ่งแปลว่าใช้ไม่ได้ในกรณีต่อไปนี้:

• SSH เข้าเซิร์ฟเวอร์ระยะไกล
• Docker container (เว้นแต่จะฝ่า port forwarding)
• CI/CD pipeline
• เซิร์ฟเวอร์ headless
• บางระบบองค์กรที่จำกัด

จึงเห็นว่าเครื่องมือบางตัวที่ default เป็น browser OAuth มักจะมี fallback เช่น device code หรือ API key ด้วย

สามข้อผิดพลาดด้านความปลอดภัยที่เจอบ่อยมาก#

ข้อผิดพลาด 1: Bind ที่ 0.0.0.0 แทน 127.0.0.1

พบได้บ่อยและร้ายแรง เพราะ bind ที่ 0.0.0.0 ใครในวงแลนก็ดัก code ได้

เคยเห็น production CLI ทำผิดแบบนี้บ่อยมาก เพราะไลบรารี HTTP หลายตัว default เป็น 0.0.0.0

ข้อผิดพลาด 2: ไม่ตรวจสอบ state parameter

state คือการป้องกัน CSRF ถ้าขาดนี้ คนร้ายอาจหลอก CLI ให้รับ authorization code จาก session ปลอม

ข้อผิดพลาด 3: ไม่ใช้ PKCE

ถ้า flow OAuth ของคุณไม่ใช้ PKCE (Proof Key for Code Exchange), authorization code ที่ถูก intercept สามารถถูกนำไปแลก token ได้เลย

ใน standard code flow ถ้าโดนดักรหัส code (เช่นจาก redirect URL), จะแลก token ได้ PKCE ป้องกันนี้ด้วยการพิสูจน์ว่าทีมเดียวกับที่เริ่ม flow เท่านั้นที่แลกได้

PKCE เพิ่ม flow นี้เข้าไป:

1. ก่อนเริ่ม CLI สร้าง code_verifier (random string ระดับ entropy สูง)
2. แฮช verifier นี้ด้วย SHA-256 ออกมาเป็น code_challenge
3. ส่ง challenge ไปกับ authorization request แรก
4. ตอนแลก token, CLI จะส่ง code_verifier กลับไป
5. Auth server ตรวจสอบว่าตรงกับ challenge

คนร้ายที่ intercept code ไม่มี code_verifier ก็จบ

นี่คือเหตุผลที่ AWS CLI v2.22+ เปลี่ยน default SSO เป็น PKCE browser OAuth+PKCE ดีกว่า device code flow ทั้ง UX และความปลอดภัย ฟิชชิ่งก็หมด Device code flow เหมาะกับกรณีที่เบราว์เซอร์ไม่ได้อยู่บนเครื่องเดียวกับ CLI (SSH, container, remote dev) ส่วน local development ใช้ PKCE ดีกว่า

3. API keys และ personal access tokens#

วิธีที่ง่ายที่สุด: สร้าง token ที่ dashboard, นำไปวางใน config CLI หรือ environment variable ก็ใช้ได้ทันที

ใครใช้: Stripe CLI (เป็นหนึ่งใน login option), npm, pip, AI coding tools ส่วนใหญ่ (Claude Code ใช้ ANTHROPIC_API_KEY, OpenAI ใช้ OPENAI_API_KEY, Aider)

วิธีการทำงาน#

1. Login ที่ dashboard เว็บ
2. ไปที่เมนู settings → API keys (หรือ personal access tokens, developer tokens)
3. สร้าง key ใหม่ ปกติจะเป็นสตริงยาว ๆ มี prefix (เช่น sk_live_, ghp_, npm_)
4. เก็บไว้ในไฟล์ config (~/.config/stripe/config.toml, ~/.aws/credentials) หรือ environment variable

CLI จะอ่านและส่งเป็น header Authorization: Bearer ใน request

ทำไมจึงนิยม แม้จะมีความเสี่ยง#

สำหรับ automation, API key ใช้ง่ายมาก CI/CD, container, script, cron job แค่ set env var ก็จบ ไม่ต้องใช้ browser ไม่ต้องมี prompt ไม่ต้อง refresh token อะไรทั้งนั้น

สำหรับ workflow แบบ AI agent, API key นี่แหละง่ายสุด Claude Code หรือ Cursor ที่ต้อง call API ผ่าน CLI แค่มี env var ก็โหลดได้

ความเสี่ยงมีจริง#

• หลุดง่าย. API key มักหลุดไปอยู่ใน commit, log, error message, CI output GitHub สแกน token เผยแพร่ได้เป็นล้าน ๆ ต่อปี
• ขอบเขตกว้างเกิน. Key ส่วนมากสิทธิ์เยอะ ถ้ารั่วคือเสียหายเยอะ
• ไม่มี MFA. API key ข้าม multi-factor auth ไปหมด
• หมุนไม่ง่าย. หมุน key ที ต้อง update ทุกจุดที่ใช้ โดยเฉพาะในทีม กลายเป็นปัญหาประสานงาน

วิธีสมัยใหม่: แลกเป็น token ชั่วคราว#

ถ้าต้องใช้ API key, ให้แลกเป็น token อายุสั้นที่ runtime เช่นที่ AWS ทำด้วย STS (Security Token Service) ใช้ credential ตัวจริงเพื่อขอ credential ชั่วคราวอายุ 1 ชั่วโมง มี aws-vault ทำให้อัตโนมัติ

ถึงจะเริ่มด้วย API key ก็ลองเพิ่มวิธีนี้ไว้ด้วย เพื่อจำกัดระยะเวลาความเสียหายจาก "จนกว่าจะถูกตรวจพบ" เหลือแค่ "1 ชั่วโมง"

4. Client credentials flow#

OAuth 2.0 flow แบบนี้ออกแบบมาเพื่อการยืนยันตัวตนระหว่างเครื่องกับเครื่อง: service คุยกับ service ไม่มี user

ใช้กับ: CI/CD pipeline, บริการ background, เครื่องมือ automation

วิธีการทำงาน#

service ส่ง client_id กับ client_secret ไปตรง ๆ กับ auth server ได้ access token อายุสั้นกลับมา ไม่ต้องใช้เบราว์เซอร์ ไม่ต้องมี user ไม่ต้อง redirect

ใช้เมื่อไร#

เหมาะเมื่อ:

• มี service หรือ bot ต้อง authenticate ไม่ใช่ผู้ใช้คน
• ทำงานใน CI/CD pipeline
• ต้องการ access แบบอัตโนมัติ
• "user" คือแอปเอง

อย่าใช้สำหรับผู้ใช้จริง เพราะไม่มี MFA, SSO หรือ verification แบบโต้ตอบ

เครื่องมือ CLI จริงใช้อะไรบ้าง#

อันนี้คือตารางสรุปที่อัปเดตล่าสุด อ้างอิงจากเอกสารและโค้ดจริง หลายเว็บไซต์เขียนผิดเพราะค่า default เปลี่ยนบ่อยมาก

แนวโน้ม: browser-based OAuth เป็นดีฟอลต์สำหรับ local, fallback เป็น device code สำหรับ headless และ API key สำหรับ automation PKCE ได้รับความนิยมเพิ่มขึ้นเพราะปลอดภัยสูงสุดถ้ามีเบราว์เซอร์

การเก็บ token: ทำอย่างไรและควรหลีกเลี่ยงอะไร#

ต่อให้ auth ดีแค่ไหน ถ้าเก็บ token ผิดก็จบ

ทางที่ถูก: OS keychain#

ทุกระบบ OS มี credential store แบบเข้ารหัสในตัว:

• macOS: Keychain (ใช้กับ GitHub CLI, Claude Code)
• Windows: Credential Manager
• Linux: Secret Service API (GNOME Keyring, KDE Wallet)

ปลอดภัย, มีฮาร์ดแวร์ช่วย, Control permissions ได้, CLI ไม่ต้องสร้าง crypto เอง

ทางรอง: ไฟล์ config เข้ารหัส Permission เข้มงวด#

หากใช้ keychain ไม่ได้ (container, Linux มินิมอล) ให้ใช้ไฟล์ config ที่ permission limit สุด ๆ

ควรหลีกเลี่ยง#

ไฟล์ plaintext. ฟังดูง่าย แต่หลายเครื่องมือยังทำอยู่ ทุก process ที่ใช้งาน user เดียวกัน/back up/แม้แต่แค่คนอื่นนั่งเครื่องก็เปิดดูได้หมด

Environment variable แบบเก็บระยะยาว. Env var โชว์ใน process listing, ฝังใน log/crash dump/child process, เหมาะกับ CI/CD (ที่ secret ถูกจัดการโดยแพลตฟอร์ม) แต่ไม่ควรใช้กับ local

Browser localStorage. ถ้า CLI ของคุณมี web component อย่าเก็บ token ใน localStorage ช่องโหว่ XSS รั่วหมด

การจัดการอายุการใช้งาน Token#

Access tokens#

ควรอายุสั้น (1 ชั่วโมงเป็นมาตรฐาน) เมื่อหมดอายุ CLI ควร refresh เองโดย user ไม่ต้อง re-login

Refresh tokens#

Refresh token เป็นรหัสระยะยาวสำหรับขอ access token ใหม่โดยไม่ต้องยืนยันใหม่ มูลค่าสูงสำหรับคนร้าย (เพราะอายุนาน)

การหมุน refresh token#

ระบบ auth สมัยใหม่จะหมุน refresh token ทุกครั้งที่ใช้:

1. CLI ส่ง refresh token ขอ access token ใหม่
2. Auth server คืน access token และ refresh token ใหม่ กลับมา
3. refresh token เดิมหมดอายุทันที
4. CLI เก็บ token ชุดใหม่ทั้งคู่

ถ้า refresh token โดนขโมย แล้วเจ้าของที่ถูกต้องใช้ก่อน หน้า server เจอ token reuse จะรีเซ็ตทั้งชุด (ทั้งของโจรและของ user จริง) บังคับ re-auth ป้องกันคนร้ายรักษา session ไว้ได้

Common pitfalls (พร้อมโค้ด)#

1. คอลแบ็กเซิร์ฟเวอร์ bind ที่ network ทั้งหมด#

ย้ำอีกที: bind ที่ 127.0.0.1 เท่านั้น อย่าใช้ 0.0.0.0

2. Logging token#

เกิดขึ้นบ่อยอย่างไม่น่าเชื่อ debug log/error มัก log header รวม token ไปและสุดท้ายก็โผล่ใน Slack

3. กลั่น credential ลง Docker image#

Docker image ไม่ใช่ที่เก็บความลับ ทุกเลเยอร์แตกไฟล์ดูได้หมด

4. ไม่ handle token หมดอายุอย่างถูกต้อง#

ถ้า token หมดอายุระหว่างใช้งาน อย่าให้ crash 401 ดื้อ ๆ ควรลอง refresh ดูก่อน ถ้า refresh ก็หมดด้วยค่อยบังคับ login ใหม่

5. ไม่สนใจหลัก least privilege#

อย่าไปขอ scope admin:* ถ้าต้องการแค่ repo:read ทั้ง OAuth scope และ API key

ถ้า AI agent ใช้ CLI ของคุณยิ่งสำคัญ อย่าให้สิทธิ์มากกว่ารีดจริง ให้แค่พอใช้งาน

ประเด็นใหม่เมื่อ AI agent เข้ามา#

นี่คือสิ่งที่ทำให้ปี 2026 ไม่เหมือนปี 2023: CLI ไม่ใช่แค่คนพิมพ์แล้วตอนนี้ AI coding agent อย่าง Claude Code, Codex, Cursor agent mode เรียก CLI อัตโนมัติ ทำให้เรื่อง auth ยากขึ้น

Delegated permissions. เมื่อ Claude Code รัน gh pr create แทนคุณ มันใช้ credential ของ คุณ แต่ควรหรือไม่ที่ agent จะได้สิทธิ์เท่าคุณ? หลัก least privilege ตอบว่าไม่ควร แต่เครื่องมือส่วนใหญ่ยังไม่มีฟีเจอร์คุมขอบเขตสิทธิ์ agent แยก

Credential exposure. ถ้า API key อยู่ใน env var ทุก process ใน environment นั้นอ่านได้หมด รวมถึง subprocess ของ AI agent Claude Code บางตัวแก้ด้วย apiKeyHelper ที่ generate token อายุน้อย on demand แต่ยังไม่เหมือนกันหมด

Headless auth สำหรับ agent. AI agent ใน sandbox เปิดเบราว์เซอร์ไม่ได้ device code flow ใช้ได้ (คนไป approve บนอุปกรณ์อื่น) แต่ API key นิยมเพราะไม่ต้องโต้ตอบใด ๆ

Audit trail. ถ้า agent เรียก API ด้วย credential ของคุณ log จะโชว์ว่า คุณ เป็นคนทำ ไม่มีวิธีแยกว่า "มนุษย์ทำ" หรือ "agent ทำแทนมนุษย์"

ข้อปฏิบัติ:

• ใช้ token ที่ขอบเขตแคบกับ agent
• เลือก token อายุน้อย (temporary token แทนที่ API key ยาว)
• ใช้ credential แยกเฉพาะ agent กับ credential ส่วนตัว
• มอนิเตอร์การใช้งาน API

Framework ช่วยตัดสินใจ#

จะเลือกวิธี auth แบบไหน อ่านสรุปสั้นต่อไปนี้ได้เลย:

"ผู้ใช้ของฉันคือ dev บนเครื่อง local" → ใช้ browser-based OAuth + PKCE (ปลอดภัยสุด + UX ดียอด)

"CLI ต้องใช้ได้ใน SSH หรือ container" → Device code เป็น fallback, browser OAuth เป็นหลัก

"รันใน CI/CD แบบไม่มีมนุษย์" → Client credentials flow หรือ API key แบบ limit ขอบเขต

"ขอติดตั้งเร็วสุด" → API key (แต่เพิ่ม token rotation ทีหลัง)

"ลูกค้าองค์กรต้อง SSO กับ MFA" → OAuth flow อะไรก็ได้ (device code หรือ browser) รองรับ auth สำหรับองค์กร

"AI agent จะใช้ CLI ตัวนี้" → รองรับ API key (สำหรับ agent) + browser OAuth (สำหรับคน), จำกัดขอบเขต permission และใช้ token อายุน้อย

FAQ#

Device code flow ปลอดภัยไหม?#

ปลอดภัยกับโจมตีส่วนใหญ่ แต่มีช่องโหว่ phishing คือโจรสร้าง device code แล้วหลอกให้ user authorize ซึ่ง AWS จึงเปลี่ยน default SSO เป็น PKCE แต่กรณีที่ PKCE ใช้ไม่ได้ device code ก็ยังดีที่สุด เพียงแต่ต้องตระหนักเรื่อง phishing

ควรเก็บ token ใน environment variable หรือไม่?#

บน CI/CD: ได้ เพราะ platform จัดการ secret เข้ารหัส inject ให้เอง แต่ local ไม่ควร ควรใช้ OS keychain ดีกว่า เพราะ env var มองเห็นได้ใน process list, log, และลูก process อื่น

ต่างกันอย่างไรระหว่าง API key กับ personal access token#

ฟังก์ชันเหมือนกัน ต่างแค่ชื่อและวิธีจัดการ API key จะผูกกับโปรเจคหรือแอป ส่วน PAT ผูกกับผู้ใช้ บางเจ้าสลับใช้ชื่อกัน

ควรหมุน credential บ่อยแค่ไหน#

Access token: ทุก 1 ชั่วโมงหรือน้อยกว่า (token refresh flow จัดการ) Refresh token: หมุนทุกครั้งที่ใช้ (auth server จัดการ) API key: อย่างน้อยทุก 90 วัน หรือทันทีที่สงสัยว่าหลุด ในทางปฏิบัติมักหมุนหลังเกิดเรื่อง ซึ่งช้าเกินไป

Auth ใน Docker container ทำอย่างไร#

3 ตัวเลือก อันดับความปลอดภัย:

1. Device code flow สำหรับ interactive (เบราว์เซอร์อาจรันที่อื่นได้)
2. Environment variable ตอน runtime (docker run -e API_KEY=${API_KEY}) สำหรับ CI/CD
3. Volume-mounted credential (docker run -v ~/.config/tool:/root/.config/tool:ro) สำหรับ development

อย่าฝัง credential ลงใน image เด็ดขาด

แล้ว MCP (Model Context Protocol) authentication ล่ะ?#

MCP คือมาตรฐานใหม่สำหรับ AI agent เชื่อมต่อกับเครื่องมือ/บริการภายนอก มุม auth คือ agent ต้องใช้ credential กับ MCP server ซึ่งเองก็ต้องใช้ credential กับ downstream API ตอนนี้มักใช้ API key หรือ OAuth token ผ่าน config อยู่ กำลังพัฒนาอยู่เร็วมาก

---

CLI auth กำลังเปลี่ยนไวมาก สิ่งที่เคยเป็น best practice เมื่อสองปีก่อน (device code flow ดีฟอลต์, cred file plain text) กำลังถูกแทนที่ ถ้าคุณจะเพิ่ม auth ให้ CLI ตอนนี้ เริ่มด้วย browser OAuth + PKCE สำหรับมนุษย์, API key สำหรับ automation แล้ววางแผนสำหรับวันที่ AI agent จะเป็นผู้ใช้หลักของคุณด้วย