อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect
เรียนรู้ว่า SSO, การยืนยันของ SAML, ขั้นตอนการทำงานของ OAuth 2.0 และโทเค็นของ OpenID Connect ช่วยให้ผู้ใช้ยืนยันตัวตนเพียงครั้งเดียวและเข้าใช้หลายแอปพลิเคชันได้อย่างปลอดภัยอย่างไร
อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
ปัญหาของอัตลักษณ์ระหว่างโดเมน
ในองค์กรสมัยใหม่ พนักงานจำเป็นต้องเข้าถึง Application หลายสิบรายการ ทั้งแอปบนคลาวด์ เครื่องมือ SaaS พอร์ทัลของพันธมิตร และระบบภายใน ซึ่งแต่ละรายการอาจได้รับการดูแลโดยองค์กรที่แตกต่างกัน การสร้างและจัดการบัญชีแยกกันสำหรับแต่ละระบบไม่ปลอดภัย (ทำให้มีข้อมูลรับรองจำนวนมาก) และไม่มีประสิทธิภาพ Federated identity แก้ปัญหานี้ด้วยการให้ Identity Provider (IdP) ซึ่งเป็นแหล่งข้อมูลอัตลักษณ์ที่เชื่อถือได้และมีอำนาจหน้าที่ ทำการพิสูจน์ตัวตนผู้ใช้ แล้วแชร์อัตลักษณ์ที่ผ่านการพิสูจน์ตัวตนแล้วกับ Service Providers (SP) ข้ามขอบเขตขององค์กร ผู้ใช้พิสูจน์ตัวตนเพียงครั้งเดียวและเข้าถึงหลายระบบได้โดยไม่ต้องกรอกข้อมูลรับรองอีก
พื้นฐาน Single Sign-On (SSO)
Single Sign-On (SSO) ช่วยให้ผู้ใช้พิสูจน์ตัวตนครั้งเดียวและเข้าถึง Application หลายรายการภายในเซสชันได้โดยไม่ต้องพิสูจน์ตัวตนซ้ำ ผู้ใช้เข้าสู่ระบบ Identity Provider (corporate Active Directory, Okta, Azure AD) ได้รับ session token หรือ assertion แล้วนำ token นี้ไปแสดงต่อ Service Provider แต่ละแห่งที่เข้าใช้งาน SSO ช่วยเพิ่มความปลอดภัยโดยลดจำนวนรหัสผ่านที่ผู้ใช้ต้องจัดการ (ลดการนำรหัสผ่านกลับมาใช้ซ้ำ) ช่วยให้บังคับใช้นโยบายการพิสูจน์ตัวตนแบบรวมศูนย์ และทำให้เพิกถอนการเข้าถึงได้ทันทีในทุก Application ที่ผสานรวมกัน เมื่อบัญชีถูกปิดใช้งานที่ระดับ IdP
SAML 2.0: การทำสหพันธรัฐที่ใช้ XML
SAML (Security Assertion Markup Language) 2.0 เป็นมาตรฐานเปิดที่ใช้ XML สำหรับแลกเปลี่ยนข้อมูลการพิสูจน์ตัวตนและการอนุญาตระหว่าง Identity Provider และ Service Provider ลำดับการทำงานของ SAML คือ (1) ผู้ใช้เข้าใช้งาน Service Provider (เช่น Salesforce) (2) SP เปลี่ยนเส้นทางไปยัง Identity Provider (เช่น Okta) (3) ผู้ใช้พิสูจน์ตัวตนที่ IdP (4) IdP ออก SAML Assertion แบบ XML ที่มีลายเซ็น ซึ่งประกอบด้วยอัตลักษณ์และ Attribute ของผู้ใช้ (5) ส่ง assertion กลับไปยัง SP (6) SP ตรวจสอบลายเซ็นของ assertion โดยใช้กุญแจสาธารณะของ IdP แล้วอนุญาตให้เข้าถึง SAML ถูกใช้อย่างแพร่หลายสำหรับ SSO ระดับองค์กรใน Application บนเว็บ
<!-- Simplified SAML Assertion structure -->
<saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
IssueInstant='2026-06-21T10:00:00Z'
ID='_abc123'>
<saml:Issuer>https://idp.company.com</saml:Issuer>
<saml:Subject>
<saml:NameID>alice@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore='2026-06-21T10:00:00Z'
NotOnOrAfter='2026-06-21T10:05:00Z'/>
<saml:AttributeStatement>
<saml:Attribute Name='groups'>
<saml:AttributeValue>Sales</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<!-- Signature verifies IdP signed this assertion -->
</saml:Assertion>บทบาทของ SAML: IdP, SP และ Principal
มีสามฝ่ายที่เข้าร่วมในสหพันธรัฐ SAML Principal คือผู้ใช้ (หรือระบบ) ที่ต้องการเข้าถึง โดยเป็นผู้เริ่มกระบวนการพิสูจน์ตัวตน Identity Provider (IdP) คือแหล่งข้อมูลอัตลักษณ์ที่มีอำนาจหน้าที่ ทำการพิสูจน์ตัวตน Principal และออก assertion ตัวอย่างได้แก่ Microsoft Azure AD, Okta, Ping Identity และ ADFS Service Provider (SP) รับ assertion ไปใช้และอนุญาตการเข้าถึงตามข้อมูลดังกล่าว ตัวอย่างได้แก่ Salesforce, Google Workspace, AWS และ Application ใด ๆ ที่รองรับ SAML SP และ IdP จะสร้างความไว้วางใจไว้ล่วงหน้าด้วยการแลกเปลี่ยน metadata ซึ่งมี URL ปลายทางและใบรับรองสำหรับลงลายเซ็นของแต่ละฝ่าย
OAuth 2.0: กรอบงาน Authorization
OAuth 2.0 เป็นกรอบงานด้าน Authorization (ไม่ใช่โปรโตคอลการพิสูจน์ตัวตน) ที่ช่วยให้ Application ของบุคคลที่สามเข้าถึงทรัพยากรในนามของผู้ใช้ได้โดยไม่เปิดเผยข้อมูลรับรองของผู้ใช้ กรณีใช้งานทั่วไปคือ “อนุญาตให้แอปแต่งภาพนี้เข้าถึง Google Photos ของคุณ” OAuth 2.0 กำหนดบทบาทไว้สี่บทบาท ได้แก่ Resource Owner (ผู้ใช้) Client (แอปของบุคคลที่สาม) Authorization Server (ออก token) และ Resource Server (โฮสต์ทรัพยากรที่ได้รับการปกป้อง) ผู้ใช้อนุญาตให้ Client ทำงาน จากนั้น Client จะได้รับ access token เพื่อนำไปแสดงต่อ Resource Server โดยไม่จำเป็นต้องใช้รหัสผ่านจริงของผู้ใช้
OAuth 2.0 Authorization Code Flow
Authorization Code Flow เป็น flow ของ OAuth 2.0 ที่ปลอดภัยที่สุดสำหรับ Application บนเว็บ ลำดับการทำงานคือ (1) Client เปลี่ยนเส้นทางผู้ใช้ไปยัง Authorization Server พร้อม scope ที่ร้องขอ (2) ผู้ใช้พิสูจน์ตัวตนและให้ความยินยอมที่ Authorization Server (3) Authorization Server เปลี่ยนเส้นทางกลับมาพร้อม authorization code ที่มีอายุสั้น (4) Client แลกเปลี่ยน code เป็น access token (และอาจได้รับ refresh token) ผ่านการเรียกจาก server ไปยัง server โดยใช้ข้อมูลรับรองของ Client (5) Client ใช้ access token เรียก Resource Server การแลกเปลี่ยน code เกิดขึ้นที่ฝั่ง server จึงป้องกันไม่ให้ access token ปรากฏในประวัติเบราว์เซอร์หรือบันทึกการทำงาน
# OAuth 2.0 Authorization Code Flow (step 3-4)
# Step 3: User is redirected back to client with auth code
# GET https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
# Step 4: Client exchanges code for access token (server-to-server)
curl -X POST https://auth.example.com/oauth2/token \
-d 'grant_type=authorization_code' \
-d 'code=SplxlOBeZQQYbYS6WxSbIA' \
-d 'redirect_uri=https://app.example.com/callback' \
-d 'client_id=client_abc' \
-d 'client_secret=secret_xyz'
# Response: {'access_token': 'MTQ0Nj...', 'token_type': 'Bearer', 'expires_in': 3600}OpenID Connect: เพิ่มการพิสูจน์ตัวตนให้ OAuth
OpenID Connect (OIDC) เป็นชั้นการพิสูจน์ตัวตนที่สร้างอยู่บน OAuth 2.0 OAuth ให้เฉพาะ Authorization (access token ใช้พิสูจน์ว่า Client ทำอะไรได้บ้าง) ส่วน OIDC เพิ่มการพิสูจน์ตัวตน (ด้วย ID token ที่พิสูจน์ว่าผู้ใช้คือใคร) OIDC เพิ่ม scope openid ให้กับ flow ของ OAuth และส่ง JWT (JSON Web Token) ID Token ที่มีลายเซ็นมาพร้อมกับ access token ID token ประกอบด้วย claims (ชื่อ อีเมล และ sub [ตัวระบุ Subject]) ที่ใช้ระบุผู้ใช้ ปัจจุบัน OIDC เป็นโปรโตคอลหลักสำหรับ SSO ที่ให้บริการแก่ผู้ใช้ทั่วไป ปุ่ม “Sign in with Google/Apple/Microsoft” ล้วนใช้ OIDC
# OIDC ID Token is a JWT with three base64url-encoded parts:
# header.payload.signature
# Decoded payload example:
# {
# 'iss': 'https://accounts.google.com',
# 'sub': '110169484474386276334',
# 'aud': 'client_id_abc123',
# 'exp': 1750000000,
# 'iat': 1749996400,
# 'email': 'alice@gmail.com',
# 'name': 'Alice Smith',
# 'email_verified': true
# }
# The signature is verified with the IdP's public key (from JWKS endpoint)JWT: Token ในการพิสูจน์ตัวตนสมัยใหม่
JSON Web Tokens (JWT) เป็นรูปแบบกะทัดรัดที่ปลอดภัยสำหรับ URL ซึ่งใช้แทน claims ระหว่างฝ่ายต่าง ๆ JWT ประกอบด้วยสามส่วนที่เข้ารหัสแบบ base64url และคั่นด้วยจุด ได้แก่ Header (อัลกอริทึมและประเภท token) Payload (claims: iss, sub, aud, exp, iat และ claims แบบกำหนดเอง) และ Signature (ลายเซ็นเชิงการเข้ารหัสที่ใช้ตรวจสอบความสมบูรณ์ของ token) JWT เป็นแบบ self-contained กล่าวคือ Resource Server สามารถตรวจสอบได้โดยไม่ต้องเรียกกลับไปยัง Authorization Server ทำให้ประสิทธิภาพดีขึ้นและรองรับสถาปัตยกรรมแบบไร้สถานะ ข้อกำหนดด้านความปลอดภัยที่สำคัญคือ ต้องตรวจสอบลายเซ็นของ JWT และตรวจสอบ claims exp (วันหมดอายุ) กับ aud (กลุ่มผู้รับ) เสมอ
# Decode a JWT (header and payload are just base64 encoded)
import base64, json
jwt = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNzUwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
parts = jwt.split('.')
print('Header:', json.loads(base64.b64decode(parts[0] + '==')))
print('Payload:', json.loads(base64.b64decode(parts[1] + '==')))
# Signature (parts[2]) must be verified with IdP public key!SAML กับ OAuth กับ OIDC: ควรใช้แบบใดเมื่อใด
การเข้าใจว่าแต่ละมาตรฐานเหมาะกับกรณีใดมีความสำคัญอย่างยิ่งต่อการสอบ Security+ SAML 2.0: SSO ระดับองค์กรสำหรับ Application บนเว็บ flow ที่ทำงานผ่านเบราว์เซอร์ และ assertion แบบ XML เป็นเทคโนโลยีเดิมแต่ยังมีการใช้งานอย่างแพร่หลายในองค์กร OAuth 2.0: Authorization สำหรับ API ใช้เพื่อให้สิทธิ์ Application ของบุคคลที่สามเข้าถึงทรัพยากรอย่างจำกัด และไม่ได้พิสูจน์ตัวตนผู้ใช้โดยตรง OIDC: ใช้สำหรับการพิสูจน์ตัวตนของผู้ใช้ทั่วไปและองค์กรสมัยใหม่ (SSO) โดยสร้างอยู่บน OAuth 2.0 และส่ง JWT ID token ที่ระบุผู้ใช้ ในทางปฏิบัติ สภาพแวดล้อมระดับองค์กรมักใช้ SAML สำหรับ SSO ของ Application และใช้ OIDC สำหรับการพิสูจน์ตัวตนผ่าน API หรืออุปกรณ์เคลื่อนที่ สภาพแวดล้อมสมัยใหม่ที่สร้างบนคลาวด์มักเลือก OIDC แทน SAML เนื่องจากใช้รูปแบบ JSON/JWT และรองรับอุปกรณ์เคลื่อนที่ได้ดีกว่า
ช่องทางการโจมตีสหพันธรัฐ
ระบบ Federated identity มีช่องทางการโจมตีเฉพาะหลายรูปแบบ การโจมตีแบบ replay ของ assertion: ผู้โจมตีดักจับ SAML assertion แล้วนำกลับมาใช้เพื่อเข้าถึงระบบ วิธีลดความเสี่ยงคือกำหนดอายุ assertion ให้สั้นและใช้ ID ของ assertion ได้เพียงครั้งเดียว การห่อหุ้มลายเซ็น XML (XSW): ใน SAML ผู้โจมตีอาจแก้ไข XML ที่มีลายเซ็นเพื่อเปลี่ยน claims ขณะที่ยังคงทำให้ลายเซ็นของเนื้อหาเดิมถูกต้องได้ ความสับสนของอัลกอริทึม JWT: หาก server ยอมรับทั้งอัลกอริทึม RS256 (แบบอสมมาตร) และ HS256 (แบบสมมาตร) ผู้โจมตีสามารถปลอม JWT โดยใช้กุญแจสาธารณะของ server เป็นข้อมูลลับ HMAC สำหรับ HS256 ต้องตรวจสอบเสมอว่าอัลกอริทึมใน Header ตรงกับอัลกอริทึมที่คาดไว้ ตัวเปลี่ยนเส้นทางแบบเปิด: ต้องตรวจสอบ URI เปลี่ยนเส้นทางของ OAuth ให้ตรงกันทุกประการ เพื่อป้องกันการขโมย token ผ่านการเปลี่ยนเส้นทางไปยังเว็บไซต์ที่ผู้โจมตีควบคุม
การทำสหพันธรัฐของไดเรกทอรีและ SCIM
การทำสหพันธรัฐด้านอัตลักษณ์ระดับองค์กรมักต้องซิงโครไนซ์ข้อมูลอัตลักษณ์ของผู้ใช้ระหว่างระบบต่าง ๆ SCIM (System for Cross-domain Identity Management) เป็นมาตรฐาน REST API สำหรับทำให้การจัดสรรและยกเลิกการจัดสรรผู้ใช้ระหว่าง Identity Provider กับ Service Provider ที่เชื่อมต่ออยู่เป็นไปโดยอัตโนมัติ เมื่อเพิ่มพนักงานใหม่ใน Azure AD (IdP) SCIM จะสร้างบัญชีของพนักงานใน Salesforce, Slack, GitHub และ Application อื่น ๆ ที่รองรับ SCIM โดยอัตโนมัติ เมื่อพนักงานพ้นสภาพ SCIM จะปิดใช้งานบัญชีทั้งหมดพร้อมกัน ทำให้ช่วงเวลาที่บัญชีตกค้างอาจถูกโจมตีสั้นลง SCIM ช่วยเสริมโปรโตคอล SSO (SAML/OIDC) ด้วยการจัดการวงจรชีวิตของอัตลักษณ์ ซึ่งเป็นส่วนที่โปรโตคอล SSO ไม่ได้ครอบคลุม
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า SAML 2.0 ใช้ assertion แบบ XML สำหรับ SSO ระดับองค์กรที่ทำงานผ่านเบราว์เซอร์ OAuth 2.0 เป็นกรอบงานด้าน Authorization สำหรับมอบหมายการเข้าถึง API OpenID Connect เพิ่มการพิสูจน์ตัวตน (ด้วย JWT ID token) บน OAuth และ SCIM ทำให้การจัดการวงจรชีวิตของอัตลักษณ์ในระบบสหพันธรัฐเป็นไปโดยอัตโนมัติ บทนี้เป็นบทสุดท้ายของหลักสูตรการพิสูจน์ตัวตนและการอนุญาต บทถัดไปเราจะศึกษา พื้นฐานความปลอดภัยของ Network
คำถามที่พบบ่อย
บทเรียน “อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect”
เรียนรู้ว่า SSO, การยืนยันของ SAML, ขั้นตอนการทำงานของ OAuth 2.0 และโทเค็นของ OpenID Connect ช่วยให้ผู้ใช้ยืนยันตัวตนเพียงครั้งเดียวและเข้าใช้หลายแอปพลิเคชันได้อย่างปลอดภัยอย่างไร คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- นโยบายรหัสผ่านและการยืนยันตัวตนหลายปัจจัย
- ชีวมาตรและการยืนยันตัวตนด้วยโทเค็น
- รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC
- อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect