การรับรองความถูกต้อง

สองวิธีในการรับรองความถูกต้องกับ s.id API, API key สำหรับ server-to-server, OAuth 2.0 สำหรับการทำงานแทนผู้ใช้

การเข้าถึงแบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์

API key รับรองความถูกต้องของการเชื่อมต่อ server-to-server สร้างหนึ่งใน Dashboard → Developer → API Keys เลือกสิทธิ์ของคุณ และส่งเป็น Bearer token

ขอบเขต	สิทธิ์การเข้าถึง
`links:read`	แสดงและอ่านลิงก์
`links:write`	สร้างและอัปเดตลิงก์ (สร้าง แก้ไข กู้คืน)
`links:archive`	เก็บลิงก์เข้าคลัง
`links:analytics`	อ่านสถิติการคลิกและจำนวนคลิกตลอดอายุการใช้งานของแต่ละลิงก์
`qr:read`	อ่านการตั้งค่าคิวอาร์โค้ด (ส่วนกลางและรายลิงก์)
`qr:write`	ปรับแต่งการตั้งค่าคิวอาร์โค้ด (ส่วนกลางและรายลิงก์)
`user:read`	อ่านโปรไฟล์ผู้ใช้ที่ยืนยันตัวตนแล้วและโควตาบัญชี
`microsites:read`	อ่าน microsite
`microsites:write`	สร้าง อัปเดต และจัดการคอมโพเนนต์ของ microsite
`microsites:delete`	ลบ microsite และคอมโพเนนต์

bash

Authorization: Bearer sk_live_...

bash

curl https://api.s.id/v2/links \
  -H "Authorization: Bearer sk_live_..."

Key เริ่มต้นด้วย sk_live_ และแสดงเพียงครั้งเดียวเมื่อสร้าง
ขอเฉพาะสิทธิ์ขั้นต่ำที่การเชื่อมต่อของคุณต้องการ
เพิกถอน key ทันทีหากถูกบุกรุก, สร้างอันใหม่
อย่าเปิดเผย API key ฝั่ง client (เบราว์เซอร์, แอปมือถือ)

Authorization flow

เปลี่ยนเส้นทางผู้ใช้ไปยัง s.id เพื่อให้ความยินยอม ตรวจสอบ state ของ callback แล้วแลกรหัสแบบใช้ครั้งเดียวเป็น access token และ refresh token แบบหมุนเวียน

สร้างค่า state ที่คาดเดาไม่ได้ เก็บไว้ในเซสชันผู้ใช้ และตรวจสอบให้ตรงกันทุกประการเมื่อ callback เพื่อป้องกัน CSRF
ใช้ redirect_uri ที่ตรงกับค่าที่ลงทะเบียนไว้สำหรับแอปพลิเคชัน OAuth ของคุณทุกประการ

ต้องใช้ PKCE โดยไม่มี client secret

สำหรับ SPA แอปมือถือ และ CLI สร้าง code_verifier แบบสุ่ม ส่งค่า challenge S256 ตอนขออนุญาต แล้วส่ง verifier เดิมเมื่อแลกโทเค็น

bash

https://api.s.id/oauth/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&
  scope=links%3Aread%20links%3Awrite&
  state=RANDOM_CSRF_VALUE&
  code_challenge=BASE64URL_SHA256_VERIFIER&
  code_challenge_method=S256

bash

curl -X POST https://api.s.id/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "code_verifier=ORIGINAL_RANDOM_VERIFIER"

Client secret บนแบ็กเอนด์ที่เชื่อถือได้

สำหรับแอปพลิเคชันที่เรนเดอร์บนเซิร์ฟเวอร์หรือแบ็กเอนด์ที่เก็บ client_secret เป็นความลับได้ PKCE ยังคงเป็นตัวเลือกและแนะนำให้ใช้เพื่อเพิ่มการป้องกันหลายชั้น

bash

https://api.s.id/oauth/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&
  scope=links%3Aread%20links%3Awrite&
  state=RANDOM_CSRF_VALUE

bash

curl -X POST https://api.s.id/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://app.example.com/callback"

โทเค็นการเข้าถึง	คำอธิบาย
`access_token`	หมดอายุหลังจาก 1 ชั่วโมง
`refresh_token`	หมดอายุหลังจาก 30 วัน
`code`	ใช้ได้ครั้งเดียว และหมดอายุหลังจาก 10 นาที

bash

curl -X POST https://api.s.id/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "refresh_token=CURRENT_REFRESH_TOKEN"

bash

curl -X POST https://api.s.id/oauth/revoke \
  -H "Content-Type: application/json" \
  -d '{"token":"TOKEN_TO_REVOKE"}'

การค้นหาและการดำเนินการโทเค็น	คำอธิบาย
`https://api.s.id/.well-known/oauth-authorization-server`	ค้นหา URL ของ endpoint สโคปที่รองรับ และวิธี PKCE ผ่านข้อมูลเมตา RFC 8414
`POST /oauth/introspect`	เซิร์ฟเวอร์ทรัพยากรลับสามารถตรวจสอบว่าโทเค็นยังใช้งานอยู่และดูสโคปของโทเค็นได้
`POST /oauth/revoke`	เพิกถอน access token หรือ refresh token เมื่อผู้ใช้ยกเลิกการเชื่อมต่อกับระบบของคุณ
`GET /oauth/userinfo`	อ่านโปรไฟล์ที่เชื่อมโยงกับโทเค็นการเข้าถึง OAuth ที่มี user:read

เปิด Developer Dashboard