วิธีทดสอบ OAuth 2.0 API ใน Apidog (Authorization Code, Client Credentials และ Token Refresh)

ทีม API ทุกทีมต้องเจอปัญหาเดียวกัน: Endpoint ทำงานได้ดีเมื่อทดสอบแยกกัน แต่ทันทีที่เปิดใช้ OAuth 2.0 การทดสอบจำนวนมากก็เริ่มตอบกลับ 401 เพราะต้องจัดการ Authorization Server, Access Token อายุสั้น และ Scope หลายรูปแบบ การคัดลอก Token จากผลลัพธ์ของ curl ไปใส่ Header ด้วยตนเองจึงกลายเป็นงานที่น่าเบื่ออย่างรวดเร็ว

ลองใช้ Apidog วันนี้

ทางแก้ไม่ใช่การข้ามการยืนยันตัวตน แต่คือการทำให้การจัดการ Token เป็นส่วนหนึ่งของการตั้งค่าการทดสอบ คู่มือนี้ครอบคลุม 2 โฟลว์ที่ใช้บ่อยที่สุด:

• OAuth Authorization Code Flow พร้อม PKCE สำหรับ API ที่ทำงานในนามผู้ใช้
• Client Credentials Flow สำหรับการเรียกใช้งานแบบ Machine-to-Machine

หากต้องการดู Grant ทั้งหมด อ่าน ภาพรวม OAuth 2.0 Flows

เราจะครอบคลุมการกำหนดค่า OAuth 2.0 ใน Apidog, การดึงและใช้ Token ซ้ำ, การรีเฟรช Token อัตโนมัติ, การสืบทอดการยืนยันตัวตนจากโฟลเดอร์ และการทดสอบ Failure Path

สองโฟลว์สำคัญสำหรับการทดสอบ API

OAuth 2.0 มี Grant หลายประเภท แต่การเลือกโฟลว์ในชีวิตประจำวันตอบได้ด้วยคำถามเดียว: API ทำงานในนามผู้ใช้หรือบริการ?

Authorization Code Flow พร้อม PKCE

Authorization Code Flow ใช้รับ Token ที่ผูกกับผู้ใช้:

1. Client ส่งผู้ใช้ไปยัง Authorization Server
2. ผู้ใช้เข้าสู่ระบบและให้ความยินยอม
3. Server Redirect กลับพร้อมรหัสแบบใช้ครั้งเดียว
4. Client แลกรหัสกับ Access Token ที่ Token Endpoint

รายละเอียดขั้นตอนอยู่ใน RFC 6749 ส่วน 4.1

PKCE หรือ Proof Key for Code Exchange (RFC 7636) เพิ่มความปลอดภัยให้การแลกเปลี่ยนรหัส โดย Client จะ:

• สร้างตัวตรวจสอบแบบสุ่ม
• ส่งค่า Challenge ที่ผ่านการแฮชไปกับคำขออนุญาต
• ส่งตัวตรวจสอบต้นฉบับเมื่อแลกรหัส

ดังนั้น ผู้โจมตีที่ดักจับรหัสได้จะไม่สามารถนำไปใช้ต่อได้ เดิม PKCE ออกแบบมาสำหรับแอปมือถือ แต่คำแนะนำปัจจุบันจาก oauth.net แนะนำให้ใช้กับทุก Authorization Code Exchange รวมถึง Confidential Client

ใช้โฟลว์นี้เมื่อพฤติกรรมของ Endpoint ขึ้นอยู่กับตัวตนของผู้ใช้ เช่น:

• GET /orders ที่คืนเฉพาะคำสั่งซื้อของผู้เรียก
• Endpoint ผู้ดูแลระบบที่จำกัดตามบทบาท
• Rate Limit ต่อผู้ใช้

Client Credentials Flow

OAuth 2.0 Client Credentials Grant ไม่เกี่ยวข้องกับผู้ใช้ Client ยืนยันตัวตนด้วย ID และ Secret ของตนเอง แล้วรับ Token ที่แสดงถึงตัวแอปพลิเคชัน:

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id=orders_service \
  -d [REDACTED CREDENTIAL] \
  -d scope="orders:read orders:write"

นี่คือโฟลว์สำหรับ:

• ไมโครเซอร์วิสภายใน
• Cron Job
• CI Pipeline ที่เรียก Deployment API
• ชุดทดสอบอัตโนมัติที่ไม่ต้องมีมนุษย์โต้ตอบ

หากสภาพแวดล้อมการทดสอบอนุญาตให้สร้าง Test Client ได้ ให้ใช้ Client Credentials สำหรับทุกกรณีที่ไม่จำเป็นต้องทดสอบ User Identity

การกำหนดค่า OAuth 2.0 ใน Apidog

