OAuth 2.0 และ JWT Authentication คู่มือครบถ้วน

ในยุคดิจิทัลที่ทุกอย่างเชื่อมต่อถึงกัน การเข้าถึงข้อมูลและบริการต่าง ๆ ผ่านแอปพลิเคชันและ API กลายเป็นเรื่องปกติ การรักษาความปลอดภัยและการยืนยันสิทธิ์ของผู้ใช้งานจึงเป็นหัวใจสำคัญที่ไม่สามารถละเลยได้ครับ หากเรายังคงพึ่งพาวิธีการแบบดั้งเดิมในการจัดการกับรหัสผ่านและเซสชัน เราอาจพบกับข้อจำกัดด้านความยืดหยุ่น ความปลอดภัย และความสามารถในการปรับขนาด โดยเฉพาะอย่างยิ่งในสถาปัตยกรรมแบบ Microservices หรือ Single Page Application ที่ซับซ้อนในปัจจุบัน

บทความนี้จะพาคุณดำดิ่งสู่โลกของ OAuth 2.0 และ JWT Authentication ซึ่งเป็นสองมาตรฐานที่ได้รับการยอมรับและใช้งานอย่างแพร่หลายในการจัดการการอนุญาต (Authorization) และการพิสูจน์ตัวตน (Authentication) ในระบบที่ทันสมัยครับ เราจะมาทำความเข้าใจตั้งแต่พื้นฐาน บทบาทของผู้เกี่ยวข้อง กลไกการทำงาน ไปจนถึงการประยุกต์ใช้ในสถานการณ์จริง พร้อมทั้งข้อควรพิจารณาด้านความปลอดภัย เพื่อให้คุณสามารถนำความรู้ไปปรับใช้กับโปรเจกต์ของคุณได้อย่างมั่นใจครับ

• ทำความเข้าใจภาพรวมการพิสูจน์ตัวตนและการอนุญาต
• เจาะลึก OAuth 2.0: มาตรฐานสำหรับการอนุญาต
  • OAuth 2.0 คืออะไร?
  • บทบาทของผู้เกี่ยวข้อง (Roles Involved)
  • ประเภทของ Grant Types ใน OAuth 2.0
  • Scope ใน OAuth 2.0
  • ข้อดีและข้อเสียของ OAuth 2.0
• เจาะลึก JWT Authentication: โทเค็นที่ปลอดภัยและไร้สถานะ
  • JWT คืออะไร?
  • โครงสร้างของ JWT
  • การทำงานของ JWT Authentication
  • ประเภทของ Claims ใน JWT
  • ข้อดีและข้อเสียของ JWT
• ผสานพลัง: OAuth 2.0 และ JWT ทำงานร่วมกันอย่างไร
• การใช้งานจริงและการประยุกต์ใช้
  • ตัวอย่าง Code Snippet: การสร้างและตรวจสอบ JWT ด้วย Node.js
  • ข้อควรพิจารณาด้านความปลอดภัย
• ตารางเปรียบเทียบ: OAuth 2.0 vs. JWT
• คำถามที่พบบ่อย (FAQ)
• สรุปและก้าวต่อไป

ทำความเข้าใจภาพรวมการพิสูจน์ตัวตนและการอนุญาต

ก่อนที่เราจะเจาะลึกถึง OAuth 2.0 และ JWT เรามาทำความเข้าใจแนวคิดพื้นฐานของการพิสูจน์ตัวตนและการอนุญาตกันก่อนครับ สองคำนี้มักจะถูกใช้สลับกันไปมา แต่จริง ๆ แล้วมีความหมายและบทบาทที่แตกต่างกันอย่างชัดเจน:

• การพิสูจน์ตัวตน (Authentication): คือกระบวนการยืนยันว่า “คุณคือใคร?” ครับ เป็นการตรวจสอบตัวตนของผู้ใช้งานว่าเป็นบุคคลหรือเอนทิตีที่อ้างสิทธิ์จริง ๆ มักจะทำโดยการใช้ชื่อผู้ใช้และรหัสผ่าน, ลายนิ้วมือ, การสแกนใบหน้า หรือรหัส OTP ครับ
• การอนุญาต (Authorization): คือกระบวนการกำหนดว่า “คุณสามารถทำอะไรได้บ้าง?” หลังจากที่พิสูจน์ตัวตนแล้ว ระบบจะตรวจสอบสิทธิ์ว่าผู้ใช้งานคนนั้นมีสิทธิ์ในการเข้าถึงทรัพยากรหรือฟังก์ชันใดได้บ้าง เช่น ผู้ดูแลระบบอาจมีสิทธิ์ลบข้อมูลได้ แต่ผู้ใช้งานทั่วไปอาจทำได้แค่ดูข้อมูลเท่านั้นครับ

ในอดีต การพิสูจน์ตัวตนและการอนุญาตมักจะถูกจัดการโดยระบบเดียวที่เก็บข้อมูลผู้ใช้งานและรหัสผ่านไว้ และใช้ Session ID เพื่อระบุตัวตนของผู้ใช้งานที่เข้าสู่ระบบอยู่ แต่เมื่อแอปพลิเคชันมีความซับซ้อนมากขึ้น มีการใช้งาน API ระหว่างบริการต่าง ๆ และมีอุปกรณ์หลากหลายประเภท การจัดการแบบเดิมก็เริ่มมีข้อจำกัดครับ เช่น:

• การจัดการรหัสผ่าน: ผู้ใช้งานต้องจำรหัสผ่านจำนวนมากสำหรับแต่ละบริการ หรือใช้รหัสผ่านชุดเดียวกันซึ่งเป็นความเสี่ยงด้านความปลอดภัย
• ความปลอดภัยของ Session: Session ID ที่ถูกขโมยไปอาจทำให้ผู้โจมตีเข้าถึงบัญชีผู้ใช้งานได้ และการจัดการ Session ในระบบกระจายตัว (Distributed Systems) เป็นเรื่องที่ซับซ้อน
• การแบ่งปันข้อมูล: หากแอปพลิเคชันต้องการเข้าถึงข้อมูลของผู้ใช้งานจากบริการอื่น ๆ (เช่น รูปภาพจาก Google Photos หรือโพสต์จาก Facebook) การให้รหัสผ่านโดยตรงนั้นอันตรายมากครับ
• ความสามารถในการปรับขนาด (Scalability): การพึ่งพาสถานะ (Stateful) ของเซสชันอาจเป็นคอขวดเมื่อระบบต้องรองรับผู้ใช้งานจำนวนมาก

ด้วยเหตุผลเหล่านี้เอง ทำให้เกิดมาตรฐานและแนวปฏิบัติใหม่ ๆ ขึ้นมาเพื่อจัดการกับปัญหาเหล่านี้ และ OAuth 2.0 กับ JWT ก็เป็นสองเสาหลักที่เข้ามาเติมเต็มช่องว่างเหล่านี้ได้อย่างลงตัวครับ

เจาะลึก OAuth 2.0: มาตรฐานสำหรับการอนุญาต

