ไทย

logto
api
protection
JWT
authorization

วิธีการให้สิทธิ์ API

ในบทความนี้ เราจะสำรวจกลไกการให้สิทธิ์ API สามแบบทั่วไป ได้แก่ คีย์ API, การรับรองความถูกต้องแบบพื้นฐาน และโทเค็น OAuth JWT สุดท้ายเราจะพูดถึงวิธีที่ Logto สามารถช่วยปกป้อง API ของคุณด้วยการใช้โทเค็น OAuth JWT ได้อย่างไร

Simeng

Developer

10/16/2023

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

บทนำ

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

การปกป้อง API เป็นกระบวนการรักษาความปลอดภัย API จากการเข้าถึงโดยไม่ได้รับอนุญาต การใช้งานผิดวัตถุประสงค์ และการโจมตี เป็นองค์ประกอบที่สำคัญของกลยุทธ์ API ในบทความนี้เราจะสำรวจกลไกการปกป้อง API สามแบบที่พบเห็นได้ทั่วไป: คีย์ API, การรับรองความถูกต้องแบบพื้นฐาน และโทเค็น OAuth JWT สุดท้ายเราจะแสดงให้เห็นว่า Logto ปกป้อง API ของคุณด้วยการใช้โทเค็น OAuth JWT อย่างไร

คีย์ API

คีย์ API เป็นวิธีการรักษาความปลอดภัย API ที่ง่ายที่สุดและนิยมใช้กันอย่างแพร่หลาย คีย์ API เป็นสตริงอักขระยาวที่สร้างโดยผู้ให้บริการ API และแชร์กับผู้ใช้ที่ได้รับอนุญาต คีย์นี้จะต้องรวมอยู่ในส่วนหัวของคำขอเมื่อเข้าถึง API คีย์ API ง่ายและมีประสิทธิภาพสำหรับความต้องการด้านความปลอดภัยพื้นฐาน ตัวอย่างเช่น บริการยอดนิยมอย่าง Google Maps API และ AWS ให้คีย์ API เพื่อควบคุมการเข้าถึงและตรวจสอบการใช้งาน อย่างไรก็ตาม พวกมันมีข้อจำกัดในแง่ของความปลอดภัย มักใช้สำหรับการสื่อสารแบบเครื่องต่อเครื่อง

ตัวอย่าง

ข้อดี:

ง่ายต่อการใช้งาน: คีย์ API ติดตั้งง่าย เพียงผนวกคีย์ไปยังส่วนหัวของคำขอ ทำให้เป็นวิธีที่ตรงไปตรงมาสำหรับนักพัฒนาและลูกค้าในการทำความเข้าใจและใช้งาน
ง่ายต่อการติดตาม: คีย์ API ง่ายต่อการติดตาม คุณสามารถติดตามการใช้งานของแต่ละคีย์และเพิกถอนคีย์ได้หากจำเป็น
จำกัดอัตราที่มีประสิทธิภาพ: คีย์ API มีประสิทธิภาพสำหรับการจำกัดอัตรา คุณสามารถกำหนดขีดจำกัดจำนวนคำขอต่อคีย์เพื่อป้องกันการละเมิด
เหมาะสำหรับข้อมูลที่ไม่ละเอียดอ่อน: คีย์ API เหมาะสำหรับข้อมูลที่ไม่ละเอียดอ่อนหรือ API ที่มีให้สำหรับสาธารณะซึ่งความต้องการด้านความปลอดภัยไม่สูง

ข้อเสีย:

ความปลอดภัยที่จำกัด: คีย์ API ไม่ปลอดภัยเพียงพอสำหรับข้อมูลที่ละเอียดอ่อน โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันด้านลูกค้า มักใช้ในการสื่อสารแบบเครื่องต่อเครื่อง
ไม่เหมาะสำหรับการรับรองความถูกต้องของผู้ใช้: คีย์ API ผูกติดอยู่กับแอปพลิเคชันหรือระบบ ไม่ผูกติดกับผู้ใช้แต่ละคน ทำให้ยากต่อการระบุผู้ใช้เฉพาะหรือการติดตามการกระทำของพวกเขา
ไม่มีการหมดอายุของโทเค็น: คีย์ API มักจะคงที่และไม่หมดอายุ หากคีย์ถูกขโมย อาจถูกนำไปใช้ในทางที่ผิดตลอดไปเว้นแต่จะสร้างใหม่

การรับรองความถูกต้องแบบพื้นฐาน

