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

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

การแก้ไขไม่ใช่การข้ามการยืนยันตัวตนในการทดสอบของคุณ แต่เป็นการทำให้การจัดการ Token เป็นส่วนหนึ่งของการตั้งค่าการทดสอบ เพื่อไม่ให้เป็นงานที่ต้องทำด้วยตนเองอีกต่อไป คู่มือนี้ครอบคลุมโฟลว์สองแบบที่คุณจะพบในแผนการทดสอบเกือบทุกแผน: OAuth Authorization Code Flow (พร้อม PKCE) สำหรับ API ที่ทำงานในนามของผู้ใช้ และ Client Credentials Flow สำหรับการเรียกใช้งานแบบ Machine-to-Machine หากคุณต้องการแผนภาพ Grants ทั้งหมดก่อน เรามี ภาพรวม OAuth 2.0 Flows ที่จะอธิบายทั้งหมด

จากนั้นเราจะลงมือปฏิบัติจริง: การกำหนดค่า OAuth 2.0 ใน Apidog, การดึง Token เพียงครั้งเดียวและนำกลับมาใช้ใหม่ในหลายคำขอ, การปล่อยให้ Token ที่หมดอายุรีเฟรชเอง, การสืบทอดการยืนยันตัวตนที่ระดับโฟลเดอร์ และการทดสอบเส้นทางความล้มเหลวที่การตรวจสอบความปลอดภัยของคุณจะสอบถาม

ดาวน์โหลดแอป

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

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

Authorization Code Flow พร้อม PKCE

Authorization Code Flow เป็นวิธีมาตรฐานในการรับ Token ที่ผูกกับผู้ใช้ ไคลเอนต์จะส่งผู้ใช้ไปยัง Authorization Server ผู้ใช้เข้าสู่ระบบและให้ความยินยอม เซิร์ฟเวอร์จะเปลี่ยนเส้นทางกลับพร้อมรหัสแบบใช้ครั้งเดียว และไคลเอนต์จะแลกเปลี่ยนรหัสนั้นกับ Access Token ที่ Token Endpoint RFC 6749 ได้กำหนดขั้นตอนทั้งหมดไว้ในส่วน 4.1

PKCE (Proof Key for Code Exchange, RFC 7636) เสริมความแข็งแกร่งให้กับการแลกเปลี่ยน ไคลเอนต์จะสร้างตัวตรวจสอบแบบสุ่ม ส่ง Challenge ที่แฮชพร้อมกับคำขอการอนุญาต จากนั้นพิสูจน์ว่าตนเองมีตัวตรวจสอบต้นฉบับเมื่อแลกใช้รหัส ผู้โจมตีที่ดักจับรหัสไปจะไม่สามารถนำไปใช้ได้ PKCE เริ่มต้นจากการแก้ไขสำหรับแอปพลิเคชันมือถือ แต่คำแนะนำปัจจุบันจาก oauth.net แนะนำให้ใช้สำหรับทุกการแลกเปลี่ยนรหัสการอนุญาต รวมถึง Confidential Client ด้วย

ทดสอบด้วยโฟลว์นี้เมื่อใดก็ตามที่พฤติกรรมของ Endpoint ขึ้นอยู่กับว่าผู้ใช้คือใคร: GET /orders ที่ส่งคืนเฉพาะคำสั่งซื้อของผู้เรียก, Endpoint ผู้ดูแลระบบที่จำกัดตามบทบาท, การจำกัดอัตราต่อผู้ใช้

Client Credentials Flow

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

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

นี่คือโฟลว์สำหรับ API แบบ Machine-to-Machine: ไมโครเซอร์วิสภายใน, Cron Job, CI Pipeline ที่เรียกใช้ Deployment API นอกจากนี้ยังเป็นหัวใจสำคัญของการทดสอบอัตโนมัติ เนื่องจากไม่จำเป็นต้องมีมนุษย์เข้ามาเกี่ยวข้อง หากสภาพแวดล้อมการทดสอบของคุณอนุญาตให้คุณจัดเตรียม Test Client ได้ ให้ใช้ Client Credentials สำหรับทุกอย่าง ยกเว้นกรณีที่ User Identity เป็นสิ่งที่เราต้องการทดสอบ

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

Apidog ถือว่า OAuth 2.0 เป็นประเภทการยืนยันตัวตนระดับเฟิร์สคลาส คุณกำหนดค่าเพียงครั้งเดียวในแท็บ Auth ของคำขอหรือโฟลเดอร์ และแพลตฟอร์มจะจัดการการดึง, การแนบ และการรีเฟรช Token ประเภท Grant Type ที่รองรับได้แก่ Authorization Code, Authorization Code (With PKCE), Client Credentials, Password Credentials และ Implicit