OAuth 2.0 หรือ Open Authorization 2.0 เป็นเฟรมเวิร์กมาตรฐานเปิดสำหรับการอนุญาตที่ช่วยให้แอปพลิเคชันหรือบริการหนึ่งสามารถเข้าถึงทรัพยากรของผู้ใช้งานจากบริการอื่น ๆ ได้อย่างปลอดภัย โดยที่ผู้ใช้งานไม่จำเป็นต้องเปิดเผยรหัสผ่านของตนเองให้กับแอปพลิเคชันนั้น ๆ ครับ

OAuth 2.0 คืออะไร?

หัวใจสำคัญของ OAuth 2.0 คือแนวคิดของการ “มอบสิทธิ์” (Delegated Authorization) ครับ แทนที่แอปพลิเคชันจะขอรหัสผ่านจากผู้ใช้งานโดยตรงเพื่อเข้าถึงข้อมูลในบริการอื่น ๆ (เช่น Google, Facebook) OAuth 2.0 จะทำหน้าที่เป็นตัวกลางในการออก “โทเค็นการเข้าถึง” (Access Token) ให้กับแอปพลิเคชันนั้น ๆ ครับ โทเค็นนี้เปรียบเสมือนกุญแจที่ผู้ใช้งานมอบให้แอปพลิเคชันเพื่อเข้าถึงข้อมูลบางอย่างที่กำหนดไว้เท่านั้น และสามารถถูกถอนสิทธิ์ได้ทุกเมื่อครับ

ข้อสำคัญ: OAuth 2.0 ไม่ใช่โปรโตคอลการพิสูจน์ตัวตน (Authentication) แต่เป็นโปรโตคอลการอนุญาต (Authorization) ครับ หน้าที่หลักของมันคือการจัดการสิทธิ์การเข้าถึง ไม่ใช่การยืนยันตัวตนของผู้ใช้งานโดยตรงครับ

บทบาทของผู้เกี่ยวข้อง (Roles Involved)

ในระบบ OAuth 2.0 มีผู้เกี่ยวข้องหลัก ๆ 4 ส่วนครับ:

1. Resource Owner (ผู้ใช้งาน): คือบุคคลที่เข้าสู่ระบบและเป็นเจ้าของข้อมูลหรือทรัพยากรที่ต้องการให้แอปพลิเคชันอื่นเข้าถึงครับ เช่น คุณที่เป็นเจ้าของบัญชี Google Drive ครับ
2. Client (แอปพลิเคชัน): คือแอปพลิเคชันที่ต้องการเข้าถึงข้อมูลของผู้ใช้งานจากบริการอื่น ๆ ครับ เช่น แอปพลิเคชันแก้ไขรูปภาพที่ต้องการเข้าถึงรูปภาพของคุณที่เก็บไว้ใน Google Photos ครับ Client นี้จะต้องลงทะเบียนกับ Authorization Server ล่วงหน้าและได้รับ Client ID และ Client Secret ครับ
3. Authorization Server (เซิร์ฟเวอร์ออกโทเค็น): คือเซิร์ฟเวอร์ที่ทำหน้าที่พิสูจน์ตัวตนของผู้ใช้งาน และเมื่อผู้ใช้งานอนุญาตแล้ว ก็จะออก Access Token ให้กับ Client ครับ ตัวอย่างเช่น เซิร์ฟเวอร์ของ Google ที่จัดการการเข้าสู่ระบบและออกโทเค็นให้แอปพลิเคชันอื่น ๆ ครับ
4. Resource Server (เซิร์ฟเวอร์เก็บข้อมูล): คือเซิร์ฟเวอร์ที่เก็บข้อมูลหรือทรัพยากรของผู้ใช้งาน และจะตรวจสอบ Access Token ที่ Client ส่งมา เพื่ออนุญาตให้เข้าถึงข้อมูลได้ครับ ตัวอย่างเช่น Google Drive API ที่เก็บไฟล์ของคุณครับ

การทำงานร่วมกันของบทบาทเหล่านี้ทำให้เกิดกระบวนการที่ปลอดภัยและยืดหยุ่นครับ

ประเภทของ Grant Types ใน OAuth 2.0

OAuth 2.0 มีกลไกหลายรูปแบบที่เรียกว่า “Grant Types” เพื่อให้ Client ได้รับ Access Token ซึ่งแต่ละแบบก็เหมาะกับประเภทของแอปพลิเคชันที่แตกต่างกันไปครับ:

Authorization Code Grant

นี่คือ Grant Type ที่นิยมใช้มากที่สุดและปลอดภัยที่สุด โดยเฉพาะอย่างยิ่งสำหรับเว็บแอปพลิเคชัน (Web Applications) ที่ทำงานบนฝั่งเซิร์ฟเวอร์ (Server-side) ครับ

ขั้นตอนการทำงานโดยสรุป:

1. Client ร้องขอการอนุญาต: ผู้ใช้งานคลิก “เข้าสู่ระบบด้วย Google” บนเว็บแอปพลิเคชัน (Client) ครับ Client จะสร้าง URL เพื่อส่งผู้ใช้งานไปยัง Authorization Server ของ Google พร้อมกับ Client ID, Redirect URI และ Scopes ที่ต้องการ
2. ผู้ใช้งานอนุญาต: Authorization Server (Google) จะแสดงหน้าต่างให้ผู้ใช้งานเข้าสู่ระบบ (ถ้ายังไม่ได้เข้า) และขออนุญาตให้ Client เข้าถึงข้อมูลตาม Scopes ที่ร้องขอครับ
3. Authorization Server ส่ง Authorization Code: หากผู้ใช้งานอนุญาต Authorization Server จะ redirect ผู้ใช้งานกลับไปยัง Redirect URI ของ Client พร้อมกับแนบ Authorization Code มาด้วยครับ
4. Client แลกเปลี่ยน Code เป็น Token: Client (บนฝั่ง Server-side) จะนำ Authorization Code ที่ได้รับ มาส่งคำขอ POST ไปยัง Authorization Server อีกครั้งครับ โดยครั้งนี้จะแนบ Client ID, Client Secret และ Authorization Code เพื่อยืนยันตัวตนครับ
5. Authorization Server ออก Access Token และ Refresh Token: หากการตรวจสอบถูกต้อง Authorization Server จะออก Access Token (และอาจรวมถึง Refresh Token) ให้กับ Client ครับ
6. Client ใช้ Access Token: Client จะนำ Access Token ที่ได้รับ ไปใช้ในการร้องขอข้อมูลจาก Resource Server (เช่น Google Drive API) ในการเรียกใช้ API ครั้งต่อ ๆ ไปครับ

ตัวอย่าง Code (เชิงแนวคิด) สำหรับการเริ่มต้นกระบวนการ:

