Trình Gỡ Lỗi OAuth

Proof Key for Code Exchange (PKCE, RFC 7636) ban đầu được thiết kế cho các ứng dụng di động và ứng dụng gốc không thể lưu trữ client secret một cách an toàn. Nó hoạt động bằng cách để client tạo một code_verifier ngẫu nhiên, suy ra một code_challenge từ đó (SHA-256 + base64url), và gửi challenge cùng với yêu cầu ủy quyền. Khi đổi mã ủy quyền lấy token, client gửi code_verifier gốc. Máy chủ ủy quyền xác minh nó khớp với challenge trước đó — chứng minh yêu cầu token đến từ cùng một client đã bắt đầu luồng.

Ngay cả với các client bảo mật (ứng dụng phía máy chủ có client secret), PKCE hiện được OAuth 2.1 khuyến nghị như một biện pháp phòng thủ chống lại tấn công đánh chặn mã ủy quyền.

Luồng implicit (response_type=token) được thiết kế như một cách rút gọn cho các ứng dụng single-page, trả về access token trực tiếp trong đoạn URL. Điều này tạo ra các vấn đề nghiêm trọng: token trong URL xuất hiện trong lịch sử trình duyệt, log máy chủ, và header referrer, và luồng này dễ bị tấn công token injection. OAuth 2.0 Security Best Current Practice (RFC 9700) và OAuth 2.1 loại bỏ hoàn toàn luồng implicit để ưu tiên Authorization Code + PKCE, mà các SPA có thể sử dụng an toàn mà không cần client secret.

• Bắt buộc PKCE cho tất cả các luồng Authorization Code, bao gồm cả client bảo mật.
• Loại bỏ luồng Implicit — dùng Authorization Code + PKCE thay thế.
• Loại bỏ Resource Owner Password Credentials (ROPC) — grant type password không còn được khuyến nghị.
• Bắt buộc xoay vòng refresh token cho client công khai — một refresh token mới phải được cấp mỗi lần sử dụng.
• Bắt buộc khớp chính xác Redirect URI — không dùng khớp mẫu hay ký tự đại diện.

1. Tạo cặp PKCE: Tạo một code_verifier ngẫu nhiên và tính code_challenge = BASE64URL(SHA256(code_verifier)).
2. Chuyển hướng đến endpoint ủy quyền: Bao gồm response_type=code, client_id, redirect_uri, scope, state, code_challenge, và code_challenge_method=S256.
3. Người dùng xác thực tại máy chủ ủy quyền và cấp sự đồng ý.
4. Nhận mã ủy quyền tại redirect_uri của bạn cùng với state được phản hồi lại — xác minh state khớp với những gì bạn đã gửi.
5. Đổi mã lấy token: POST đến endpoint token với grant_type=authorization_code, code, redirect_uri, client_id, và code_verifier.
6. Nhận access token (và tùy chọn id_token và refresh_token) và sử dụng chúng để gọi API.