นี่คือการตั้งค่าสำหรับสองโฟลว์ข้างต้น โดยใช้ API จัดการคำสั่งซื้อที่สมมติขึ้น

การตั้งค่า Client Credentials

เปิดคำขอ (หรือดีกว่านั้นคือโฟลเดอร์; รายละเอียดเพิ่มเติมด้านล่าง), เปลี่ยนประเภทการยืนยันตัวตนเป็น OAuth 2.0 และเลือก Client Credentials เป็น Grant Type กรอกข้อมูล:

Access Token URL: https://auth.example.com/oauth/token
Client ID: orders_service
Client Secret: Secret ที่คุณจัดเตรียมไว้
Scope: orders:read orders:write (ตั้งค่าในตัวเลือกขั้นสูง)

Apidog มีสองวิธีในการส่ง Credentials ให้คุณ: เป็น Basic Auth Header หรือใน Request Body ปรับให้เข้ากับสิ่งที่ Authorization Server ของคุณต้องการ; Auth0 และ Okta ยอมรับทั้งสองแบบ แต่เซิร์ฟเวอร์ภายในบางตัวจะประมวลผลเฉพาะ Body เท่านั้น

คลิก Get Token Apidog จะเรียก Token Endpoint, จัดเก็บผลลัพธ์ และแสดง Token พร้อมกับระยะเวลาความถูกต้อง หลังจากนั้น ทุกการส่งจะแนบ Token เข้ากับ Header Authorization โดยมี Prefix เป็น Bearer ไม่ต้องคัดลอกวาง ไม่ต้องจัดการตัวแปร {{token}}

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

สำหรับการทดสอบในบริบทของผู้ใช้ ให้เลือก Authorization Code (With PKCE) เป็น Grant Type PKCE เป็นตัวเลือก Grant ของตัวเองใน Apidog ไม่ใช่แค่ช่องทำเครื่องหมาย คุณจะต้องระบุฟิลด์เพิ่มเติมอีกเล็กน้อย:

Auth URL: https://auth.example.com/oauth/authorize
Access Token URL: https://auth.example.com/oauth/token
Callback URL: URI สำหรับ Redirect ที่ลงทะเบียนกับผู้ให้บริการของคุณ
Client ID และ Client Secret: จากการลงทะเบียนแอป OAuth ของคุณ

คลิก Get Token แล้ว Apidog จะเปิดหน้าต่างเบราว์เซอร์ที่ชี้ไปยังหน้าเข้าสู่ระบบ ลงชื่อเข้าใช้ในฐานะผู้ใช้ทดสอบของคุณ อนุมัติหน้าจอความยินยอม และ Token จะถูกส่งกลับมาและจัดเก็บไว้ในช่องที่จัดการไว้เช่นเดิม หากผู้ให้บริการของคุณส่งคืน OpenID Connect ID Token พร้อมกับ Access Token ตัวเลือก Token Type Used จะช่วยให้คุณสามารถสลับได้ว่าจะแนบ Token ตัวใด; มีประโยชน์เมื่อ API ที่กำลังทดสอบตรวจสอบ ID Token

เคล็ดลับที่เป็นประโยชน์อย่างหนึ่ง: ให้มีผู้ใช้ทดสอบเฉพาะสำหรับแต่ละบทบาทที่คุณต้องการครอบคลุม (ผู้ซื้อ, ผู้ดูแลระบบ, ผู้ตรวจสอบแบบอ่านอย่างเดียว) การดึง Token ในฐานะผู้ใช้แต่ละคนและการรันสถานการณ์เดิมซ้ำเป็นวิธีที่เร็วที่สุดในการตรวจสอบกฎการเข้าถึงตามบทบาท

การนำ Token กลับมาใช้ใหม่และการรีเฟรชอัตโนมัติ

Access Token จะหมดอายุ โดยปกติจะภายในหนึ่งชั่วโมง ก่อนที่ Apidog จะจัดการเรื่องนี้ Token ที่หมดอายุหมายถึงการรันที่ล้มเหลวและการดึงซ้ำด้วยตนเอง ซึ่งเป็นความล้มเหลวที่ไม่น่าเชื่อถือประเภทที่ทีมงานมักจะเรียนรู้ที่จะมองข้าม