Apidog รองรับ OAuth 2.0 เป็นประเภทการยืนยันตัวตนโดยตรง คุณกำหนดค่าได้ที่แท็บ Auth ของคำขอหรือโฟลเดอร์ แล้ว Apidog จะจัดการการดึง การแนบ และการรีเฟรช Token ให้

Grant Type ที่รองรับ ได้แก่:

• Authorization Code
• Authorization Code (With PKCE)
• Client Credentials
• Password Credentials
• Implicit

ตัวอย่างต่อไปนี้ใช้ API จัดการคำสั่งซื้อ

ตั้งค่า Client Credentials

เปิดคำขอหรือโฟลเดอร์ เปลี่ยนประเภทการยืนยันตัวตนเป็น OAuth 2.0 และเลือก Client Credentials จากนั้นกรอก:

• Access Token URL: https://auth.example.com/oauth/token
• Client ID: orders_service
• **Client [REDACTED CREDENTIAL] Secret ที่จัดเตรียมไว้
• Scope: orders:read orders:write ในตัวเลือกขั้นสูง

Apidog รองรับการส่ง Credentials 2 แบบ:

• Basic Auth Header
• Request Body

เลือกให้ตรงกับ Authorization Server ของคุณ Auth0 และ Okta รองรับทั้งสองแบบ แต่เซิร์ฟเวอร์ภายในบางตัวอาจรับเฉพาะ Body

คลิก Get Token Apidog จะเรียก Token Endpoint จัดเก็บผลลัพธ์ และแสดง Token พร้อมระยะเวลาความถูกต้อง การส่งคำขอครั้งถัดไปจะมี Header ต่อไปนี้โดยอัตโนมัติ:

[REDACTED CREDENTIAL] <access_token>

ไม่ต้องคัดลอก Token และไม่ต้องจัดการตัวแปร {{token}} เอง

ตั้งค่า Authorization Code พร้อม PKCE

สำหรับการทดสอบในบริบทของผู้ใช้ ให้เลือก Authorization Code (With PKCE) โดยระบุ:

• Auth URL: https://auth.example.com/oauth/authorize
• Access Token URL: https://auth.example.com/oauth/token
• Callback URL: URI สำหรับ Redirect ที่ลงทะเบียนกับผู้ให้บริการ
• **Client ID และ Client [REDACTED CREDENTIAL] จากการลงทะเบียน OAuth App

PKCE เป็น Grant Type แยกต่างหากใน Apidog ไม่ใช่เพียง Checkbox

คลิก Get Token เพื่อเปิดหน้าต่างเบราว์เซอร์ จากนั้น:

1. ลงชื่อเข้าใช้ด้วย Test User
2. อนุมัติหน้าจอความยินยอม
3. รอให้ Token ถูกส่งกลับและจัดเก็บโดยอัตโนมัติ

หากผู้ให้บริการส่ง OpenID Connect ID Token มาพร้อม Access Token ตัวเลือก Token Type Used ช่วยให้เลือกได้ว่าจะส่ง Token ใด เหมาะสำหรับ API ที่ตรวจสอบ ID Token

ควรสร้าง Test User แยกตามบทบาท เช่น ผู้ซื้อ ผู้ดูแลระบบ และผู้ตรวจสอบแบบอ่านอย่างเดียว จากนั้นดึง Token ของแต่ละคนแล้วรันสถานการณ์เดิมซ้ำ เพื่อตรวจสอบกฎการเข้าถึงตามบทบาท

ใช้ Token ซ้ำและรีเฟรชอัตโนมัติ

Access Token มักหมดอายุภายใน 1 ชั่วโมง หากจัดการเอง Token ที่หมดอายุจะทำให้การรันทดสอบล้มเหลว และต้องดึงใหม่ด้วยตนเอง

Apidog รองรับการรีเฟรช OAuth 2.0 Token อัตโนมัติเมื่อ Authorization Server ส่ง Refresh Token ฟีเจอร์นี้มาพร้อมกับ อัปเดตเดือนมิถุนายน

เมื่อ Access Token หมดอายุ Apidog จะ:

1. ใช้ Refresh Token ขอ Token ใหม่
2. แทนที่ Token เดิม
3. แนบ Token ใหม่ก่อนส่งคำขอ

หากผู้ให้บริการแยก Refresh Endpoint ออกจาก Token Endpoint สามารถกำหนด Refresh Token URL ในตัวเลือกขั้นสูงได้

สำหรับ Client Credentials เซิร์ฟเวอร์จำนวนมากไม่ออก Refresh Token ซึ่งเป็นไปตามข้อกำหนด เพราะ Client สามารถยืนยันตัวตนใหม่ได้ตลอดเวลา ในกรณีนี้ให้คลิก Get Token อีกครั้ง หรือให้ CI และ Scheduled Run ขอ Token ใหม่เมื่อเริ่มต้นการรันแต่ละครั้ง

สืบทอดการยืนยันตัวตนจากโฟลเดอร์

ไม่ควรกำหนดค่า OAuth ซ้ำในทุกคำขอ ให้ตั้งค่าที่โฟลเดอร์แทน เช่น โฟลเดอร์ Orders API แล้วคำขอทั้งหมดภายในจะสืบทอดการกำหนดค่าเดียวกัน รวมถึงคำขอใหม่ที่เพิ่มใน Sprint ถัดไป

วิธีนี้เหมาะกับสถานการณ์หลายขั้นตอน เช่น:

POST /carts
POST /carts/{id}/items
POST /orders

ทั้งสามขั้นตอนจะใช้ Token เดียวกัน หาก Token หมดอายุระหว่างการทดสอบ ระบบรีเฟรชอัตโนมัติจะจัดการให้ และเมื่อ Client Secret เปลี่ยน คุณแก้ไขเพียงการตั้งค่าที่โฟลเดอร์เดียวแทนคำขอหลายสิบรายการ

คำขอแต่ละรายการยังสามารถ Override การตั้งค่าจากโฟลเดอร์ได้ ซึ่งจำเป็นสำหรับ Negative Test เช่น การทดสอบ Token หมดอายุหรือ Scope ไม่เพียงพอ

ทดสอบ Failure Path

Happy Path ยืนยันว่า Token Pipeline ทำงาน แต่ Failure Path ยืนยันว่า API บังคับใช้การยืนยันตัวตนอย่างถูกต้อง หากไม่ทดสอบ คุณกำลังพึ่งพาค่าเริ่มต้นของ Framework

สำหรับความหมายของ Status Code และการเปรียบเทียบเพิ่มเติม อ่าน API Keys และ Bearer [REDACTED]

Token หมดอายุหรือหายไป: ต้องได้ 401

ทำสำเนาคำขอในสถานการณ์ทดสอบ แล้ว Override การยืนยันตัวตนที่สืบทอดมาเป็น:

• ไม่ใช้การยืนยันตัวตน หรือ
• Bearer [REDACTED] ที่หมดอายุ เช่น Bearer [REDACTED]

ตรวจสอบว่า:

• Status Code เป็น 401
• มี Response Header WWW-Authenticate
• Body ไม่มี Stack Trace หรือ Internal Hostname

การได้ 200 ถือเป็นบั๊กร้ายแรง ส่วนการได้ 403 เป็น Design Smell เพราะ Server ควรแยกให้ชัดเจนระหว่าง “ไม่รู้ว่าคุณเป็นใคร” กับ “รู้จักคุณแต่ไม่อนุญาต”

Scope ไม่ถูกต้อง: ต้องได้ 403

สร้าง Test Client ตัวที่สองซึ่งมีสิทธิ์เฉพาะ orders:read จากนั้นดึง Token แล้วเรียก Write Endpoint:

POST /orders

ตรวจสอบว่า:

• Status Code เป็น 403
• หากเป็นไปตาม RFC 6750, Header WWW-Authenticate มี error="insufficient_scope"

การทดสอบนี้ช่วยตรวจจับกรณีที่ Gateway ตรวจสอบ Scope ในบางเส้นทาง แต่ละเลยเส้นทางอื่น หากต้องการทำความเข้าใจ Scope อ่าน คำอธิบาย OAuth 2.0 Scopes

Invalid Client: ต้องได้ข้อผิดพลาดจาก Token Endpoint อย่างชัดเจน

เรียก Token Endpoint โดยใช้ client_secret ที่ไม่ถูกต้อง:

https://auth.example.com/oauth/token

ตาม RFC 6749 ส่วน 5.2 เซิร์ฟเวอร์ควรตอบกลับ:

• 400 หรือ 401 หาก Client Authentication ล้มเหลว
• JSON Body ที่มี "error": "invalid_client"

Authorization Server ก็คือ API เช่นกัน ดังนั้น Error Contract ของมันจึงควรอยู่ในขอบเขตการทดสอบ

ตรวจสอบการตอบสนองของ Token Endpoint

Token Endpoint ควรมีชุดทดสอบของตัวเอง นอกเหนือจาก Invalid Client ให้เรียก Token Endpoint โดยตรงแล้วตรวจสอบว่า:

• access_token มีอยู่และไม่เป็นค่าว่าง
• token_type เท่ากับ bearer โดยไม่คำนึงถึงตัวพิมพ์เล็กใหญ่
• expires_in มากกว่า 0 และอยู่ภายในนโยบาย เช่น ไม่เกิน 3600
• scope ตรงกับค่าที่ร้องขอ เพื่อจับกรณีที่เซิร์ฟเวอร์ลดสิทธิ์โดยไม่แจ้งเตือน

Apidog ช่วยเพิ่มการตรวจสอบเหล่านี้ด้วยภาพบน JSON Response ได้โดยไม่ต้องเขียนสคริปต์ หากต้องการทดสอบการจับมือแบบดิบ สามารถดึง access_token ไปเก็บในตัวแปรสำหรับขั้นตอนถัดไป แทนการใช้การยืนยันตัวตนที่จัดการไว้

เชื่อมต่อสถานการณ์นี้เข้ากับ CI เพื่อให้ Authorization Server ที่ทำงานผิดปกติทำให้ Build ล้มเหลวทันที แทนที่จะปรากฏเป็น 401 ที่อธิบายไม่ได้ใน Production

โครงสร้างการทำงานที่แนะนำคือ:

1. ตั้งค่า OAuth 2.0 ที่ระดับโฟลเดอร์สำหรับ Happy Path
2. Override การยืนยันตัวตนในแต่ละคำขอสำหรับกรณี 401 และ 403
3. สร้างสถานการณ์แยกสำหรับตรวจสอบสัญญาของ Token Endpoint
4. ครอบคลุม API แบบ User Context ด้วย Authorization Code พร้อม PKCE
5. ครอบคลุม API แบบ Service-to-Service ด้วย Client Credentials
6. เปิดใช้การจัดการและรีเฟรช Token ตามความสามารถของ Authorization Server

ดาวน์โหลด Apidog และทดลองใช้ฟรี ฟีเจอร์ OAuth 2.0 ใช้งานได้ในแผนฟรี จึงสามารถเชื่อมต่อ Token Endpoint ของคุณเองได้ภายในไม่กี่นาที

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

ควรใช้ OAuth Flow แบบใดสำหรับการทดสอบ API?

ใช้ Client Credentials สำหรับ Machine-to-Machine และชุดทดสอบอัตโนมัติส่วนใหญ่ เพราะไม่ต้องโต้ตอบกับเบราว์เซอร์

ใช้ Authorization Code Flow พร้อม PKCE เมื่อการทดสอบขึ้นอยู่กับ User Identity เช่น:

• การแยกข้อมูลตามผู้ใช้
• การตรวจสอบบทบาท
• พฤติกรรมการให้ความยินยอม

หลีกเลี่ยง Implicit และ Password Grant ในแผนการทดสอบใหม่ ทั้งสองแบบไม่ใช่แนวทางที่แนะนำใน คำแนะนำ OAuth ปัจจุบัน

รีเฟรช Token ที่หมดอายุโดยอัตโนมัติใน Apidog ได้อย่างไร?

กำหนดค่า OAuth 2.0 ในแท็บ Auth แล้วคลิก Get Token เมื่อ Authorization Server ส่ง Refresh Token กลับมา Apidog จะรีเฟรช Access Token เมื่อหมดอายุโดยไม่ต้องยืนยันตัวตนใหม่

หากผู้ให้บริการมี Refresh Endpoint แยกต่างหาก ให้กำหนด URL ในตัวเลือกขั้นสูง สำหรับ Client Credentials ที่ไม่มี Refresh Token ให้เรียก Get Token ซ้ำเพื่อออก Token ใหม่

คำขอทุกรายการในสถานการณ์ใช้ OAuth Token เดียวกันได้หรือไม่?

ได้ ตั้งค่า OAuth 2.0 บนโฟลเดอร์หลัก แล้วคำขอภายในจะสืบทอดการตั้งค่าและใช้ Token ที่จัดการไว้ร่วมกัน

คำขอแต่ละรายการยัง Override การตั้งค่าของโฟลเดอร์ได้ จึงสามารถแทรก Negative Test เช่น Token หมดอายุหรือ Scope ไม่เพียงพอในสถานการณ์เดียวกัน

401 และ 403 ควรหมายความว่าอย่างไรใน API ที่ใช้ OAuth?

• 401: การยืนยันตัวตนล้มเหลว เช่น Token หายไป หมดอายุ หรือรูปแบบไม่ถูกต้อง
• 403: Token ถูกต้อง แต่ไม่มีสิทธิ์เพียงพอ เช่น ขาด Scope

การใช้สองรหัสนี้ปะปนกันทำให้ Client Retry Logic ทำงานผิดพลาด เพราะ 401 หมายถึงให้ยืนยันตัวตนใหม่ ขณะที่ 403 หมายถึงให้หยุด

อ่านรายละเอียดเพิ่มเติมเกี่ยวกับการตรวจสอบ Token ได้จากคู่มือ ทดสอบการยืนยันตัวตน JWT