OIDC token คือชื่อเรียกรวมของ ID token, access token และ refresh token ที่ออกภายใต้โปรโตคอล OpenID Connect ซึ่งเป็นข้อมูลที่มีลายเซ็นดิจิทัลสำหรับแลกเปลี่ยนข้อมูลการยืนยันตัวตนและการอนุญาตของผู้ใช้อย่างปลอดภัย
OpenID Connect (OIDC) คือข้อกำหนดที่เพิ่ม Authentication Layer สำหรับบอกว่า "คนนี้คือใคร" บน OAuth 2.0 เนื่องจาก OAuth 2.0 เพียงอย่างเดียวนั้นจัดการได้เฉพาะการ Authorization ในแง่ที่ว่า "อนุญาตให้ผู้ถือ Token นี้เข้าถึง Resource ได้" เท่านั้น โดยไม่มีวิธีมาตรฐานที่ฝั่ง Application จะรู้ได้ว่า User ที่ Login เข้ามานั้นคือใคร OIDC จึงเติมเต็มช่องว่างดังกล่าวด้วย Token 3 ประเภท
ID Token คือแกนหลักของ OIDC ออกในรูปแบบ JWT (JSON Web Token) โดย Payload จะประกอบด้วย Claim ต่าง ๆ เช่น ตัวระบุผู้ใช้ (sub), ผู้ออก Token (iss) และวันหมดอายุ (exp) เป็นต้น เมื่อตรวจสอบ Signature แล้วสามารถตัดสินได้ทันทีว่ามีการปลอมแปลงหรือไม่ โดยไม่จำเป็นต้องสอบถามไปยัง IdP (Identity Provider) คุณสมบัติที่เป็น "บัตรประจำตัวแบบ Self-Contained" นี้เองที่เป็นกุญแจสำคัญในการลดต้นทุนการ Authentication ระหว่าง Microservice
Access Token มีต้นกำเนิดจาก OAuth 2.0 ใช้แทนสิทธิ์การเข้าถึง API หรือ Resource Server โดยจำกัดขอบเขตสิทธิ์ผ่าน Scope (เช่น openid profile email) และโดยทั่วไปจะตั้งวันหมดอายุไว้สั้น ประมาณไม่กี่นาทีถึง 1 ชั่วโมง
Refresh Token ใช้สำหรับขอชุด Token ใหม่เมื่อ Access Token หมดอายุ โดยไม่ต้องให้ User Login ใหม่อีกครั้ง เนื่องจากมีอายุการใช้งานยาวนาน จึงมีความเสี่ยงในการรั่วไหลสูง แนวปฏิบัติในการทำงานจริงคือเก็บไว้ฝั่ง Server เท่านั้น และเปิดใช้งาน Rotation (เปลี่ยนเป็น Refresh Token ใหม่ทุกครั้งที่ใช้งาน)
ใน Authorization Code Flow แบบทั่วไป เมื่อ User Login ผ่าน IdP แล้ว Authorization Code จะถูกส่งกลับมายัง Client จากนั้น Client จะนำ Code นี้ส่งไปยัง Token Endpoint ของ IdP เพื่อรับ ID Token, Access Token และ Refresh Token ทั้ง 3 รายการพร้อมกัน เนื่องจาก Authorization Code ใช้ได้เพียงครั้งเดียวและมีอายุสั้นมาก จึงช่วยลดจำนวนครั้งที่ Token ตัวจริงต้องส่งผ่านเครือข่ายให้น้อยที่สุด
สิ่งที่ผู้เขียนรู้สึกว่ามักถูกมองข้ามคือสถานที่จัดเก็บ Token ใน SPA (Single Page Application) บางครั้งมีการแนะนำให้บันทึก Access Token ไว้ใน localStorage ของ Browser แต่วิธีนี้สามารถถูกขโมยได้ง่ายผ่านการโจมตี XSS การใช้ Pattern BFF (Backend for Frontend) เพื่อเก็บใน HttpOnly Cookie หรือเก็บไว้ใน Session Store ฝั่ง Server จะมีความปลอดภัยสูงกว่า
ควรให้ความสนใจกับการออกแบบวันหมดอายุของ Token ด้วย หาก exp ของ ID Token ยาวเกินไป การเปลี่ยนแปลงสิทธิ์หรือการระงับบัญชีของ User จะไม่สะท้อนผลทันที แต่หากสั้นเกินไปก็จะเพิ่มความถี่ในการ Refresh และเพิ่มภาระให้กับ IdP IdP ส่วนใหญ่กำหนดค่า Default ไว้ที่ ID Token 5–15 นาที, Access Token 1 ชั่วโมง และ Refresh Token 30–90 วัน ซึ่งการเริ่มปรับจากช่วงนี้ถือเป็นแนวทางที่เป็นจริงในทางปฏิบัติ



Token คือหน่วยที่เล็กที่สุดที่ LLM ใช้ในการประมวลผลข้อความ โดยไม่ได้หมายถึงคำทั้งคำเสมอไป แต่ยังรวมถึงส่วนหนึ่งของคำ สัญลักษณ์ หรือช่องว่าง ซึ่งเป็นผลจากการแบ่งข้อความตามคลังคำศัพท์ (Vocabulary) ของโมเดล

PDPA (Personal Data Protection Act) คือกฎหมายที่ควบคุมการเก็บรวบรวม การใช้ การจัดเก็บ และการโอนข้อมูลส่วนบุคคลในประเทศไทย ซึ่งเปรียบได้กับกฎหมายคุ้มครองข้อมูลของไทยที่มีลักษณะเทียบเท่า GDPR ของสหภาพยุโรป

อัลกอริทึมที่รวมข้อความโดยใช้รูปแบบที่พบบ่อยและแบ่งออกเป็นหน่วย subword ส่งผลโดยตรงต่อต้นทุนอินพุต/เอาต์พุตและความเร็วในการประมวลผลของ LLM สำหรับภาษาที่มีทรัพยากรน้อย อาจเกิดการแตกย่อยระดับ byte เนื่องจากคลังคำศัพท์เฉพาะมีไม่เพียงพอ

วิธีการออกแบบที่แยกระบบ AI และโครงสร้างพื้นฐานการประมวลผลข้อมูลออกจากกันทั้งในเชิงกายภาพและเชิงตรรกะ เพื่อขจัดความเสี่ยงการรั่วไหลของข้อมูลส่วนบุคคลในเชิงโครงสร้าง โดยมีตัวอย่างที่เป็นแบบฉบับ ได้แก่ การแยก Tenant และการดำเนินงานแบบ On-premises

OWASP (Open Worldwide Application Security Project) คือโครงการชุมชนเปิดที่มุ่งเน้นการปรับปรุงความปลอดภัยของซอฟต์แวร์ เป็นที่รู้จักกันอย่างแพร่หลายจากการจัดอันดับความเสี่ยงด้านช่องโหว่ "OWASP Top 10"