การขอและการอัปเดตแอ็กเซสโทเคน

แอ็กเซสโทเคน รีเฟรชโทเคน OAuth อายุการใช้งาน
บทความนี้เหมาะสำหรับใคร
สำหรับนักพัฒนาที่ต้องจัดการแอ็กเซสโทเคนสำหรับเรียกใช้ ReceiptRoller API

นำแอ็กเซสโทเคนที่ได้จาก OAuth authorization code flow มาใส่ในเฮดเดอร์ Authorization: Bearer ... เพื่อเรียก API แอ็กเซสโทเคนมีอายุการใช้งาน และต้องอัปเดตด้วยรีเฟรชโทเคนก่อนหมดอายุ

เกณฑ์อายุการใช้งาน

โทเคน อายุการใช้งาน การใช้งาน
แอ็กเซสโทเคน1 ชั่วโมงเรียก API
รีเฟรชโทเคน90 วันอัปเดตแอ็กเซสโทเคน
โค้ดอนุญาต10 นาที(ใช้ครั้งเดียว)ขอโทเคนครั้งแรก

การขอ(โค้ดอนุญาต → โทเคน)

POST https://receiptroller.io/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code={โค้ดอนุญาต}
&redirect_uri={URI ที่ลงทะเบียนไว้}
&client_id={ไคลเอนต์ ID}
&client_secret={ไคลเอนต์ซีเคร็ต}

เรสปอนส์

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "rrrt_xxxxxxxxxxxx",
  "scope": "store.read receipt.read"
}

การอัปเดต(รีเฟรชโทเคน → แอ็กเซสโทเคนใหม่)

POST https://receiptroller.io/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token={รีเฟรชโทเคน}
&client_id={ไคลเอนต์ ID}
&client_secret={ไคลเอนต์ซีเคร็ต}

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

แพตเทิร์นการอัปเดตตามจังหวะเวลา

  • อัปเดตล่วงหน้า:อัปเดตอัตโนมัติ 5 นาทีก่อนหมดอายุ(แนะนำ)
  • อัปเดตแบบหน่วง:อัปเดตหลังได้รับเออเรอร์ 401 แล้วลองใหม่
  • ใช้ทั้งล่วงหน้าและหน่วง:โดยพื้นฐานใช้แบบล่วงหน้า และเตรียมแบบหน่วงไว้เผื่อกรณีที่ล้มเหลวโดยไม่คาดคิด

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

กรณีที่ถูกเพิกถอน

  • รีเฟรชโทเคนหมดอายุ 90 วัน
  • ผู้ใช้ยกเลิกการเชื่อมต่อ
  • มีการสร้างซีเคร็ตใหม่
  • แอปถูกระงับโดยผู้ดูแลระบบ
  • ไม่มีการเข้าถึง API เป็นเวลานาน(30 วันขึ้นไป)

เมื่อถูกเพิกถอน จะส่งเออเรอร์ invalid_grant กลับมา ให้แอปนำผู้ใช้ไปยัง flow การอนุญาตใหม่

การจัดเก็บ

  • เก็บโทเคนไว้ที่ฝั่งเซิร์ฟเวอร์เท่านั้น หลีกเลี่ยงการเก็บใน local storage ของฟรอนต์เอนด์・แอปมือถือ
  • เมื่อบันทึกลง DB ให้เข้ารหัส(เช่น AES-256)
  • จัดเก็บแยกตามผู้ใช้ ไม่ปะปนกับโทเคนของผู้ใช้รายอื่น
  • ไม่พิมพ์ออกในล็อก

คู่มือที่เกี่ยวข้อง

วันที่เผยแพร่: 2569-04-27 วันที่อัปเดต: 2569-07-06