API Documentation

Overview

1. Single Sign-On (SSO)

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

2. ความสำคัญของ KMUTNB Single Sign-On (KMUTNB SSO)

KMUTNB Single Sign-On (SSO) ได้รับการพัฒนาเพื่อตอบสนองความต้องการด้านความปลอดภัยและความสะดวกสบายในการเข้าถึงระบบสารสนเทศของมหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ โดยมีวัตถุประสงค์หลักเพื่อ

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

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

3. การใช้ Multi-Factor Authentication (MFA)

เพื่อเพิ่มความปลอดภัยของระบบ SSO KMUTNB ยังได้นำการตรวจสอบตัวตนแบบหลายปัจจัย (Multi-Factor Authentication - MFA) มาใช้เป็นส่วนหนึ่งของกระบวนการล็อกอิน ซึ่งช่วยป้องกันการเข้าถึงระบบโดยไม่ได้รับอนุญาตจากผู้ที่ไม่ใช่เจ้าของบัญชีจริง MFA เพิ่มความปลอดภัยโดยการตรวจสอบข้อมูลเพิ่มเติม เช่น การใช้งาน Passcode หรือการใช้แอปพลิเคชันที่สร้างรหัสชั่วคราว เพื่อยืนยันตัวตนของผู้ใช้ในขณะที่ทำการเข้าสู่ระบบ

4. ความสำคัญของ KMUTNB SSO ต่อผู้ใช้

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

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

5. การพัฒนาและการดูแลรักษา

KMUTNB SSO ได้รับการพัฒนาและดูแลโดยสำนักคอมพิวเตอร์และเทคโนโลยีสารสนเทศ ซึ่งมีหน้าที่ในการพัฒนาและดูแลระบบสารสนเทศของมหาวิทยาลัย เพื่อให้แน่ใจว่าระบบมีความเสถียรและปลอดภัยตลอดเวลา สำนักคอมพิวเตอร์ฯ จะดำเนินการตรวจสอบและอัปเดตระบบอย่างต่อเนื่องเพื่อรองรับความต้องการที่เปลี่ยนแปลงไปและพัฒนาให้สอดคล้องกับเทคโนโลยีใหม่ ๆ

6. นโยบายเกี่ยวกับข้อมูลส่วนบุคคล

การขอสิทธิ์ใช้งาน API

กรุณาส่งแบบบันทึกขอเปิดใช้งาน ICIT Account API มาที่

สำนักคอมพิวเตอร์และเทคโนโลยีสารสนเทศ มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ (ติดต่อเรา)

แบบบันทึกขอเปิดใช้งาน ICIT Account API

การใช้งาน KMUTNB SSO API

การใช้งาน KMUTNB SSO API มีขั้นตอนดังนี้

1. การเตรียมความพร้อม

ศึกษาเอกสารประกอบการพัฒนาให้เข้าใจ
เตรียมข้อมูลแอปพลิเคชันที่จะขอใช้งาน เช่น ชื่อแอปพลิเคชัน คำอธิบาย หน่วยงานที่รับผิดชอบ
เตรียม URLs ที่จำเป็น: Homepage URL, Callback URL (ต้องเป็น HTTPS)
กำหนด Scope ที่ต้องการใช้งานให้ชัดเจน

2. การลงทะเบียนแอปพลิเคชัน

เข้าสู่ระบบที่ https://sso.kmutnb.ac.th ด้วยบัญชี ICIT Account
เลือกเมนู "จัดการแอป"
เลือกเมนู "เพิ่มแอปพลิเคชัน" และกรอกข้อมูลให้ครบถ้วน
เมื่อลงทะเบียนแอปพลิเคชันสำเร็จจะได้รับ Client ID และ Client Secret สำหรับการพัฒนา

3. การทดสอบระบบ (Development Mode)

ระบุ Username สำหรับทดสอบในโหมด Development
พัฒนาและทดสอบระบบตามมาตรฐานที่กำหนด
ตรวจสอบการทำงานของระบบให้ครบทุกฟังก์ชัน
ทดสอบการจัดการ Error cases ต่างๆ

4. การขออนุมัติใช้งานจริง (Approved Mode)

ตรวจสอบให้แน่ใจว่าระบบผ่านเกณฑ์การพิจารณาทั้งหมด
ส่งคำขอเปลี่ยนโหมดการทำงานเป็น Approved Mode
รอการตรวจสอบจากสำนักคอมพิวเตอร์ฯ (3-5 วันทำการ)
เมื่อได้รับอนุมัติ สามารถใช้งานกับผู้ใช้ทั่วไปได้ทันที

ข้อควรทราบ:

การพัฒนาต้องเป็นไปตามมาตรฐานความปลอดภัยที่กำหนด
ต้องมีการจัดการ Error Response อย่างเหมาะสม
ควรมีเอกสารประกอบการใช้งานสำหรับผู้ใช้
มีช่องทางติดต่อผู้ดูแลระบบที่ชัดเจน
หากมีการเปลี่ยนแปลงข้อมูลสำคัญ ต้องแจ้งผู้ดูแลระบบทุกครั้ง

ภาพรวมการทำงาน