// ฝั่ง Client (ตัวอย่างใน Node.js/Express)
app.get('/login/google', (req, res) => {
    const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?` +
                    `client_id=${process.env.GOOGLE_CLIENT_ID}&` +
                    `redirect_uri=${encodeURIComponent(process.env.GOOGLE_REDIRECT_URI)}&` +
                    `response_type=code&` +
                    `scope=openid%20profile%20email`; // กำหนด Scopes ที่ต้องการ
    res.redirect(authUrl);
});

app.get('/auth/google/callback', async (req, res) => {
    const code = req.query.code;
    if (!code) {
        return res.status(400).send('Authorization code not found.');
    }

    try {
        // ขั้นตอนนี้จะดำเนินการบนฝั่ง Server-side เพื่อแลกเปลี่ยน code เป็น token
        // ตัวอย่างการเรียกใช้ API เพื่อแลกเปลี่ยน Code (ใช้ไลบรารีเช่น axios)
        // const tokenResponse = await axios.post('https://oauth2.googleapis.com/token', {
        //     code: code,
        //     client_id: process.env.GOOGLE_CLIENT_ID,
        //     client_secret: process.env.GOOGLE_CLIENT_SECRET,
        //     redirect_uri: process.env.GOOGLE_REDIRECT_URI,
        //     grant_type: 'authorization_code'
        // });

        // const accessToken = tokenResponse.data.access_token;
        // const refreshToken = tokenResponse.data.refresh_token; // ถ้ามี

        // console.log('Access Token:', accessToken);
        // console.log('Refresh Token:', refreshToken);

        // ปกติจะเก็บ token เหล่านี้ไว้ในเซสชันหรือฐานข้อมูลและ redirect ผู้ใช้ไปยังหน้าหลัก
        res.send('Successfully authenticated! Access token received (check server logs).');

    } catch (error) {
        console.error('Error exchanging authorization code:', error.response ? error.response.data : error.message);
        res.status(500).send('Authentication failed.');
    }
});

จากตัวอย่างข้างต้น แสดงให้เห็นถึงการส่งผู้ใช้งานไปยัง Google เพื่อขอ Authorization Code และการรับ Code กลับมายัง Callback URL ครับ ส่วนการแลกเปลี่ยน Code เป็น Access Token นั้น ควรทำบนฝั่ง Server-side เท่านั้น เพื่อป้องกัน Client Secret รั่วไหลครับ

Client Credentials Grant

Grant Type นี้ใช้สำหรับกรณีที่ Client (แอปพลิเคชัน) ต้องการเข้าถึงทรัพยากรของตนเอง หรือทรัพยากรที่ไม่ได้ผูกกับผู้ใช้งานโดยตรงครับ เป็นการอนุญาตระหว่างแอปพลิเคชันกับแอปพลิเคชัน (machine-to-machine) โดยไม่มีผู้ใช้งานเข้ามาเกี่ยวข้องครับ มักใช้กับ Microservices ที่สื่อสารกันเองครับ

Refresh Token Grant

Access Token มักจะมีอายุสั้นเพื่อเพิ่มความปลอดภัย (เช่น 1 ชั่วโมง) เพื่อหลีกเลี่ยงการให้ผู้ใช้งานเข้าสู่ระบบใหม่บ่อย ๆ Authorization Server สามารถออก Refresh Token ให้กับ Client พร้อมกับ Access Token ได้ครับ เมื่อ Access Token หมดอายุ Client สามารถใช้ Refresh Token เพื่อขอ Access Token ใหม่ได้โดยไม่ต้องให้ผู้ใช้งานเข้าสู่ระบบอีกครั้งครับ Refresh Token มักจะมีอายุที่ยาวนานกว่าและควรเก็บรักษาอย่างปลอดภัยที่สุดครับ

นอกจากนี้ยังมี Grant Type อื่น ๆ เช่น Implicit Grant (เดิมใช้สำหรับ Single Page Applications แต่ปัจจุบันไม่แนะนำเนื่องจากความเสี่ยงด้านความปลอดภัย), Resource Owner Password Credentials Grant (ไม่แนะนำอย่างยิ่งสำหรับการใช้งานทั่วไป), และ Device Code Grant ครับ แต่ Authorization Code Grant เป็นหัวใจสำคัญที่คุณควรรู้จักเป็นอย่างดีครับ

Scope ใน OAuth 2.0

Scope คือกลไกใน OAuth 2.0 ที่ใช้ในการกำหนดระดับของสิทธิ์การเข้าถึงที่ Client ต้องการจาก Resource Owner ครับ เมื่อผู้ใช้งานถูกนำไปยังหน้าอนุญาตบน Authorization Server ผู้ใช้งานจะเห็นรายการของ Scopes ที่ Client ร้องขอ และสามารถเลือกที่จะอนุมัติหรือปฏิเสธได้ครับ

• ตัวอย่าง Scope: email (ขอสิทธิ์เข้าถึงอีเมล), profile (ขอสิทธิ์เข้าถึงข้อมูลโปรไฟล์), openid (สำหรับ OpenID Connect), https://www.googleapis.com/auth/drive.readonly (ขอสิทธิ์อ่านไฟล์ใน Google Drive เท่านั้น)

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

ข้อดีและข้อเสียของ OAuth 2.0

ข้อดี:

• ความปลอดภัย: ผู้ใช้งานไม่จำเป็นต้องเปิดเผยรหัสผ่านให้กับ Client โดยตรง
• การมอบสิทธิ์แบบจำกัด: สามารถกำหนดสิทธิ์การเข้าถึงได้อย่างละเอียดผ่าน Scopes
• ควบคุมโดยผู้ใช้งาน: ผู้ใช้งานสามารถอนุมัติหรือเพิกถอนสิทธิ์ได้ทุกเมื่อ
• เหมาะสำหรับ API: ออกแบบมาเพื่อรองรับการทำงานกับ API และ Microservices ที่หลากหลาย
• ยืดหยุ่น: รองรับ Grant Types ที่แตกต่างกันสำหรับแอปพลิเคชันประเภทต่าง ๆ

ข้อเสีย:

• ความซับซ้อน: มีขั้นตอนและผู้เกี่ยวข้องหลายส่วน ทำให้การทำความเข้าใจและนำไปใช้งานครั้งแรกอาจซับซ้อน
• ไม่ใช่การพิสูจน์ตัวตน: OAuth 2.0 ไม่ได้ถูกออกแบบมาเพื่อพิสูจน์ตัวตนโดยตรง แต่เป็นการอนุญาต (ซึ่ง OpenID Connect สร้างขึ้นมาเพื่อแก้ไขจุดนี้)
• Overhead ในการตั้งค่า: Client ต้องลงทะเบียนกับ Authorization Server และจัดการ Client ID/Secret

โดยรวมแล้ว OAuth 2.0 เป็นเครื่องมือที่ทรงพลังและจำเป็นอย่างยิ่งในการจัดการการอนุญาตในระบบที่ทันสมัย แม้จะมีความซับซ้อนบ้าง แต่ประโยชน์ที่ได้รับด้านความปลอดภัยและความยืดหยุ่นนั้นคุ้มค่ามากครับ

อ่านเพิ่มเติมเกี่ยวกับ OAuth 2.0 Grant Types

เจาะลึก JWT Authentication: โทเค็นที่ปลอดภัยและไร้สถานะ

หลังจากที่เราเข้าใจ OAuth 2.0 ที่เป็นเฟรมเวิร์กสำหรับการอนุญาตแล้ว คราวนี้เรามาดู JWT (JSON Web Token) ซึ่งเป็นมาตรฐานที่มักจะถูกใช้เป็น Access Token ภายในเฟรมเวิร์ก OAuth 2.0 หรือใช้สำหรับการพิสูจน์ตัวตนโดยตรงในระบบที่ต้องการความเป็น Stateless ครับ

JWT คืออะไร?

JSON Web Token (JWT) คือมาตรฐาน (RFC 7519) ที่ใช้ในการสร้างโทเค็นที่ปลอดภัยสำหรับการส่งข้อมูลระหว่างสองฝ่ายในรูปแบบ JSON ครับ ข้อมูลที่อยู่ใน JWT สามารถถูกตรวจสอบความถูกต้องและน่าเชื่อถือได้ เนื่องจากมีการลงชื่อดิจิทัล (Digitally Signed) ไว้

หัวใจสำคัญของ JWT คือ Statelessness หรือ “ไร้สถานะ” ครับ หมายความว่าเซิร์ฟเวอร์ไม่จำเป็นต้องเก็บข้อมูลเซสชันของผู้ใช้งานไว้ โทเค็น JWT เองจะบรรจุข้อมูลที่จำเป็นทั้งหมดไว้ในตัวมันเอง ทำให้เซิร์ฟเวอร์สามารถตรวจสอบความถูกต้องและสิทธิ์ของผู้ใช้งานได้โดยการถอดรหัสและตรวจสอบลายเซ็นของโทเค็นเท่านั้น ซึ่งช่วยลดภาระการจัดการสถานะและเพิ่มความสามารถในการปรับขนาดของระบบได้อย่างมากครับ

โครงสร้างของ JWT

โทเค็น JWT โดยทั่วไปจะประกอบด้วยสามส่วนที่คั่นด้วยจุด (.) ครับ:

Header.Payload.Signature

แต่ละส่วนจะถูกเข้ารหัสด้วย Base64Url-encoded ครับ

Header (ส่วนหัว)

ส่วนหัวมักจะประกอบด้วยข้อมูลเกี่ยวกับประเภทของโทเค็น (typ) ซึ่งมักจะเป็น “JWT” และอัลกอริทึมที่ใช้ในการลงชื่อดิจิทัล (alg) เช่น HS256 (HMAC SHA256) หรือ RS256 (RSA SHA256) ครับ

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (ส่วนข้อมูล)

ส่วน Payload จะบรรจุ “Claims” หรือชุดของข้อมูลเกี่ยวกับเอนทิตี (โดยทั่วไปคือผู้ใช้งาน) และข้อมูลเพิ่มเติมอื่น ๆ ครับ Claims สามารถแบ่งออกเป็นสามประเภทหลัก ๆ:

1. Registered Claims: เป็น Claim ที่ถูกกำหนดไว้ล่วงหน้าและแนะนำให้ใช้ เพื่อให้สามารถทำงานร่วมกันได้ดี เช่น:
   • iss (Issuer): ผู้ออกโทเค็น
   • sub (Subject): หัวข้อของโทเค็น (โดยทั่วไปคือ ID ของผู้ใช้งาน)
   • exp (Expiration Time): เวลาที่โทเค็นจะหมดอายุ
   • iat (Issued At): เวลาที่โทเค็นถูกออก
   • aud (Audience): ผู้รับโทเค็น
2. Public Claims: เป็น Claim ที่กำหนดโดยผู้ใช้ แต่ต้องลงทะเบียนใน IANA JSON Web Token Registry หรือกำหนดให้เป็น URI ที่ไม่ขัดแย้งกับ Registered Claims
3. Private Claims: เป็น Claim ที่กำหนดขึ้นเองตามความต้องการของแอปพลิเคชัน โดยตกลงกันเองระหว่างผู้ออกและผู้รับโทเค็น เช่น "userId": "123", "role": "admin"

{
  "sub": "1234567890",
  "name": "SiamLancard User",
  "admin": true,
  "iat": 1516239022,
  "exp": 1516242622 // โทเค็นหมดอายุใน 1 ชั่วโมง
}

Signature (ลายเซ็น)

ส่วน Signature ใช้สำหรับตรวจสอบความถูกต้องของโทเค็น เพื่อให้แน่ใจว่าไม่มีใครเปลี่ยนแปลง Header หรือ Payload ครับ Signature จะถูกสร้างขึ้นโดยการนำ Base64Url-encoded ของ Header และ Payload มารวมกัน แล้วนำไปแฮชด้วย Secret Key ที่มีเพียงผู้ออกโทเค็นเท่านั้นที่รู้ (สำหรับ HS256) หรือใช้ Private Key (สำหรับ RS256) ครับ

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

เมื่อผู้รับโทเค็นได้รับ JWT ก็จะนำ Header และ Payload มาสร้าง Signature ใหม่ด้วย Secret Key เดียวกัน แล้วนำไปเปรียบเทียบกับ Signature ที่อยู่ในโทเค็น หากไม่ตรงกัน แสดงว่าโทเค็นถูกดัดแปลงหรือไม่ได้ออกโดยผู้ออกที่ถูกต้องครับ

การทำงานของ JWT Authentication

การทำงานของ JWT Authentication มีขั้นตอนดังนี้ครับ:

1. ผู้ใช้งานเข้าสู่ระบบ: ผู้ใช้งานส่งชื่อผู้ใช้และรหัสผ่านไปยังเซิร์ฟเวอร์พิสูจน์ตัวตน (Authentication Server) ครับ
2. เซิร์ฟเวอร์ออก JWT: หากการพิสูจน์ตัวตนสำเร็จ เซิร์ฟเวอร์จะสร้าง JWT ที่มีข้อมูลของผู้ใช้งาน (เช่น ID, บทบาท) ในส่วน Payload และลงชื่อด้วย Secret Key ครับ
3. ส่ง JWT กลับไปยัง Client: เซิร์ฟเวอร์ส่ง JWT นี้กลับไปยัง Client (โดยทั่วไปจะอยู่ใน Response Body หรือ Header) ครับ
4. Client จัดเก็บ JWT: Client จะจัดเก็บ JWT ที่ได้รับไว้ (มักจะเก็บใน Local Storage, Session Storage, หรือ Cookie ครับ)
5. Client ส่ง JWT ในทุกคำขอ: ในการเรียกใช้ API หรือเข้าถึงทรัพยากรที่ต้องมีการยืนยันสิทธิ์ Client จะแนบ JWT ไว้ในส่วน Authorization Header ของ HTTP Request เสมอครับ โดยมีรูปแบบเป็น Bearer <token>
6. Resource Server ตรวจสอบ JWT: เมื่อ Resource Server ได้รับคำขอพร้อม JWT จะทำการตรวจสอบดังนี้:
   • ตรวจสอบลายเซ็น: ใช้ Secret Key ที่รู้ร่วมกัน (หรือ Public Key) เพื่อตรวจสอบลายเซ็นว่าถูกต้องหรือไม่ หากไม่ถูกต้องจะปฏิเสธคำขอทันที
   • ตรวจสอบวันหมดอายุ: ตรวจสอบ exp Claim ว่าโทเค็นหมดอายุหรือยัง
   • ตรวจสอบ Claims อื่น ๆ: ตรวจสอบ Claims อื่น ๆ เช่น iss, aud หรือ Private Claims เพื่อยืนยันสิทธิ์ของผู้ใช้งาน
7. อนุญาตการเข้าถึง: หาก JWT ผ่านการตรวจสอบทั้งหมด Resource Server จะอนุญาตให้เข้าถึงทรัพยากรตามสิทธิ์ที่ระบุใน Payload ครับ

ประเภทของ Claims ใน JWT

อย่างที่กล่าวไปในส่วนโครงสร้าง Claims คือหัวใจของ Payload ซึ่งเป็นข้อมูลที่ JWT บรรจุอยู่ครับ การเลือกใช้ Claims ที่เหมาะสมมีความสำคัญต่อความปลอดภัยและการใช้งาน:

• Registered Claims: ควรใช้เมื่อข้อมูลนั้นเป็นมาตรฐานและจำเป็นต่อการทำงานร่วมกัน เช่น exp (หมดอายุ) และ sub (หัวเรื่อง/ผู้ใช้งาน ID) เพื่อให้ผู้รับโทเค็นสามารถตรวจสอบเบื้องต้นได้ทันที
• Public Claims: ใช้สำหรับข้อมูลที่ไม่ใช่มาตรฐานแต่ต้องการให้สาธารณะเข้าถึงได้
• Private Claims: ใช้สำหรับข้อมูลเฉพาะภายในแอปพลิเคชันของคุณเอง เช่น "role": "admin" หรือ "companyId": "XYZ" แต่ควรระมัดระวังไม่ให้ใส่ข้อมูลที่ละเอียดอ่อนเกินไป เพราะถึงแม้จะเข้ารหัส Base64Url แต่ก็สามารถถอดรหัสกลับมาอ่านได้ง่ายครับ ข้อมูลสำคัญควรอยู่บนเซิร์ฟเวอร์เท่านั้น

ข้อดีและข้อเสียของ JWT

ข้อดี:

• Stateless (ไร้สถานะ): เซิร์ฟเวอร์ไม่จำเป็นต้องเก็บข้อมูลเซสชัน ทำให้ Scalability ดีขึ้น และเหมาะกับสถาปัตยกรรม Microservices
• Compact: มีขนาดเล็กและสามารถส่งผ่าน URL, POST parameter หรือ HTTP header ได้ง่าย
• Self-contained: มีข้อมูลที่จำเป็นทั้งหมดอยู่ในตัวโทเค็น ทำให้ Resource Server ไม่ต้องสอบถามฐานข้อมูลเพิ่มเติมในการตรวจสอบสิทธิ์ทุกครั้ง
• Mobile-friendly: เหมาะสำหรับแอปพลิเคชันบนมือถือที่ไม่พึ่งพา Cookie
• Secured by Signature: ลายเซ็นดิจิทัลช่วยให้มั่นใจได้ว่าข้อมูลในโทเค็นไม่ถูกแก้ไข

ข้อเสีย:

• ไม่มีกลไกการเพิกถอนในตัว (No Built-in Revocation): เมื่อ JWT ถูกออกไปแล้ว จะยังคงใช้ได้จนกว่าจะหมดอายุ เว้นแต่จะมีการนำไปจัดการบน Blacklist บนเซิร์ฟเวอร์
• ขนาดของโทเค็น: หากใส่ข้อมูล (Claims) มากเกินไป โทเค็นอาจมีขนาดใหญ่ขึ้น ทำให้ HTTP Request มีขนาดใหญ่ขึ้นด้วย
• การเก็บข้อมูลที่ละเอียดอ่อน: เนื่องจาก Payload สามารถถอดรหัส Base64Url กลับมาอ่านได้ง่าย จึงไม่ควรเก็บข้อมูลที่ละเอียดอ่อนมาก ๆ ใน Payload
• ความปลอดภัยของ Secret Key: หาก Secret Key รั่วไหล ผู้โจมตีสามารถสร้าง JWT ปลอมขึ้นมาได้

JWT เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการสร้างระบบ Authentication ที่มีประสิทธิภาพและปรับขนาดได้ดี แต่ก็ต้องมีการจัดการด้านความปลอดภัยอย่างรอบคอบ โดยเฉพาะเรื่องการเพิกถอนโทเค็นและการปกป้อง Secret Key ครับ

ผสานพลัง: OAuth 2.0 และ JWT ทำงานร่วมกันอย่างไร

บ่อยครั้งที่ OAuth 2.0 และ JWT ถูกนำมาใช้งานร่วมกัน ซึ่งอาจทำให้เกิดความสับสนว่าทั้งสองสิ่งนี้มีความสัมพันธ์กันอย่างไรและบทบาทของแต่ละส่วนคืออะไรครับ

ความสัมพันธ์ที่ง่ายที่สุดคือ:

• OAuth 2.0 คือ "กระบวนการ" หรือ "เฟรมเวิร์ก" ในการ ขอและได้รับ สิทธิ์การเข้าถึง (Authorization) ครับ
• JWT คือ "รูปแบบ" ของ สิ่งที่ได้รับมา ซึ่งก็คือ Access Token ที่ OAuth 2.0 มอบให้ครับ

ลองนึกภาพสถานการณ์ที่เราต้องการให้แอปพลิเคชัน (Client) เข้าถึงข้อมูลของผู้ใช้งาน (Resource Owner) จากบริการอื่น ๆ (Resource Server) โดยใช้ OAuth 2.0:

1. ผู้ใช้งาน (Resource Owner) ต้องการให้แอปพลิเคชัน A (Client) เข้าถึงรูปภาพใน Google Photos (Resource Server) ครับ
2. แอปพลิเคชัน A จะส่งผู้ใช้งานไปยัง Authorization Server ของ Google เพื่อให้ผู้ใช้งานเข้าสู่ระบบและอนุมัติสิทธิ์การเข้าถึงครับ (นี่คือส่วนของ OAuth 2.0)
3. เมื่อผู้ใช้งานอนุมัติสำเร็จ Authorization Server ของ Google จะออก Access Token และส่งกลับมายังแอปพลิเคชัน A ครับ
4. ในหลาย ๆ กรณี Access Token ที่ออกให้นั้น มีรูปแบบเป็น JWT ครับ (นี่คือส่วนที่ JWT เข้ามาเกี่ยวข้อง)
5. จากนั้น แอปพลิเคชัน A ก็จะนำ JWT (ที่เป็น Access Token) นี้ไปแนบในทุก ๆ คำขอเมื่อต้องการเรียกใช้ Google Photos API ครับ
6. Resource Server (Google Photos API) จะได้รับ JWT นี้ ทำการตรวจสอบลายเซ็น วันหมดอายุ และ Claims ต่าง ๆ ภายใน JWT เพื่อยืนยันว่า Access Token นี้ถูกต้องและผู้ใช้งานมีสิทธิ์ในการเข้าถึงข้อมูลนั้น ๆ ครับ

ดังนั้น OAuth 2.0 จึงเป็นตัวจัดการกระบวนการตั้งแต่ต้นจนจบในการขอสิทธิ์ ส่วน JWT ทำหน้าที่เป็นตัวแทนของสิทธิ์นั้นในรูปแบบที่ปลอดภัยและตรวจสอบได้ง่ายครับ

OpenID Connect (OIDC) กับ OAuth 2.0 และ JWT

เพื่อคลายความสับสนที่ว่า OAuth 2.0 ไม่ใช่การพิสูจน์ตัวตน แต่เป็นเพียงการอนุญาต จึงมีการพัฒนามาตรฐานใหม่ที่เรียกว่า OpenID Connect (OIDC) ขึ้นมาครับ

• OIDC คือ Authentication Layer ที่อยู่ บนสุด ของ OAuth 2.0 ครับ
• OIDC ใช้กระบวนการของ OAuth 2.0 ในการออกโทเค็น แต่เพิ่ม ID Token เข้ามาด้วย
• ID Token นี้เป็น JWT เสมอครับ และมี Claims ที่ใช้สำหรับพิสูจน์ตัวตนของผู้ใช้งานโดยเฉพาะ (เช่น sub, name, email)

ดังนั้น เมื่อคุณใช้ “เข้าสู่ระบบด้วย Google” หรือ “เข้าสู่ระบบด้วย Facebook” สิ่งที่คุณกำลังใช้งานอยู่จริง ๆ คือ OpenID Connect ที่ทำงานอยู่บน OAuth 2.0 และใช้ JWT เป็น ID Token เพื่อยืนยันตัวตนของคุณครับ

สรุปง่าย ๆ คือ OAuth 2.0 ได้รับ Access Token (ซึ่งอาจจะเป็น JWT) เพื่อการอนุญาต ส่วน OIDC ใช้ OAuth 2.0 เพื่อได้รับ ID Token (ซึ่งเป็น JWT เสมอ) เพื่อการพิสูจน์ตัวตนครับ

การใช้งานจริงและการประยุกต์ใช้

การนำ OAuth 2.0 และ JWT ไปใช้งานจริงต้องมีการวางแผนและการพิจารณาด้านความปลอดภัยอย่างรอบคอบครับ ในส่วนนี้ เราจะมาดูตัวอย่าง Code Snippet ง่าย ๆ และข้อควรพิจารณาที่สำคัญครับ

ตัวอย่าง Code Snippet: การสร้างและตรวจสอบ JWT ด้วย Node.js

เราจะใช้ไลบรารี jsonwebtoken สำหรับ Node.js เพื่อสาธิตการสร้างและตรวจสอบ JWT ครับ

ขั้นตอนที่ 1: ติดตั้งไลบรารี

npm install jsonwebtoken express dotenv

ขั้นตอนที่ 2: สร้างไฟล์ .env สำหรับ Secret Key

JWT_SECRET=your_super_secret_key_for_jwt_signing

สำคัญ: Secret Key นี้ต้องยาว ซับซ้อน และเก็บรักษาเป็นความลับที่สุดครับ ห้าม hardcode ในโค้ดจริงเด็ดขาด!

ขั้นตอนที่ 3: โค้ดสำหรับ Authentication Server และ Resource Server (ในไฟล์เดียวกันเพื่อความง่าย)

require('dotenv').config();
const express = require('express');
const jwt = require('jsonwebtoken');

const app = express();
const port = 3000;

app.use(express.json()); // สำหรับ Parse JSON body

const JWT_SECRET = process.env.JWT_SECRET;
if (!JWT_SECRET) {
    console.error('JWT_SECRET is not defined in .env file!');
    process.exit(1);
}

// -----------------------------------------------------------------
// 1. Authentication Server (Login Endpoint)
// -----------------------------------------------------------------
app.post('/login', (req, res) => {
    const { username, password } = req.body;

    // นี่คือการตรวจสอบผู้ใช้แบบง่าย ๆ ในโลกจริงต้องตรวจสอบกับฐานข้อมูล
    if (username === 'user123' && password === 'pass123') {
        // สร้าง Payload สำหรับ JWT
        const user = {
            id: 1,
            username: username,
            role: 'user'
        };

        // สร้าง JWT
        // expiresIn: กำหนดอายุของโทเค็น (เช่น '1h', '7d', '30s')
        const token = jwt.sign(user, JWT_SECRET, { expiresIn: '1h' });

        res.json({
            message: 'Login successful!',
            accessToken: token
        });
    } else {
        res.status(401).json({ message: 'Invalid credentials' });
    }
});

// -----------------------------------------------------------------
// 2. Middleware สำหรับตรวจสอบ JWT (ใน Resource Server)
// -----------------------------------------------------------------
function authenticateToken(req, res, next) {
    // ดึงโทเค็นจาก Authorization Header
    const authHeader = req.headers['authorization'];
    // รูปแบบ: Bearer TOKEN_STRING
    const token = authHeader && authHeader.split(' ')[1];

    if (token == null) {
        return res.status(401).json({ message: 'Access Token required' }); // ไม่มีโทเค็น
    }

    jwt.verify(token, JWT_SECRET, (err, user) => {
        if (err) {
            console.error('JWT Verification Error:', err.message);
            // err.name จะเป็น 'TokenExpiredError' ถ้าโทเค็นหมดอายุ
            return res.status(403).json({ message: 'Invalid or expired token' }); // โทเค็นไม่ถูกต้องหรือไม่หมดอายุ
        }
        req.user = user; // เก็บข้อมูลผู้ใช้จาก Payload ไว้ใน req object
        next(); // ไปยัง Handler ถัดไป
    });
}

// -----------------------------------------------------------------
// 3. Resource Server (Protected Endpoint)
// -----------------------------------------------------------------
app.get('/protected', authenticateToken, (req, res) => {
    res.json({
        message: 'This is a protected route!',
        user: req.user, // ข้อมูลผู้ใช้ที่ได้จาก JWT
        data: 'You have access to sensitive data.'
    });
});

app.listen(port, () => {
    console.log(`Server running on http://localhost:${port}`);
});

วิธีการทดสอบ:

1. รันเซิร์ฟเวอร์: node app.js
2. Login:
   • ส่ง POST Request ไปยัง http://localhost:3000/login
   • Header: Content-Type: application/json
   • Body: {"username": "user123", "password": "pass123"}
   • คุณจะได้รับ Access Token กลับมา
3. Access Protected Route:
   • ส่ง GET Request ไปยัง http://localhost:3000/protected
   • Header: Authorization: Bearer <Access Token ที่ได้รับจากขั้นตอนที่ 2>
   • คุณควรจะได้รับข้อความ Protected และข้อมูลผู้ใช้งานจาก JWT ครับ
   • ลองส่งโดยไม่มี Authorization Header หรือใช้โทเค็นผิด ๆ เพื่อดูผลลัพธ์

ตัวอย่างนี้เป็นเพียงการสาธิตแนวคิดพื้นฐานเท่านั้น ในการใช้งานจริงจะต้องมีการจัดการที่ดีกว่านี้ครับ

ข้อควรพิจารณาด้านความปลอดภัย

การนำ OAuth 2.0 และ JWT ไปใช้ต้องคำนึงถึงความปลอดภัยเป็นสำคัญครับ

• ปกป้อง Secret Key/Private Key: Secret Key สำหรับ JWT หรือ Private Key สำหรับ OAuth 2.0 (ถ้าใช้ RS256) ต้องถูกเก็บรักษาเป็นความลับสูงสุด ห้ามเปิดเผยเด็ดขาดครับ ควรเก็บไว้ใน Environment Variables หรือ Key Management System
• HTTPS/SSL เสมอ: การสื่อสารทั้งหมดระหว่าง Client, Authorization Server, และ Resource Server ต้องทำผ่าน HTTPS เพื่อป้องกันการดักจับข้อมูล (Man-in-the-Middle attacks) ครับ
• การจัดเก็บ JWT บน Client:
  • Local Storage/Session Storage: สะดวก แต่เสี่ยงต่อการถูกโจมตีแบบ XSS (Cross-Site Scripting) หากมีช่องโหว่ ผู้โจมตีสามารถอ่านโทเค็นไปใช้ได้
  • HTTP-Only Cookies: ปลอดภัยกว่าเพราะ JavaScript ไม่สามารถเข้าถึงได้โดยตรง ช่วยลดความเสี่ยงจาก XSS แต่ก็ยังมีข้อควรระวังเรื่อง CSRF (Cross-Site Request Forgery) ซึ่งต้องมีการป้องกันเพิ่มเติม เช่น ใช้ CSRF Token หรือ SameSite cookie attribute
  • Memory (in SPA): เก็บในหน่วยความจำของแอปพลิเคชัน (JavaScript variable) อาจปลอดภัยที่สุดสำหรับ XSS แต่โทเค็นจะหายไปเมื่อผู้ใช้งานปิดหน้าต่าง/แท็บ

  การเลือกวิธีการจัดเก็บขึ้นอยู่กับลักษณะของแอปพลิเคชันและความเสี่ยงที่ยอมรับได้ครับ

