การขอและการอัปเดตแอ็กเซสโทเคน
แอ็กเซสโทเคน
รีเฟรชโทเคน
OAuth
อายุการใช้งาน
บทความนี้เหมาะสำหรับใคร
สำหรับนักพัฒนาที่ต้องจัดการแอ็กเซสโทเคนสำหรับเรียกใช้ ReceiptRoller API
สำหรับนักพัฒนาที่ต้องจัดการแอ็กเซสโทเคนสำหรับเรียกใช้ 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
หมวดหมู่
แท็ก
API (22)
OAuth (15)
Android (10)
iOS (9)
Webhook (8)
api (7)
oauth (5)
getting-started (4)
การลงทะเบียนแอป (4)
การแก้ปัญหา (4)