ขอ Authorization Code
- แอปพลิเคชันส่งผู้ใช้ไปยังหน้า Login ของ KMUTNB SSO
- ส่งพารามิเตอร์สำคัญ: client_id, redirect_uri, scope ที่ต้องการเข้าถึง
- ผู้ใช้งานจะเห็นหน้าจอ Login (กรณียังไม่ได้เข้าสู่ระบบ)
ผู้ใช้ยืนยันตัวตนและอนุญาต
- ผู้ใช้เข้าสู่ระบบด้วยบัญชี KMUTNB SSO
- ระบบแสดงหน้าขออนุญาตเข้าถึงข้อมูลตาม scope ที่แอปพลิเคชันร้องขอ
- เมื่อผู้ใช้อนุญาต ระบบจะส่ง Authorization Code กลับมาที่ redirect_uri
แลก Code เป็น Token
- แอปพลิเคชันส่ง Authorization Code พร้อม client_id และ client_secret ไปยัง Token Endpoint
- ต้องส่ง redirect_uri เดิมที่ใช้ในขั้นตอนแรก
- หากข้อมูลถูกต้อง ระบบจะตอบกลับด้วย Access Token
ใช้งาน Access Token
- ใช้ Token เรียก API ตาม scope ที่ได้รับอนุญาต
- ส่ง Token ในรูปแบบ Bearer Authentication
- เก็บ Token ไว้ใช้งานจนกว่าจะหมดอายุ

ข้อควรระวัง

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

การลงทะเบียนแอปพลิเคชัน

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

พารามิเตอร์	คำอธิบาย	หมายเหตุ
Application Name	ชื่อของแอปพลิเคชันที่จะใช้แสดงต่อผู้ใช้งานในกระบวนการเข้าสู่ระบบ	เช่น "Human Resource Information System"
Application Description	คำอธิบายสั้น ๆ เกี่ยวกับแอปพลิเคชัน เพื่อช่วยให้ผู้ใช้งานเข้าใจจุดประสงค์ของแอปพลิเคชัน	เช่น "ระบบสารสนเทศข้อมูลทรัพยากรมนุษย์"
หน่วยงานที่จัดการ	หน่วยงานเป็นผู้ดูแลและจัดการแอปพลิเคชันนี้	เช่น "สำนักคอมพิวเตอร์และเทคโนโลยีสารสนเทศ"
Homepage URL	URL ของหน้าแรกของแอปพลิเคชันที่จะแสดงข้อมูลหรือบริการแก่ผู้ใช้งาน	ต้องเป็น HTTPS เท่านั้น
Login URL	URL สำหรับการ Login ของแอปพลิเคชันผ่าน KMUTNB SSO (Auto redirect to KMUTNB SSO if not logged in) โดยหากผู้ใช้งานยังไม่ได้เข้าสู่ระบบให้ redirect มายัง KMUTNB SSO เพื่อให้ผู้สามารถเข้าสู่ระบบได้อย่างสะดวก แต่หากผู้ใช้งานได้เข้าสู่ระบบแล้ว ให้ redirect ไปหน้าสำหรับผู้ใช้งานของแอปพลิเคชันได้เลย	ต้องรองรับการ Auto-redirect
Redirect URI	URL ของแอปพลิเคชันที่ต้องการให้ KMUTNB SSO ส่ง authorization code กลับหลังจากการยืนยันตัวตนสำเร็จ สามารถระบุได้หลาย URI เช่น: Production: https://app.kmutnb.ac.th/auth/callback Development: https://dev.app.kmutnb.ac.th/auth/callback Local: http://localhost:3000/auth/callback	ต้องใช้ HTTPS (ยกเว้น localhost ในโหมด Development) แนะนำให้ใช้ path: /auth/callback, /oauth/callback, หรือ /sso/return หลีกเลี่ยงการใช้ Query Parameters
Scope	สิทธิ์ในการเข้าถึงข้อมูลหรือฟังก์ชันต่าง ๆ ที่แอปพลิเคชันจะร้องขอจากผู้ใช้งาน	เลือกเฉพาะ scope ที่จำเป็น
Allowed Account Types for Login	ประเภทบัญชีที่อนุญาตให้เข้าสู่ระบบในแอปพลิเคชันนี้	เช่น นักศึกษา, บุคลากร
Specific Username for Login	ระบุ Username เพื่อใช้สำหรับการ Login ในขั้นตอนการพัฒนาระบบ ซึ่งจำเป็นต้องใช้ในระหว่างที่แอปพลิเคชัน Development mode ก่อนที่สำนักคอมพิวเตอร์ฯ จะตรวจสอบและอนุมัติการใช้งานแอปพลิเคชันเพื่อเปลี่ยนเป็น Approved mode	ใช้เฉพาะในโหมด Development

เมื่อลงทะเบียนสำเร็จ คุณจะได้รับ

Client ID: รหัสเฉพาะสำหรับแอปพลิเคชันของคุณ
Client Secret: รหัสลับที่ใช้ในการยืนยันตัวตนของแอปพลิเคชัน

สำคัญ: เก็บรักษา Client Secret ไว้ในที่ปลอดภัยและห้ามเปิดเผยต่อผู้อื่น

Scopes