ตอนนี้ Apidog จะรีเฟรช OAuth 2.0 Token ด้วยตัวเองเมื่อ Authorization Server ออก Refresh Token ซึ่งเป็นคุณสมบัติที่มาพร้อมกับการ อัปเดตเดือนมิถุนายน เมื่อ Access Token ที่จัดเก็บไว้หมดอายุ Apidog จะใช้ Refresh Token เพื่อขอ Token ใหม่และเปลี่ยนแทนที่ก่อนที่จะส่ง คุณยังสามารถชี้ไปยัง URL Refresh Token ที่กำหนดเองในการตั้งค่าขั้นสูงได้ หากผู้ให้บริการของคุณแยกสอง Endpoint นี้

สำหรับ Client Credentials เซิร์ฟเวอร์หลายแห่งข้าม Refresh Token ไปโดยสิ้นเชิง (ข้อกำหนดอนุญาต เนื่องจากไคลเอนต์สามารถยืนยันตัวตนใหม่ได้ตลอดเวลา) ในทางปฏิบัติ สิ่งนี้ไม่เป็นอันตราย: การดึงซ้ำด้วย Get Token ทำได้ด้วยคลิกเดียว และการรันตามกำหนดเวลาหรือ CI สามารถร้องขอ Token ใหม่ได้เมื่อเริ่มต้นการรันแต่ละครั้ง

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

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

สิ่งนี้สำคัญที่สุดในสถานการณ์การทดสอบแบบหลายขั้นตอน สถานการณ์การชำระเงินอาจมีการต่อกันของ POST /carts, POST /carts/{id}/items และ POST /orders ด้วยการยืนยันตัวตนระดับโฟลเดอร์ ทั้งสามขั้นตอนจะใช้ Token เดียวกันและการกำหนดค่าเดียวกัน เมื่อ Token หมดอายุระหว่างสถานการณ์ การรีเฟรชอัตโนมัติจะจัดการให้ และเมื่อทีมรักษาความปลอดภัยของคุณเปลี่ยน Client Secret คุณก็อัปเดตเพียงโฟลเดอร์เดียว แทนที่จะอัปเดตคำขอสี่สิบรายการ

คำขอยังคงมีตัวเลือกในการแทนที่การกำหนดค่าจากโฟลเดอร์หลัก ซึ่งเป็นสิ่งที่คุณต้องการสำหรับการทดสอบกรณีลบ (Negative Tests) เราจะพูดถึงเรื่องนี้เพิ่มเติมในตอนนี้

การทดสอบเส้นทางความล้มเหลว

การทดสอบ OAuth แบบ Happy Path พิสูจน์ว่า Token Pipeline ของคุณทำงานได้ การทดสอบ Failure Path พิสูจน์ว่า API ของคุณบังคับใช้การยืนยันตัวตน หากคุณข้ามการทดสอบเหล่านี้ คุณกำลังเชื่อถือค่าเริ่มต้นของเฟรมเวิร์ก นี่คือสามกรณีที่ควรทำให้เป็นอัตโนมัติ; สำหรับการทบทวนความหมายของแต่ละรหัสสถานะ โปรดดูการเปรียบเทียบของเราเกี่ยวกับ API Keys และ Bearer Tokens

Token หมดอายุหรือหายไป: ควรเป็น 401

ทำซ้ำคำขอหนึ่งรายการในสถานการณ์ของคุณ และแทนที่การยืนยันตัวตนที่สืบทอดมาด้วยการไม่ใช้การยืนยันตัวตนเลย หรือใช้ Bearer Token ที่ตายไปนานแล้วที่กำหนดไว้ล่วงหน้า เช่น Bearer expired_token_do_not_rotate ตรวจสอบสิ่งต่อไปนี้:

Status code เท่ากับ 401
มี WWW-Authenticate Response Header อยู่ (RFC 6749 คู่กับ RFC 6750 คาดหวังไว้)
Body ไม่มีการรั่วไหลของ Stack Trace หรือ Internal Hostname

การได้รหัส 200 ในที่นี้ถือเป็นบั๊กที่ร้ายแรง การได้รหัส 403 เป็น Design Smell ที่ควรสร้างตั๋ว: เซิร์ฟเวอร์ควรแยกความแตกต่างระหว่าง "ฉันไม่รู้ว่าคุณเป็นใคร" กับ "ฉันรู้จักคุณ แต่ไม่ได้รับอนุญาต"

Scope ผิด: ควรเป็น 403

จัดเตรียม Test Client ตัวที่สองที่จำกัดสิทธิ์แค่ orders:read ดึง Token ของมัน แล้วเรียกใช้ Write Endpoint เช่น POST /orders ตรวจสอบว่าสถานะเป็น 403 และหาก API ของคุณเป็นไปตาม RFC 6750 Header WWW-Authenticate จะต้องมี error="insufficient_scope" การทดสอบนี้จะตรวจจับการกำหนดค่าที่ผิดพลาดแบบคลาสสิกที่ Scope ถูกตรวจสอบที่ Gateway สำหรับบางเส้นทาง แต่ถูกละเลยในเส้นทางอื่น หาก Scope เป็นเรื่องใหม่สำหรับทีมของคุณ คำอธิบาย OAuth 2.0 Scopes จะอธิบายวิธีแบ่งย่อย Scope