• อายุของโทเค็น (Token Expiration) และ Refresh Token:
  • กำหนด Access Token ให้มีอายุสั้น (เช่น 15 นาที – 1 ชั่วโมง) เพื่อลดความเสี่ยงหากโทเค็นถูกขโมยไป
  • ใช้ Refresh Token ที่มีอายุยาวนานกว่า (เช่น 7 วัน – 1 ปี) เพื่อให้ผู้ใช้งานไม่ต้องเข้าสู่ระบบบ่อย ๆ ครับ Refresh Token ควรถูกเก็บรักษาอย่างปลอดภัยยิ่งกว่า Access Token และควรมีการตรวจสอบเพิ่มเติม (เช่น Re-authentication หรือใช้ Rotating Refresh Tokens)
• การเพิกถอน JWT (JWT Revocation): JWT โดยพื้นฐานไม่มีกลไกการเพิกถอนในตัว เพราะเป็น Stateless แต่สามารถทำได้โดย:
  • Blacklisting: เก็บรายการ JWT ที่ถูกเพิกถอนไว้ในฐานข้อมูล (เช่น Redis) และตรวจสอบทุกครั้งที่มีการร้องขอ
  • Short Expiration + Refresh Token: ใช้ Access Token อายุสั้น และใช้ Refresh Token ที่สามารถเพิกถอนได้