Scopes เป็นกลไกการควบคุมการเข้าถึงข้อมูลในระบบ KMUTNB SSO ที่ช่วยให้ผู้ใช้งานสามารถมั่นใจได้ว่าแอปพลิเคชันจะเข้าถึงเฉพาะข้อมูลที่จำเป็นและได้รับอนุญาตเท่านั้น เมื่อแอปพลิเคชันต้องการเข้าถึงข้อมูลส่วนบุคคล เช่น ชื่อ-นามสกุล รหัสนักศึกษา อีเมล คณะ/ภาควิชา หรือสถานะการเป็นนักศึกษา/บุคลากร ระบบจะแสดงหน้าจอขออนุญาตให้ผู้ใช้งานยืนยันการให้สิทธิ์ก่อนเสมอ ผู้พัฒนาควรขอเฉพาะ scope ที่จำเป็นต่อการทำงานของแอปพลิเคชันจริง ๆ เพื่อสร้างความไว้วางใจและความมั่นใจในความปลอดภัยให้แก่ผู้ใช้งาน

Scope ที่ใช้ได้:

Scope	Description
profile	Profile (username, display_name, account_type) username: ชื่อบัญชีผู้ใช้งาน dispay_name: ชื่อ-สกุล account_type: ประเภทบัญชีผู้ใช้งาน personnel = บุคลากร student = นักศึกษา templecturer = อาจารย์พิเศษ retirement = ผู้เกษียณอายุ exchange_student = นักศึกษาแลกเปลี่ยนชาวต่างประเทศจากศูนย์ความร่วมมือนานาชาติ สนอ. (ICC) alumni = ศิษย์เก่า guest = ผู้ใช้งานชั่วคราว
person_key	รหัสอ้างอิงข้อมูลบุคลากรใน HRIS ใช้สำหรับการอ้างอิงข้อมูลการ login ในกรณีที่แอปพลิเคชันมีการเชื่อมโยงกับ API ของ HRIS อยู่แล้ว (ถ้ามีการใช้งาน scope personnel_info ไม่จำเป็นต้องกำหนด scope นี้)
personnel_info	ข้อมูลบุคลากรจากระบบ HRIS ประกอบด้วย รหัสบุคลากร (person_key) คำนำหน้าชื่อ ชื่อ-สกุล (ภาษาไทย, ภาษาอังกฤษ) ประเภทบุคลากร สายงานบุคลากร ตําแหน่ง ส่วนงาน (คณะ/สำนัก/สถาบัน, ภาควิชา/ฝ่าย/กอง) ภาพบุคลากร
student_info	ข้อมูลนักศึกษาจากระบบ REG ประกอบด้วย รหัสประจําตัวนักศึกษา คำนำหน้าชื่อ ชื่อ-สกุล (ภาษาไทย, ภาษาอังกฤษ) เพศ ระดับการศึกษา ชั้นปี วิทยาเขต คณะ ภาควิชา สาขาวิชา สถานภาพการศึกษา
email	อีเมล @kmutnb.ac.th
pid	เลขประจำตัวประชาชน (ใช้งานได้เฉพาะแอปพลิเคชันที่ได้รับอนุญาตเท่านั้น)

Authentication

1. Authorization Request

Authorization Request คือกระบวนการที่แอปพลิเคชันขออนุญาตเข้าถึงข้อมูลผู้ใช้งานผ่าน KMUTNB SSO โดยระบบจะสร้าง URL พร้อมพารามิเตอร์ที่จำเป็นเพื่อส่งคำขอไปยัง KMUTNB SSO เมื่อผู้ใช้ยืนยันตัวตนและอนุญาตการเข้าถึงเรียบร้อยแล้ว ระบบจะส่งผู้ใช้กลับมายังแอปพลิเคชันพร้อม Authorization Code ที่จะใช้แลกเปลี่ยนเป็น Access Token ในขั้นตอนต่อไป ซึ่งจำเป็นต้องระบุพารามิเตอร์สำคัญดังนี้

Authorization Endpoint:

GET https://sso.kmutnb.ac.th/auth/authorize

Query parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
response_type required	รูปแบบการตอบกลับที่ต้องการ สำหรับ OAuth 2.0 ใช้ค่า "code"	`code`
client_id required	รหัสที่ระบุตัวตนของแอปพลิเคชัน ได้รับหลังจากลงทะเบียนแอปพลิเคชัน	`a1b2c3d4e5f6g7h8`
redirect_uri required	URL ที่ต้องการให้ระบบส่งผู้ใช้กลับมาหลังจากยืนยันตัวตนสำเร็จ ต้องตรงกับที่ลงทะเบียนไว้	`https://app.kmutnb.ac.th/callback`
scope required	ขอบเขตของข้อมูลที่ต้องการร้องขอสิทธิ์การเข้าถึงข้อมูลจากผู้ใช้งาน สามารถระบุได้หลายรายการโดยใช้รูปแบบใดรูปแบบหนึ่งต่อไปนี้: ใช้การเว้นวรรค: `profile pid email` ใช้ URL encoded (%20): `profile%20pid%20email` ใช้เครื่องหมายบวก: `profile+pid+email` หมายเหตุ: ทั้งสามรูปแบบให้ผลลัพธ์เหมือนกัน แนะนำให้ใช้ URL encoded (%20) เพื่อความเข้ากันได้กับทุกระบบ	`profile pid email` `profile%20pid%20email` `profile+pid+email`
state recommended	ค่าที่ใช้ป้องกันการโจมตีแบบ CSRF ควรเป็นค่าสุ่มที่ไม่สามารถคาดเดาได้ ซึ่งค่านี้จะถูกส่งกลับเป็นค่าเดียวกันกับที่ระบุมา หลังจากผู้ใช้งานเข้าสู่ระบบสำเร็จ	`xyz123`

