โทเค็น OIDC (OIDC Token)

OpenID Connect (OIDC) คือข้อกำหนดที่เพิ่ม Authentication Layer สำหรับบอกว่า "คนนี้คือใคร" บน OAuth 2.0 เนื่องจาก OAuth 2.0 เพียงอย่างเดียวนั้นจัดการได้เฉพาะการ Authorization ในแง่ที่ว่า "อนุญาตให้ผู้ถือ Token นี้เข้าถึง Resource ได้" เท่านั้น โดยไม่มีวิธีมาตรฐานที่ฝั่ง Application จะรู้ได้ว่า User ที่ Login เข้ามานั้นคือใคร OIDC จึงเติมเต็มช่องว่างดังกล่าวด้วย Token 3 ประเภท ### บทบาทของ 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 ใหม่ทุกครั้งที่ใช้งาน) ### ภาพรวมของ Flow ใน Authorization Code Flow แบบทั่วไป เมื่อ User Login ผ่าน IdP แล้ว Authorization Code จะถูกส่งกลับมายัง Client จากนั้น Client จะนำ Code นี้ส่งไปยัง Token Endpoint ของ IdP เพื่อรับ ID Token, Access Token และ Refresh Token ทั้ง 3 รายการพร้อมกัน เนื่องจาก Authorization Code ใช้ได้เพียงครั้งเดียวและมีอายุสั้นมาก จึงช่วยลดจำนวนครั้งที่ Token ตัวจริงต้องส่งผ่านเครือข่ายให้น้อยที่สุด ### ข้อควรระวังในการ Implement สิ่งที่ผู้เขียนรู้สึกว่ามักถูกมองข้ามคือสถานที่จัดเก็บ 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 วัน ซึ่งการเริ่มปรับจากช่วงนี้ถือเป็นแนวทางที่เป็นจริงในทางปฏิบัติ