• การจำกัด Rate Limiting: ป้องกันการโจมตีแบบ Brute-force หรือ Denial-of-Service โดยการจำกัดจำนวนคำขอที่อนุญาตต่อช่วงเวลา
• การตรวจสอบ Input: ตรวจสอบและกรองข้อมูลที่ได้รับจากผู้ใช้งานอย่างเคร่งครัด เพื่อป้องกันการโจมตีแบบ Injection ต่าง ๆ
• Scope Minimal Principle: ขอสิทธิ์ (Scope) เท่าที่จำเป็นเท่านั้น อย่าขอสิทธิ์มากเกินไป

ศึกษาแนวทางปฏิบัติที่ดีที่สุดสำหรับ JWT Security

ตารางเปรียบเทียบ: OAuth 2.0 vs. JWT

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

จะเห็นได้ว่า OAuth 2.0 คือ “วิธีการ” ในการได้มาซึ่งกุญแจ (Access Token) ในขณะที่ JWT คือ “รูปแบบของกุญแจ” นั้นเองครับ ทั้งสองส่วนทำงานร่วมกันเพื่อสร้างระบบการยืนยันสิทธิ์ที่แข็งแกร่งและยืดหยุ่นครับ

คำถามที่พบบ่อย (FAQ)

เราได้รวบรวมคำถามที่พบบ่อยเกี่ยวกับ OAuth 2.0 และ JWT เพื่อช่วยให้คุณเข้าใจได้ลึกซึ้งยิ่งขึ้นครับ