Invalid Client: ควรได้รับข้อผิดพลาด Token Endpoint ที่ชัดเจน

ชี้คำขอตรงไปยัง https://auth.example.com/oauth/token โดยใช้ client_secret ที่ไม่ถูกต้อง ตาม RFC 6749 ส่วน 5.2 เซิร์ฟเวอร์ควรส่งคืน 400 (หรือ 401 สำหรับการยืนยันตัวตนไคลเอนต์ล้มเหลว) พร้อม JSON Body ที่มี "error": "invalid_client" ตรวจสอบทั้งสองอย่าง Authorization Server ก็คือ API เช่นกัน และสัญญาข้อผิดพลาดของพวกมันก็เป็นส่วนหนึ่งของอินเทอร์เฟซของคุณ

การตรวจสอบการตอบสนองของ Token ในสถานการณ์การทดสอบ

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

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

สถานการณ์การทดสอบของ Apidog ช่วยให้คุณเพิ่มการตรวจสอบเหล่านี้เป็นการตรวจสอบด้วยภาพบน JSON การตอบสนอง โดยไม่จำเป็นต้องเขียนสคริปต์ และคุณสามารถดึง access_token ไปยังตัวแปรสำหรับขั้นตอนถัดไปเมื่อคุณต้องการทดสอบการจับมือแบบดิบๆ แทนที่จะใช้การยืนยันตัวตนที่จัดการไว้ เชื่อมต่อสถานการณ์นี้เข้ากับการรัน CI ของคุณ และ Authorization Server ที่ทำงานผิดปกติจะทำให้ Build ล้มเหลว แทนที่จะปรากฏเป็นรหัส 401 ที่เป็นปริศนาในการใช้งานจริง

ลูปการทำงานทั้งหมดมีดังนี้: การกำหนดค่า OAuth 2.0 ระดับโฟลเดอร์สำหรับ Happy Path, การแทนที่ต่อคำขอสำหรับกรณี 401 และ 403, และหนึ่งสถานการณ์ที่เน้นการทดสอบสัญญาของ Token Endpoint สิ่งนี้ครอบคลุม API ที่เกี่ยวข้องกับบริบทของผู้ใช้ผ่าน Authorization Code พร้อม PKCE และ API แบบ Service-to-Service ผ่าน Client Credentials พร้อมการจัดการการรีเฟรช Token ให้คุณ ดาวน์โหลด 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 และดึง Token ด้วย Get Token เมื่อ Authorization Server ส่งคืน Refresh Token, Apidog จะรีเฟรช Access Token เมื่อหมดอายุโดยที่คุณไม่ต้องยืนยันตัวตนใหม่ และคุณสามารถตั้งค่า URL Refresh Token แยกต่างหากได้ในการตั้งค่าขั้นสูง หากผู้ให้บริการของคุณใช้ สำหรับการตั้งค่า Client Credentials ที่ไม่มี Refresh Token การรัน Get Token ซ้ำจะออก Token ใหม่ให้

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

ได้ กำหนดค่า OAuth 2.0 บนโฟลเดอร์หลัก และคำขอภายในจะสืบทอดค่าเหล่านั้น ทำให้สถานการณ์แบบหลายขั้นตอนทำงานภายใต้ Token ที่จัดการไว้เพียงตัวเดียว คำขอแต่ละรายการยังคงสามารถแทนที่การกำหนดค่าของโฟลเดอร์ได้ ซึ่งเป็นวิธีที่คุณจะแทรกการทดสอบกรณีลบ (Token หมดอายุ, Scope ผิด) เข้าไปในสถานการณ์เดียวกัน

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

คืนค่า 401 เมื่อการยืนยันตัวตนล้มเหลว: Token หายไป, หมดอายุ หรือฟอร์แมตผิดพลาด คืนค่า 403 เมื่อ Token ถูกต้องแต่ขาดสิทธิ์ เช่น ขาด Scope การใช้ปะปนกันจะทำให้ Client Retry Logic พัง เพราะ 401 บอกให้ไคลเอนต์ยืนยันตัวตนใหม่ ในขณะที่ 403 บอกให้หยุด คู่มือของเราเกี่ยวกับการ ทดสอบการยืนยันตัวตน JWT จะลงรายละเอียดเกี่ยวกับการตรวจสอบ Token นั้นเอง