Sample request:

    https://sso.kmutnb.ac.th/auth/authorize?
    response_type=code&
    client_id={client_id}&
    redirect_uri={redirect_uri}&
    scope={scope}&
    state={state}

Sample response:

{redirect_uri}?code={authorization_code}&state={state}

Response description:

code: authorization_code ที่ได้รับหลังจากผู้ใช้อนุมัติสิทธิ์ โดยโค้ดนี้สามารถนำไปแลกเป็น access_token ในขั้นตอนถัดไป
state: เป็นค่าเดียวกันกับ state ที่แอปพลิเคชันส่งมาเพื่อป้องกันการโจมตี CSRF (Cross-Site Request Forgery) เป็นค่าที่ส่งกลับมาพร้อมกันเพื่อความมั่นใจว่า response นั้นถูกต้อง

2. Token Request

Request Token คือขั้นตอนที่แอปพลิเคชันนำ Authorization Code ที่ได้รับมาแลกเปลี่ยนเป็น Access Token โดยส่งคำขอไปยัง Token Endpoint ของ KMUTNB SSO พร้อมข้อมูลยืนยันตัวตนของแอปพลิเคชัน (Client ID และ Client Secret) เมื่อการตรวจสอบสำเร็จ ระบบจะส่งกลับ Access Token ที่สามารถใช้เข้าถึงข้อมูลตาม Scope ที่ได้รับอนุญาต

Token Endpoint:

POST https://sso.kmutnb.ac.th/auth/token

Request header parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
Authorization required	กำหนดค่าเป็น Basic Base64({client_id}:{client_secret}) ใช้สำหรับส่งข้อมูลยืนยันตัวตนของแอปพลิเคชันในรูปแบบ Base64	`Basic dGVzdF9jbGllbnQ6dGVzdF9zZWNyZXQ=`
Content-Type required	กำหนดค่าเป็น application/x-www-form-urlencoded ใช้สำหรับระบุรูปแบบข้อมูลที่ส่งในการเรียก Token Endpoint	`application/x-www-form-urlencoded`

Request body parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
grant_type required	ระบุประเภทการขอ Token ต้องใช้ค่า "authorization_code"	`authorization_code`
code required	Authorization Code ที่ได้รับจากขั้นตอน Authorization Request	`abc123xyz789`
redirect_uri required	URL ที่ใช้รับ Authorization Code ต้องตรงกับที่ใช้ในขั้นตอน Authorization Request	`https://app.kmutnb.ac.th/callback`

Sample request:

    POST https://sso.kmutnb.ac.th/auth/token HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic {base64(client_id:client_secret)}
    Accept: application/json

    grant_type=authorization_code&code={authorization_code}&redirect_uri={redirect_uri}

Response description:

Response Parameter	คำอธิบาย	ตัวอย่าง
access_token string	Token ที่ใช้ในการเข้าถึงทรัพยากรที่ได้รับอนุญาต ตาม scope ที่กำหนด	`eyJhbGciOiJS...`
expires_in number	ระบุเวลาหมดอายุของ access token ในหน่วยวินาที (3600 วินาที = 1 ชั่วโมง)	`3600`
token_type string	ระบุประเภทของ token ซึ่งในกรณีนี้เป็น Bearer token	`Bearer`
scope string	ขอบเขตการเข้าถึงข้อมูลที่ได้รับอนุญาต โดยในตัวอย่างนี้มีสิทธิ์เข้าถึงข้อมูล profile, pid, email, personnel_info, และ student_info	`profile pid email personnel_info student_info`
refresh_token string	Token ที่ใช้ในการขอ access token ใหม่เมื่อ access token หมดอายุ	`def456...`

Sample response:

    {
        "access_token": : {access_token},
        "expires_in": : "3600"
        "token_type": : "Bearer",
        "scope": : "profile pid email personnel_info student_info",
        "refresh_token": : {refresh_token}
    }

3. Refresh Token

Access Token มีอายุการใช้งานจำกัด เมื่อหมดอายุ คุณสามารถใช้ Refresh Token เพื่อขอ Access Token ใหม่ได้ โดยไม่ต้องให้ผู้ใช้ login ใหม่

Request parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
grant_type required	กำหนดค่าเป็น "refresh_token" เพื่อระบุว่าต้องการใช้ Refresh Token ในการขอ Access Token ใหม่	`refresh_token`
refresh_token required	Refresh Token ที่ได้รับจากระบบในครั้งแรก	`xyz...789`
client_id required	รหัสแอปพลิเคชันที่ได้รับตอนลงทะเบียน	`abc...123`
client_secret required	รหัสลับของแอปพลิเคชัน	`def...456`

ตัวอย่างการเรียก API:

POST https://sso.kmutnb.ac.th/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64(client_id:client_secret)}

grant_type={refresh_token}&refresh_token=xyz...789

ข้อควรระวัง:

Refresh Token จะถูกยกเลิกทันทีหลังจากใช้งาน ต้องใช้ Token ใหม่ที่ได้รับในครั้งถัดไป
หากมีการใช้งาน Refresh Token ที่ไม่ถูกต้องหรือหมดอายุ ระบบอาจบังคับให้ผู้ใช้ต้อง login ใหม่
ควรเก็บ Refresh Token ไว้ในที่ปลอดภัย เช่นเดียวกับ client_secret

4. Revoke Token

Revoke the access token (ยังไม่เปิดใช้งาน)

เมื่อต้องการยกเลิกสิทธิ์การเข้าถึงของแอปพลิเคชัน คุณสามารถเพิกถอน Access Token ได้ โดยการเรียกใช้ Revocation Endpoint เพื่อป้องกันการใช้งาน Token โดยไม่ได้รับอนุญาต

Request parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
token required	Access Token หรือ Refresh Token ที่ต้องการเพิกถอน	`xyz...789`
token_type_hint optional	ระบุประเภทของ Token ที่ต้องการเพิกถอน (access_token หรือ refresh_token)	`access_token`
client_id required	รหัสแอปพลิเคชันที่ได้รับตอนลงทะเบียน	`abc...123`
client_secret required	รหัสลับของแอปพลิเคชัน	`def...456`

ตัวอย่างการเรียก API:

POST https://sso.kmutnb.ac.th/revoke
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64(client_id:client_secret)}

token={xyz...789}&token_type_hint={access_token}

ข้อควรระวัง:

หลังจากเพิกถอนแล้ว Token จะไม่สามารถใช้งานได้อีก
การเพิกถอน Access Token จะไม่ส่งผลต่อ Refresh Token และในทางกลับกัน
หากต้องการยกเลิกการเข้าถึงทั้งหมด ควรเพิกถอนทั้ง Access Token และ Refresh Token

Revoke the refresh token (ยังไม่เปิดใช้งาน)

เมื่อต้องการยกเลิก Refresh Token เพื่อป้องกันไม่ให้แอปพลิเคชันขอ Access Token ใหม่ได้อีก สามารถทำได้โดยส่งคำขอไปที่ Revocation Endpoint เช่นเดียวกับการเพิกถอน Access Token

Request parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
token required	Refresh Token ที่ต้องการเพิกถอน	`xyz...789`
token_type_hint optional	ระบุค่าเป็น "refresh_token" เพื่อแจ้งว่ากำลังเพิกถอน Refresh Token	`refresh_token`
client_id required	รหัสแอปพลิเคชันที่ได้รับตอนลงทะเบียน	`abc...123`
client_secret required	รหัสลับของแอปพลิเคชัน	`def...456`

ตัวอย่างการเรียก API:

POST https://sso.kmutnb.ac.th/revoke
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64(client_id:client_secret)}

token={xyz...789}&token_type_hint={refresh_token}

ข้อควรระวัง:

การเพิกถอน Refresh Token จะป้องกันการขอ Access Token ใหม่ แต่ไม่ส่งผลต่อ Access Token ที่มีอยู่
หากต้องการยกเลิกการเข้าถึงทั้งหมด ควรเพิกถอนทั้ง Access Token และ Refresh Token
หลังจากเพิกถอนแล้ว ผู้ใช้จะต้อง login และอนุญาตสิทธิ์ใหม่หากต้องการใช้งานแอปพลิเคชันอีกครั้ง

5. Token Introspection

การตรวจสอบสถานะและข้อมูลของ Token สามารถทำได้โดยการเรียกใช้ Introspection Endpoint เพื่อยืนยันว่า Token ยังใช้งานได้และดูรายละเอียดต่างๆ เช่น scope, วันหมดอายุ

Request parameters:

พารามิเตอร์	คำอธิบาย	ตัวอย่าง
token required	Token ที่ต้องการตรวจสอบ (Access Token หรือ Refresh Token)	`xyz...789`
token_type_hint optional	ประเภทของ Token ที่ส่งมาตรวจสอบ (access_token หรือ refresh_token)	`access_token`

ตัวอย่างการเรียก API:

POST https://sso.kmutnb.ac.th/introspect
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64(client_id:client_secret)}

token={xyz...789}&token_type_hint={access_token}

ตัวอย่างการตอบกลับ:

{
    "active": true,
    "scope": "profile email",
    "client_id": "abc123",
    "username": "user123",
    "exp": 1716239022,
    "sub": "12345",
    "iss": "https://sso.kmutnb.ac.th",
    "token_type": "Bearer"
}

หมายเหตุ:

ค่า "active": true แสดงว่า Token ยังใช้งานได้
ค่า "active": false แสดงว่า Token ถูกเพิกถอน หมดอายุ หรือไม่ถูกต้อง
ค่า "exp" คือเวลาหมดอายุในรูปแบบ Unix timestamp
ข้อมูลที่ได้รับกลับมาขึ้นอยู่กับสิทธิ์ของแอปพลิเคชันที่ทำการตรวจสอบ

6. User Information

เมื่อได้รับ Access Token แล้ว คุณสามารถดึงข้อมูลผู้ใช้งานได้โดยส่ง Request ไปยัง UserInfo Endpoint ระบบจะส่งข้อมูลกลับมาตาม Scope ที่ได้รับอนุญาต

Userinfo Endpoint:

GET https://sso.kmutnb.ac.th/resources/userinfo

Query parameters:

Headers	คำอธิบาย	ตัวอย่าง
Authorization required	Access Token ในรูปแบบ Bearer authentication	`Bearer xyz...789`

HTTP GET examples:

GET https://sso.kmutnb.ac.th/resources/userinfo
Authorization: Bearer {access_token}