การรับรองความถูกต้องแบบพื้นฐานเป็นวิธีทั่วไปอีกวิธีหนึ่งในการรักษาความปลอดภัย API เป็นรูปแบบการรับรองความถูกต้องแบบง่ายที่อยู่ในโปรโตคอล HTTP มันเกี่ยวข้องกับการส่งชื่อผู้ใช้และรหัสผ่านในส่วนหัวของคำขอ เซิร์ฟเวอร์จะตรวจสอบข้อมูลรับรองและส่งคืนทรัพยากรที่ร้องขอหากข้อมูลเป็นความจริง ตัวอย่างเช่น แอปพลิเคชันเว็บและ API แบบ RESTful หลายตัวใช้การรับรองความถูกต้องแบบพื้นฐานเป็นวิธีการรับรองความถูกต้องที่รวดเร็วและง่ายดาย การรับรองความถูกต้องแบบพื้นฐานปลอดภัยกว่าคีย์ API เพราะมันสามารถใช้ชื่อผู้ใช้และรหัสผ่านแทนคีย์คงที่ได้ อย่างไรก็ตาม มันยังไม่ปลอดภัยพอสำหรับข้อมูลที่ละเอียดอ่อน เมื่อข้อมูลประจำตัวถูกส่งในรูปแบบข้อความธรรมดา พวกมันจึงเสี่ยงต่อการถูกดักจับ การรับรองความถูกต้องแบบพื้นฐานเหมาะสำหรับระบบภายในที่การเชื่อมต่อเครือข่ายมีความปลอดภัย เช่น การสื่อสารระหว่างเครื่องกับเครื่อง

ตัวอย่าง

หรือ

ข้อดี:

ความปลอดภัยที่แข็งแกร่งขึ้น: การรับรองความถูกต้องแบบพื้นฐานปลอดภัยกว่าคีย์ API เพราะใช้ชื่อผู้ใช้และรหัสผ่านแทนคีย์คงที่
สนับสนุนอย่างกว้างขวาง: การรับรองความถูกต้องแบบพื้นฐานได้รับการยอมรับและสนับสนุนอย่างกว้างขวางโดยเซิร์ฟเวอร์เว็บและเบราว์เซอร์ส่วนใหญ่
เรียบง่าย: คล้ายกับคีย์ API การรับรองความถูกต้องแบบพื้นฐานค่อนข้างง่ายในการตั้งค่าและใช้งาน

ข้อเสีย:

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

โทเค็น OAuth JWT

JSON Web Token (JWT) ซึ่งกำหนดโดย RFC 7519 เป็นมาตรฐานเปิดสำหรับการส่งข้อมูลระหว่างฝ่ายต่าง ๆ อย่างปลอดภัยในรูปแบบ JSON มันถูกใช้กันทั่วไปในการรับรองความถูกต้องและอนุญาตในแอปพลิเคชันเว็บและ API

JWT ที่ลงนามแล้วมีรูปแบบดังนี้:

มันประกอบด้วย 3 ส่วนที่แยกด้วย . : ส่วนหัว ไจโหลด และลายเซ็น

ตัวอย่าง JWT:

header: มีข้อมูลเกี่ยวกับประเภทของโทเค็นและอัลกอริธึมการแฮชที่ใช้ลงนาม
payload: มีข้อเรียกร้อง (คำแถลง) เกี่ยวกับผู้ใช้และข้อมูลอื่นๆ
signature: เป็นการแฮชของส่วนหัวและไจโหลดที่ลงนามด้วยคีย์ลับ

OAuth เป็นมาตรฐานเปิดที่ครอบคลุมสำหรับการรักษาความปลอดภัย API และสำหรับการมอบหมายการเข้าถึงที่มักใช้เป็นวิธีการให้ผู้ใช้บริการออนไลน์อนุญาตเว็บไซต์หรือแอปพลิเคชันเข้าถึงข้อมูลของพวกเขาในเว็บไซต์อื่น ๆ โดยไม่ต้องให้รหัสผ่าน

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

หนึ่งในประโยชน์สำคัญของโทเค็น OAuth JWT คือความยืดหยุ่นของมัน สามารถใช้กับแอปพลิเคชันประเภทต่าง ๆ รวมถึงแอปเว็บและแอปมือถือ โซลูชันการลงชื่อเข้าใช้งานครั้งเดียว และอื่น ๆ ตัวอย่างเช่น แพลตฟอร์มโซเชียลมีเดียใหญ่ ๆ เช่น Facebook, Twitter, และ LinkedIn ใช้โทเค็น OAuth JWT เพื่อรับรองความถูกต้องของผู้ใช้และทำให้แอปพลิเคชันจากภายนอกสามารถเข้าถึงข้อมูลผู้ใช้อย่างปลอดภัย

ข้อดี:

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

ข้อเสีย:

ความซับซ้อน: โทเค็น OAuth JWT ซับซ้อนกว่าคีย์ API และการรับรองความถูกต้องแบบพื้นฐาน มีขั้นตอนในการตั้งค่าและใช้งาน
การจัดการโทเค็น: โทเค็น OAuth JWT ต้องจัดการและเพิกถอนเมื่อจำเป็น ซึ่งอาจเป็นเรื่องท้าทายสำหรับแอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้และลูกค้ามากมาย
การบริโภคทรัพยากร: การสร้างและการยืนยันโทเค็นอาจมีผลกระทบต่องานประมวลผล ซึ่งอาจเป็นความกังวลในสถานการณ์ที่มีการจราจรสูง