OAuth 2.0 ใช้พิสูจน์ตัวตน (Authentication) ได้หรือไม่?

OAuth 2.0 โดยพื้นฐานแล้วไม่ใช่โปรโตคอลสำหรับการพิสูจน์ตัวตนครับ เป็นเพียงเฟรมเวิร์กสำหรับการอนุญาต (Authorization) กล่าวคือ มันช่วยให้แอปพลิเคชันหนึ่งได้รับสิทธิ์ในการเข้าถึงทรัพยากรของผู้ใช้งานจากบริการอื่น โดยที่ผู้ใช้งานไม่ต้องเปิดเผยรหัสผ่านครับ

อย่างไรก็ตาม OpenID Connect (OIDC) เป็น Authentication Layer ที่สร้างขึ้นบน OAuth 2.0 ซึ่งใช้ OAuth 2.0 ในการออก ID Token (ซึ่งเป็น JWT เสมอ) เพื่อใช้ในการพิสูจน์ตัวตนของผู้ใช้งานครับ ดังนั้น หากคุณต้องการพิสูจน์ตัวตนด้วย OAuth 2.0 คุณกำลังใช้ OpenID Connect อยู่ครับ

JWT ปลอดภัยแค่ไหน?

JWT มีความปลอดภัยสูงหากนำไปใช้งานอย่างถูกต้องครับ ความปลอดภัยหลัก ๆ มาจากลายเซ็นดิจิทัล (Signature) ที่ช่วยให้มั่นใจได้ว่าข้อมูลในโทเค็นไม่ถูกแก้ไขระหว่างทาง

อย่างไรก็ตาม JWT ไม่ได้เข้ารหัสส่วน Payload (เพียงแค่ Base64Url-encoded) ดังนั้นข้อมูลใน Payload สามารถถูกอ่านได้โดยใครก็ตามที่ได้รับโทเค็นครับ จึงไม่ควรเก็บข้อมูลที่ละเอียดอ่อนมาก ๆ ใน Payload นอกจากนี้ การรั่วไหลของ Secret Key ที่ใช้ในการลงชื่อ JWT จะทำให้ผู้โจมตีสามารถสร้าง JWT ปลอมขึ้นมาได้ครับ และการจัดการโทเค็นที่ถูกขโมยไป (Revocation) ก็เป็นสิ่งสำคัญที่ต้องพิจารณาครับ

ควรเก็บ JWT ไว้ที่ไหนใน Client (Browser)?

คำถามนี้เป็นที่ถกเถียงกันมากครับ แต่ละวิธีมีข้อดีข้อเสียแตกต่างกันไป:

• Local Storage/Session Storage: ง่ายต่อการใช้งานด้วย JavaScript แต่เสี่ยงต่อ XSS attacks (Cross-Site Scripting) หากมีช่องโหว่ ผู้โจมตีสามารถดึงโทเค็นไปใช้ได้
• HTTP-Only Cookies: ปลอดภัยกว่าจาก XSS เพราะ JavaScript ไม่สามารถเข้าถึงได้โดยตรง แต่ยังคงมีความเสี่ยงต่อ CSRF attacks (Cross-Site Request Forgery) ซึ่งต้องมีการป้องกันเพิ่มเติม เช่น การใช้ CSRF Token หรือการตั้งค่า SameSite cookie attribute เป็น Strict หรือ Lax
• In-memory (JavaScript variables): ปลอดภัยที่สุดจาก XSS เพราะโทเค็นไม่ได้ถูกจัดเก็บแบบถาวร แต่จะหายไปเมื่อผู้ใช้งานปิดเบราว์เซอร์หรือรีเฟรชหน้าเว็บ ทำให้ประสบการณ์ผู้ใช้งานอาจไม่ดีนัก

สำหรับแอปพลิเคชันสมัยใหม่ มักจะแนะนำให้ใช้ HTTP-Only Cookies (พร้อม SameSite=Strict) สำหรับ Refresh Token และใช้ In-memory สำหรับ Access Token ที่มีอายุสั้นครับ

Refresh Token คืออะไรและทำงานอย่างไร?

Refresh Token คือโทเค็นพิเศษที่มีอายุยาวนานกว่า Access Token ครับ มีหน้าที่หลักในการขอ Access Token ใหม่ เมื่อ Access Token เดิมหมดอายุ โดยที่ผู้ใช้งานไม่ต้องเข้าสู่ระบบใหม่ครับ

การทำงาน: เมื่อ Access Token หมดอายุ Client จะส่ง Refresh Token ที่เก็บไว้อย่างปลอดภัย (มักจะอยู่ใน HTTP-Only Cookie) ไปยัง Authorization Server เพื่อขอ Access Token ใหม่ครับ หาก Refresh Token ยังไม่หมดอายุและยังไม่ถูกเพิกถอน Authorization Server ก็จะออก Access Token ใหม่ (และอาจจะ Refresh Token ใหม่ด้วย) ให้กับ Client ครับ

Refresh Token ควรได้รับการปกป้องอย่างเข้มงวด เพราะหากถูกขโมยไป ผู้โจมตีสามารถใช้มันเพื่อสร้าง Access Token ใหม่ได้เรื่อย ๆ ครับ

จะยกเลิก JWT ที่ออกไปแล้วได้อย่างไร?

โดยธรรมชาติแล้ว JWT เป็น Stateless คือไม่มีสถานะบนเซิร์ฟเวอร์ เมื่อออกไปแล้วจะใช้ได้จนกว่าจะหมดอายุครับ การยกเลิก (Revocation) จึงไม่ใช่เรื่องง่าย ๆ แต่สามารถทำได้โดย:

• Blacklisting: เซิร์ฟเวอร์จะเก็บรายการของ JWT ที่ถูกยกเลิก (เช่น เมื่อผู้ใช้งาน Logout หรือเปลี่ยนรหัสผ่าน) ไว้ในฐานข้อมูล Blacklist (นิยมใช้ Redis เพื่อความเร็ว) และตรวจสอบโทเค็นทุกครั้งว่าอยู่ใน Blacklist หรือไม่ก่อนที่จะอนุญาตครับ
• ใช้ Access Token อายุสั้นร่วมกับ Refresh Token: ออก Access Token ที่มีอายุสั้นมาก (เช่น 5-15 นาที) และใช้ Refresh Token ที่สามารถเพิกถอนได้ครับ หากต้องการยกเลิกสิทธิ์ ก็เพียงแค่เพิกถอน Refresh Token นั้น ๆ ครับ

การเลือกวิธีขึ้นอยู่กับความต้องการด้านความปลอดภัยและความซับซ้อนของระบบครับ

OpenID Connect (OIDC) เกี่ยวข้องกับ OAuth 2.0 และ JWT อย่างไร?

OpenID Connect (OIDC) เป็นโปรโตคอลที่สร้างขึ้นบน OAuth 2.0 เพื่อใช้ในการพิสูจน์ตัวตน (Authentication) ครับ

• OIDC ใช้กระบวนการของ OAuth 2.0 ในการขออนุญาต และเพิ่มความสามารถในการส่ง ID Token กลับมาด้วย
• ID Token นี้เป็น JWT เสมอ และบรรจุข้อมูลยืนยันตัวตนของผู้ใช้งาน (เช่น sub, name, email) ครับ

ดังนั้น OIDC ใช้ OAuth 2.0 เพื่อให้ได้ ID Token (ซึ่งเป็น JWT) สำหรับการยืนยันตัวตน และอาจจะได้ Access Token (ซึ่งอาจจะเป็น JWT ด้วย) สำหรับการอนุญาตด้วยครับ

สรุปและก้าวต่อไป

เราได้เดินทางผ่านโลกอันซับซ้อนของ OAuth 2.0 และ JWT Authentication ตั้งแต่แนวคิดพื้นฐาน บทบาทของผู้เกี่ยวข้อง กลไกการทำงาน โครงสร้าง ไปจนถึงการใช้งานจริงและข้อควรพิจารณาด้านความปลอดภัยครับ คุณคงเห็นแล้วว่าทั้งสองมาตรฐานนี้มีความสำคัญและทำงานร่วมกันได้อย่างลงตัวในการสร้างระบบการยืนยันตัวตนและการอนุญาตที่ปลอดภัย ยืดหยุ่น และสามารถปรับขนาดได้ในยุคสมัยใหม่ครับ

OAuth 2.0 เป็นเฟรมเวิร์กที่ช่วยให้แอปพลิเคชันสามารถขอสิทธิ์เข้าถึงข้อมูลของผู้ใช้งานจากบริการอื่น ๆ ได้อย่างปลอดภัย โดยที่ผู้ใช้งานไม่ต้องเปิดเผยรหัสผ่านโดยตรง เป็นหัวใจสำคัญของการมอบสิทธิ์ในระบบ API และ Microservices ครับ

ส่วน JWT (JSON Web Token) คือรูปแบบของโทเค็นที่ใช้เป็น Access Token หรือ ID Token ซึ่งมีความสามารถในการบรรจุข้อมูลและลงชื่อดิจิทัล ทำให้เซิร์ฟเวอร์สามารถตรวจสอบความถูกต้องได้อย่างรวดเร็วและเป็น Stateless ช่วยลดภาระและเพิ่มประสิทธิภาพให้กับระบบครับ

การนำความรู้เหล่านี้ไปประยุกต์ใช้ต้องอาศัยความเข้าใจอย่างถ่องแท้และคำนึงถึงแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยอยู่เสมอ โดยเฉพาะอย่างยิ่งการจัดการ Secret Key, การเลือก Grant Type ที่เหมาะสม, การจัดการอายุของโทเค็น, และการพิจารณาเรื่องการเพิกถอนโทเค็นครับ

หวังว่าบทความนี้จะเป็นคู่มือฉบับสมบูรณ์ที่ช่วยให้คุณเข้าใจ OAuth 2.0 และ JWT Authentication ได้อย่างลึกซึ้ง และพร้อมที่จะนำไปพัฒนาโซลูชันที่แข็งแกร่งสำหรับเว็บไซต์และแอปพลิเคชันของคุณครับ หากคุณมีคำถามเพิ่มเติมหรือต้องการปรึกษาเกี่ยวกับการนำเทคโนโลยีเหล่านี้ไปใช้ SiamLancard.com ยินดีให้คำแนะนำและบริการด้านการพัฒนาซอฟต์แวร์ทุกประเภทครับ อย่าลังเลที่จะติดต่อเราเพื่อพูดคุยถึงความต้องการของคุณนะครับ!

ติดต่อ SiamLancard.com เพื่อปรึกษาโปรเจกต์ของคุณ

ขอให้ทุกท่านสนุกกับการพัฒนาแอปพลิเคชันที่ปลอดภัยและทรงประสิทธิภาพครับ!

ทีมงาน SiamLancard.com