GET https://sso.kmutnb.ac.th/resources/userinfo?access_token={access_token}

curl example:

curl -X GET -H "Authorization: Bearer {access_token}" https://sso.kmutnb.ac.th/resources/userinfo

curl https://sso.kmutnb.ac.th/resources/userinfo?access_token={access_token}

Sample response:

{
    "profile": {
        "username": "siwakornl",
        "display_name": "ศิวกร หลงสมบูรณ์",
        "account_type": "personnel",
        "pid": "1234567890123",
        "email": "vTqZG@kmutnb.ac.th",
        "person_key": "1234567890123",
    },
    "personnel_info": {

    },
    "student_info": {

    }
}

หมายเหตุ:

ข้อมูลที่ได้รับจะขึ้นอยู่กับ Scope ที่ขอไว้ตอนเริ่มต้น OAuth Flow
Access Token ต้องยังไม่หมดอายุและไม่ถูกเพิกถอน
หากต้องการข้อมูลเพิ่มเติม ต้องขอ Scope ที่เหมาะสมตั้งแต่ขั้นตอนลงทะเบียนแอปพลิเคชัน

Error Responses

เมื่อเกิดข้อผิดพลาด ระบบจะส่งกลับ HTTP status code และ error response ในรูปแบบ JSON พร้อมรายละเอียดของข้อผิดพลาด

Error Response:

{
    "error": "error_code",
    "error_description": "รายละเอียดข้อผิดพลาด",
    "error_uri": "URL สำหรับดูข้อมูลเพิ่มเติม (ถ้ามี)"
}

HTTP Status Code:

HTTP Status	Error Code & Description	คำอธิบาย	วิธีการแก้ไข
400	invalid_request The request is missing a required parameter, includes an invalid parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.	คำขอไม่ถูกต้อง เช่น ขาดพารามิเตอร์ที่จำเป็น มีค่าพารามิเตอร์ที่ไม่ถูกต้อง มีพารามิเตอร์ซ้ำ มีการยืนยันตัวตนหลายรูปแบบ	ตรวจสอบพารามิเตอร์ที่จำเป็นให้ครบถ้วน ตรวจสอบรูปแบบและค่าของพารามิเตอร์ให้ถูกต้อง ใช้วิธีการยืนยันตัวตนเพียงวิธีเดียว
400	invalid_client Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method).	การยืนยันตัวตนของแอปพลิเคชันไม่สำเร็จ เช่น ไม่พบข้อมูลแอปพลิเคชัน ไม่ได้ส่งข้อมูลยืนยันตัวตน รูปแบบการยืนยันตัวตนไม่ถูกต้อง	ตรวจสอบ Client ID และ Client Secret ให้ถูกต้อง ตรวจสอบว่าแอปพลิเคชันได้รับการอนุมัติแล้ว ใช้วิธีการยืนยันตัวตนตามที่กำหนด
400	invalid_grant The provided authorization grant is invalid, expired, revoked, does not match the redirection URI, or was issued to another client.	รหัสการอนุญาตไม่ถูกต้อง เช่น รหัสหมดอายุ รหัสถูกใช้งานไปแล้ว Redirect URI ไม่ตรงกับที่ลงทะเบียน รหัสถูกออกให้กับแอปพลิเคชันอื่น	ขอรหัสอนุญาตใหม่ ตรวจสอบ Redirect URI ให้ตรงกับที่ลงทะเบียน ใช้รหัสอนุญาตทันทีที่ได้รับ ตรวจสอบว่าใช้ Client ID ถูกต้อง
400	unauthorized_client The authenticated client is not authorized to use this authorization grant type.	แอปพลิเคชันไม่ได้รับอนุญาตให้ใช้วิธีการยืนยันตัวตนนี้	ตรวจสอบสิทธิ์ของแอปพลิเคชันกับผู้ดูแลระบบ ใช้วิธีการยืนยันตัวตนที่ได้รับอนุญาต
400	unsupported_grant_type The authorization grant type is not supported by the authorization server.	ไม่รองรับประเภทการอนุญาตที่ร้องขอ	ใช้ grant_type ที่รองรับ (authorization_code, refresh_token) ตรวจสอบการสะกดของ grant_type ให้ถูกต้อง
400	invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted.	ขอบเขตการเข้าถึงไม่ถูกต้อง เช่น scope ไม่ถูกต้องหรือไม่รู้จัก รูปแบบการระบุ scope ไม่ถูกต้อง ขอสิทธิ์เกินกว่าที่ได้รับอนุญาต	ตรวจสอบรายการ scope ที่รองรับ ขอเฉพาะ scope ที่จำเป็น ใช้รูปแบบการระบุ scope ที่ถูกต้อง
401	invalid_token The access token is expired, revoked, malformed, or invalid.	Token ไม่ถูกต้อง เช่น Token หมดอายุ Token ถูกเพิกถอน รูปแบบ Token ไม่ถูกต้อง	ใช้ refresh token เพื่อขอ token ใหม่ เริ่มกระบวนการขอ token ใหม่ ตรวจสอบวิธีการส่ง token ให้ถูกต้อง
403	insufficient_scope The request requires higher privileges than provided by the access token.	Token ที่ใช้มีสิทธิ์ไม่เพียงพอสำหรับการเข้าถึงทรัพยากรที่ร้องขอ	ขอ token ใหม่พร้อมระบุ scope ที่ต้องการเพิ่มเติม ตรวจสอบสิทธิ์ที่จำเป็นสำหรับการเข้าถึง
500	server_error The authorization server encountered an unexpected condition.	เกิดข้อผิดพลาดที่เซิร์ฟเวอร์ ไม่สามารถดำเนินการตามคำขอได้	ลองส่งคำขอใหม่อีกครั้ง หากยังเกิดปัญหา ติดต่อผู้ดูแลระบบ เก็บ log เพื่อช่วยในการตรวจสอบ
503	temporarily_unavailable The server is temporarily unable to handle the request.	เซิร์ฟเวอร์ไม่พร้อมให้บริการชั่วคราว เช่น อยู่ระหว่างการบำรุงรักษา มีการใช้งานระบบมากเกินไป	รอสักครู่แล้วลองใหม่อีกครั้ง ใช้กลไก exponential backoff ในการ retry ตรวจสอบสถานะการให้บริการ