การปกป้อง API ด้วย Logto

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

Logto ให้วิธีที่ง่ายและปลอดภัยในการปกป้อง API ของคุณด้วยการใช้โทเค็น OAuth JWT มันสนับสนุนทั้งมาตรฐาน OAuth 2.0 และ OpenID Connect (OIDC) ให้คุณเลือกวิธีการรับรองความถูกต้องที่เหมาะสมกับความต้องการของคุณมากที่สุด คุณสามารถใช้ flow client_credentials สำหรับการสื่อสารแบบเครื่องกับเครื่อง และ flow authorization_code สำหรับแอปพลิเคชันเว็บ

การสื่อสารแบบเครื่องกับเครื่อง

Logto ใช้ flow client_credentials สำหรับแอปพลิเคชันประเภทเครื่องกับเครื่อง Flow นี้เหมาะสำหรับการสื่อสารบนเซิร์ฟเวอร์แบ็กเอนด์ ซึ่งลูกค้าเป็น confidential client ที่สามารถจัดเก็บข้อมูลรับรองของลูกค้าได้อย่างปลอดภัย มันเป็นที่รู้จักในชื่อ "OAuth สองขา" เพราะไม่เกี่ยวข้องกับผู้ใช้ ข้อมูลรับรองของลูกค้าจะถูกใช้โดยตรงเป็นการอนุญาตรับสิทธิ์ในการเข้าถึง

กระบวนการบูรณาการนั้นเรียบง่ายและตรงไปตรงมา:

สร้างทรัพยากร API ใน Logto Console
สร้างไคลเอนต์เครื่องต่อเครื่องใน Logto Console
ส่งคำขอไปยัง Logto token endpoint เพื่อรับสิทธิ์ในการเข้าถึง

เข้าถึงทรัพยากรที่ได้รับการปกป้องด้วยสิทธิ์ในการเข้าถึง

โปรดดู เอกสารการบูรณาการเครื่องกับเครื่อง ของเราเพื่อดูรายละเอียดเพิ่มเติม

แอปพลิเคชันเว็บ

สำหรับลูกค้าสาธารณะอย่างแอปพลิเคชันเว็บ Logto ใช้ flow authorization_code เพื่อรับรองผู้ใช้ Flow นี้เหมาะสำหรับแอปพลิเคชันเว็บที่ลูกค้าเป็น public client ที่ไม่สามารถจัดเก็บข้อมูลรับรองของลูกค้าได้อย่างปลอดภัย มันเป็นที่รู้จักในชื่อ "OAuth สามขา" เพราะเกี่ยวข้องกับผู้ใช้ ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังเซิร์ฟเวอร์รับรองเพื่อรับรองและอนุญาตลูกค้า จากนั้นลูกค้าใช้รหัสอนุญาตเพื่อรับสิทธิ์ในการเข้าถึง

กระบวนการบูรณาการซับซ้อนกว่า flow เครื่องกับเครื่องเล็กน้อย:

โปรดดูบทความของเรา Protect your Express.js API with JWT and Logto เพื่อดูตัวอย่างที่ครบถ้วนเกี่ยวกับการบูรณาการ Logto กับ React และการเข้าถึง API เซิร์ฟเวอร์ Express ของคุณด้วยโทเค็น JWT

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

บทนำ#

คีย์ API#

ข้อดี:#

ข้อเสีย:#

การรับรองความถูกต้องแบบพื้นฐาน#

ข้อดี:#

ข้อเสีย:#

โทเค็น OAuth JWT#

ข้อดี:#

ข้อเสีย:#

การปกป้อง API ด้วย Logto#

การสื่อสารแบบเครื่องกับเครื่อง#

แอปพลิเคชันเว็บ#

บทนำ#

คีย์ API#

ข้อดี:#

ข้อเสีย:#

การรับรองความถูกต้องแบบพื้นฐาน#

ข้อดี:#

ข้อเสีย:#

โทเค็น OAuth JWT#

ข้อดี:#

ข้อเสีย:#

การปกป้อง API ด้วย Logto#

การสื่อสารแบบเครื่องกับเครื่อง#

แอปพลิเคชันเว็บ#

บทนำ

คีย์ API

ข้อดี:

ข้อเสีย:

การรับรองความถูกต้องแบบพื้นฐาน

ข้อดี:

ข้อเสีย:

โทเค็น OAuth JWT

ข้อดี:

ข้อเสีย:

การปกป้อง API ด้วย Logto

การสื่อสารแบบเครื่องกับเครื่อง

แอปพลิเคชันเว็บ

บทนำ

คีย์ API

ข้อดี:

ข้อเสีย:

การรับรองความถูกต้องแบบพื้นฐาน

ข้อดี:

ข้อเสีย:

โทเค็น OAuth JWT

ข้อดี:

ข้อเสีย:

การปกป้อง API ด้วย Logto

การสื่อสารแบบเครื่องกับเครื่อง

แอปพลิเคชันเว็บ