Spring Security 6 & JWT Authentication · บทเรียน

PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ

เรียนรู้ว่าส่วนขยาย PKCE ปกป้องโฟลว์รหัสการอนุญาต OAuth2 สำหรับแอปมือถือและแอปหน้าเดียวที่ไม่สามารถเก็บความลับของไคลเอ็นต์ได้อย่างไร

บทเรียน 4 จาก 413 ขั้นตอน

PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ เป็นบทเรียน Spring Security 6 & JWT Authentication ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Spring Security 6 & JWT Authentication และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Spring Security 6 & JWT Authentication มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

The Public Client Problem

Mobile apps and SPAs are public clients: their code ships to the user, so they cannot safely store a client secret. Without a secret, the plain Authorization Code flow is vulnerable to interception.

What PKCE Solves

PKCE (Proof Key for Code Exchange, pronounced 'pixy') adds a dynamic secret per authorization request. Even if the authorization code is stolen, it cannot be exchanged without the matching proof.

The Code Verifier

The client generates a random, high-entropy string called the code_verifier and keeps it in memory for this one flow.

const codeVerifier = base64url(randomBytes(32));

The Code Challenge

The client hashes the verifier with SHA-256 to make the code_challenge. The hash is sent to the server, but the original verifier never leaves the device yet.

const codeChallenge = base64url(sha256(codeVerifier));

Starting the Authorization Request

The client sends the challenge and the method (S256) to the authorization endpoint along with the usual parameters.

GET /authorize?response_type=code
  &client_id=app123
  &code_challenge=XYZ...
  &code_challenge_method=S256

Server Stores the Challenge

The authorization server remembers the code_challenge and links it to the authorization code it issues after the user logs in.

Exchanging the Code

When swapping the code for tokens, the client now reveals the original code_verifier.

POST /token
  grant_type=authorization_code
  &code=abc123
  &code_verifier=ORIGINAL_RANDOM

Server Verifies the Proof

The server hashes the received verifier and compares it to the stored challenge. If they match, the requester is the same party that started the flow; otherwise it rejects the exchange.

if (sha256(received_verifier) !== stored_challenge) {
  reject('invalid_grant');
}

Why It Stops Interception

An attacker who steals the authorization code (for example via a malicious app on the device) still cannot use it: they never saw the code_verifier, which existed only inside the legitimate client's memory.

PKCE Is Now Recommended for All

Originally for mobile, PKCE is now recommended for every Authorization Code flow, including confidential web clients. OAuth 2.1 makes it the default.

Library Support

You rarely implement PKCE by hand. Libraries like AppAuth, oidc-client-ts, and Spring Authorization Server handle verifier generation, hashing, and validation for you.

Quick Check

Test your understanding of PKCE.

Recap

You learned how PKCE secures public clients:

  • Public clients cannot keep a secret, so the plain code flow is unsafe
  • The client creates a code_verifier and sends its hash as the code_challenge
  • The verifier is revealed only at token exchange
  • A stolen code is useless without the verifier

PKCE is now the default for all Authorization Code flows.

เริ่มต้นได้ฟรี

เรียนรู้ Java ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
12
บทเรียน
48

คำถามที่พบบ่อย

บทเรียน “PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Spring Security 6 & JWT Authentication ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Spring Security 6 & JWT Authentication มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ”

เรียนรู้ว่าส่วนขยาย PKCE ปกป้องโฟลว์รหัสการอนุญาต OAuth2 สำหรับแอปมือถือและแอปหน้าเดียวที่ไม่สามารถเก็บความลับของไคลเอ็นต์ได้อย่างไร คุณปฏิบัติ Spring Security 6 & JWT Authentication ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Spring Security 6 & JWT Authentication หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Spring Security 6 & JWT Authentication บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Spring Security 6 & JWT Authentication นี้ได้ไหม

ได้ บทเรียน Spring Security 6 & JWT Authentication ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ภาพรวมโพรโทคอล OAuth2
  2. บทนำสู่ OpenID Connect
  3. ประเภทการให้สิทธิ์ OAuth2 ที่พบบ่อย
  4. PKCE และการรักษาความปลอดภัยให้ไคลเอ็นต์สาธารณะ
← กลับไปที่ Spring Security 6 & JWT Authentication