Application Modes

แอปพลิเคชันที่ใช้งาน KMUTNB SSO มี 3 โหมดการทำงาน คือ Development Mode, Approved Mode และ Official Mode ซึ่งมีข้อจำกัดและการใช้งานที่แตกต่างกัน ดังนี้

โหมด	คำอธิบาย	ข้อกำหนด
Development Mode	โหมดสำหรับการพัฒนาและทดสอบระบบ	สามารถทดสอบได้เฉพาะ Username ที่ระบุไว้ มีข้อจำกัดในการเข้าถึงบางฟีเจอร์
Approved Mode	โหมดที่ได้รับการอนุมัติจากสำนักคอมพิวเตอร์ฯ	สามารถใช้งานได้กับผู้ใช้งานทั้งหมดตาม Allowed Account Types เข้าถึงฟีเจอร์ได้ตาม Scope ที่กำหนด ผ่านการตรวจสอบความปลอดภัยจากสำนักคอมพิวเตอร์ฯ
Official Mode	โหมดสำหรับแอปพลิเคชันทางการของมหาวิทยาลัย	ต้องเป็นแอปพลิเคชันที่พัฒนาหรือมีการกำกับดูแลโดยหน่วยงานภายในมหาวิทยาลัย ผ่านการรับรองจากผู้บริหารมหาวิทยาลัย มีแผนการดูแลและบำรุงรักษาระยะยาว มีมาตรฐานความปลอดภัยระดับสูง รองรับการใช้งานพร้อมกันจำนวนมาก มีระบบสำรองข้อมูลและแผนรับมือเหตุฉุกเฉิน

หลักเกณฑ์การอนุมัติ

การพิจารณาเปลี่ยนสถานะแอปพลิเคชันจาก Development Mode เป็น Approved Mode จะต้องผ่านการตรวจสอบและประเมินจากสำนักคอมพิวเตอร์ฯ ตามหลักเกณฑ์ดังต่อไปนี้

หัวข้อการพิจารณา	รายละเอียด
1. ความปลอดภัยของระบบ	ใช้ HTTPS ในการสื่อสารทุกครั้ง มีการจัดการ Token อย่างปลอดภัย ไม่มีการเปิดเผย client_secret ในซอร์สโค้ด มีการป้องกันการโจมตีแบบ CSRF
2. การจัดการ Scope	ขอเฉพาะ scope ที่จำเป็นต่อการทำงานจริง มีการอธิบายเหตุผลการขอ scope แต่ละรายการ ใช้ข้อมูลตาม scope ที่ได้รับอย่างเหมาะสม
3. ข้อมูลแอปพลิเคชัน	มีการระบุชื่อและคำอธิบายแอปพลิเคชันที่ชัดเจน มีการระบุหน่วยงาน/ผู้รับผิดชอบที่ชัดเจน มี Homepage URL ที่เข้าถึงได้และมีข้อมูลครบถ้วน
4. การทดสอบระบบ	ผ่านการทดสอบการทำงานในโหมด Development ไม่พบข้อผิดพลาดในการเรียกใช้ API มีการจัดการข้อผิดพลาดอย่างเหมาะสม
5. การรักษาความเป็นส่วนตัว	มีนโยบายความเป็นส่วนตัวที่ชัดเจน แจ้งวัตถุประสงค์การใช้ข้อมูลให้ผู้ใช้ทราบ ไม่มีการเก็บข้อมูลเกินความจำเป็น
6. การสนับสนุนผู้ใช้	มีช่องทางติดต่อผู้ดูแลระบบ มีเอกสารหรือคู่มือการใช้งาน มีกระบวนการรับแจ้งและแก้ไขปัญหา

หมายเหตุ:

การพิจารณาอาจใช้เวลา 3-5 วันทำการ
หากไม่ผ่านเกณฑ์ จะได้รับแจ้งสิ่งที่ต้องปรับปรุงเพื่อยื่นขอพิจารณาใหม่
เมื่อได้รับการอนุมัติแล้ว จะสามารถใช้งานกับผู้ใช้ทั่วไปได้ทันที

Code Examples

PHP

PHP Example

ตัวอย่างการใช้งาน SSO Client Library สำหรับ PHP แบบพื้นฐาน เหมาะสำหรับผู้เริ่มต้นหรือต้องการศึกษาการทำงานของระบบ

Size: 7KB Version: 1.0.0 PHP 5.6+

Download PHP Example

Yii2 Example

ตัวอย่างการใช้งาน SSO Client Library บน Yii2 Framework พร้อมตัวอย่างการทำ Component และ Authentication

Size: 0KB Version: 0.0.0 Yii2 2.0.45+

Download Yii2 Example

Python

JavaScript

หมายเหตุ: โค้ดตัวอย่างอยู่ภายใต้ MIT License สามารถนำไปใช้หรือดัดแปลงได้อย่างอิสระ

Branding Guidelines

แนวทางการใช้แบรนด์และองค์ประกอบต่างๆ ของ KMUTNB SSO เพื่อให้การแสดงผลเป็นไปในทิศทางเดียวกัน

1. การใช้โลโก้และชื่อ

หัวข้อ	ข้อกำหนด
ชื่อที่ถูกต้อง	KMUTNB SSO KMUTNB Single Sign-On
ขนาดโลโก้ขั้นต่ำ	ความสูงไม่ต่ำกว่า 32px เพื่อความชัดเจน
พื้นที่ว่าง	เว้นพื้นที่ว่างรอบโลโก้อย่างน้อย 8px

2. ปุ่มเข้าสู่ระบบ

รูปแบบที่แนะนำ

4. ข้อความแสดงผล

สถานการณ์	ข้อความที่แนะนำ
หน้า Login	"เข้าสู่ระบบด้วยบัญชี KMUTNB SSO" หรือ "Sign in with KMUTNB SSO"
กำลังดำเนินการ	"กำลังเข้าสู่ระบบ..." หรือ "Signing in..."
เข้าสู่ระบบสำเร็จ	"เข้าสู่ระบบสำเร็จ กำลังนำท่านไปยังระบบ..." หรือ "Successfully signed in. Redirecting..."

Assets และทรัพยากร:

สามารถดาวน์โหลดไฟล์ต่างๆ ได้จาก:

โลโก้และอื่นๆ: /assets/sso-resources.zip
CSS Components: /assets/sso-components.css
ตัวอย่างโค้ด: /examples/branding/

Contact

หากมีข้อสงสัยหรือต้องการความช่วยเหลือเกี่ยวกับการใช้งาน KMUTNB SSO สามารถติดต่อได้ที่

สำนักคอมพิวเตอร์และเทคโนโลยีสารสนเทศ

มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ

ที่อยู่

ชั้น 5 อาคารอเนกประสงค์
1518 ถนนประชาราษฎร์ 1
แขวงวงศ์สว่าง เขตบางซื่อ
กรุงเทพฯ 10800

ช่องทางติดต่อ

+66 2 555-2000 ต่อ 2229
siwakorn.l@icit.kmutnb.ac.th

ติดตามข่าวสารและติดต่อสอบถาม

เว็บไซต์ Facebook Line: @icitkmutnb

เวลาทำการ

วันจันทร์ - วันศุกร์ เวลา 08:30 - 16:00 น.
ปิดทำการวันเสาร์ - อาทิตย์ และวันหยุดนักขัตฤกษ์
สามารถติดต่อผ่านช่องทางออนไลน์ได้ตลอด 24 ชั่วโมง

หมายเหตุ:

กรุณาแจ้งปัญหาหรือข้อสงสัยพร้อมแนบ Screenshot หรือรายละเอียดที่เกี่ยวข้อง
ระบุ Client ID หรือชื่อแอปพลิเคชันทุกครั้งที่ติดต่อเกี่ยวกับ SSO
การตอบกลับผ่านอีเมลจะใช้เวลาประมาณ 1-2 วันทำการ

KMUTNB SSO API Documentation

เนื้อหา

Overview

1. Single Sign-On (SSO)

2. ความสำคัญของ KMUTNB Single Sign-On (KMUTNB SSO)

3. การใช้ Multi-Factor Authentication (MFA)

4. ความสำคัญของ KMUTNB SSO ต่อผู้ใช้

5. การพัฒนาและการดูแลรักษา

6. นโยบายเกี่ยวกับข้อมูลส่วนบุคคล

การขอสิทธิ์ใช้งาน API

การใช้งาน KMUTNB SSO API

1. การเตรียมความพร้อม

2. การลงทะเบียนแอปพลิเคชัน

3. การทดสอบระบบ (Development Mode)

4. การขออนุมัติใช้งานจริง (Approved Mode)

ข้อควรทราบ:

ภาพรวมการทำงาน

ข้อควรระวัง

การลงทะเบียนแอปพลิเคชัน

Scopes

Authentication

1. Authorization Request

2. Token Request

3. Refresh Token

4. Revoke Token

Revoke the access token (ยังไม่เปิดใช้งาน)

Revoke the refresh token (ยังไม่เปิดใช้งาน)

5. Token Introspection

6. User Information

Error Responses

Application Modes

หลักเกณฑ์การอนุมัติ

Code Examples

PHP

PHP Example

Yii2 Example

Python

JavaScript

Branding Guidelines

1. การใช้โลโก้และชื่อ

2. ปุ่มเข้าสู่ระบบ

รูปแบบที่แนะนำ

4. ข้อความแสดงผล

Assets และทรัพยากร:

Contact

สำนักคอมพิวเตอร์และเทคโนโลยีสารสนเทศ

ที่อยู่

ช่องทางติดต่อ

ติดตามข่าวสารและติดต่อสอบถาม

เวลาทำการ

หมายเหตุ: