OAuth PKCE Generator

Tính năng nổi bật

• Sinh code_verifier bằng crypto.getRandomValues, độ dài chỉnh được từ 43 đến 128 ký tự
• Chỉ dùng tập ký tự unreserved A-Z a-z 0-9 và bốn ký tự gạch ngang, chấm, gạch dưới, dấu ngã
• Tính code_challenge bằng crypto.subtle với SHA-256 rồi mã hóa base64url không phần đệm
• Chuyển giữa S256 và plain, chọn plain thì hiện ngay cảnh báo về rủi ro tương ứng
• Sinh kèm state và nonce từ cùng nguồn ngẫu nhiên, mỗi chuỗi 32 ký tự
• Dựng URL authorize hoàn chỉnh với response_type, code_challenge, code_challenge_method và state
• Năm nút điền nhanh endpoint mẫu cho Google, GitHub, Microsoft Entra ID, Auth0 và Keycloak
• Đoạn mã fetch đổi authorization code lấy token, điền sẵn theo tham số bạn nhập, có nút chép

Vì sao nên sinh cặp PKCE bằng công cụ thay vì gõ tay

Cặp verifier và challenge trông đơn giản nhưng có bốn chỗ dễ sai mà máy chủ ủy quyền sẽ không nói cho bạn biết là sai ở đâu. Chỗ thứ nhất là tập ký tự: nhiều người lấy tạm một chuỗi UUID hoặc một chuỗi hex, chuỗi đó tuy hợp lệ nhưng entropy thấp hơn nhiều so với độ dài của nó gợi ý, hoặc tệ hơn là lấy chuỗi base64 thường có dấu cộng và gạch chéo, hai ký tự nằm ngoài tập unreserved. Chỗ thứ hai là mã hóa kết quả băm: base64 thường và base64url chỉ khác ba chi tiết nhưng sai một chi tiết là máy chủ trả invalid_grant. Chỗ thứ ba là nguồn ngẫu nhiên, Math.random không phải nguồn dùng cho mục đích bảo mật. Chỗ thứ tư là ánh xạ byte ngẫu nhiên sang tập 66 ký tự, làm ẩu bằng phép chia lấy dư sẽ khiến 58 ký tự đầu bảng xuất hiện nhiều hơn 8 ký tự cuối. Công cụ này xử lý cả bốn chỗ đó, và khối kiểm tra hợp lệ cho bạn thấy tận mắt từng ràng buộc đã đạt hay chưa trước khi đem giá trị đi thử.

Lợi ích khi sử dụng

• •Không phải nhớ chính xác công thức base64url và ràng buộc độ dài của RFC 7636
• •Khối kiểm tra hợp lệ bắt lỗi ngay tại chỗ thay vì để máy chủ trả invalid_grant mơ hồ
• •URL authorize đã mã hóa phần trăm đúng chuẩn, dán vào trình duyệt là chạy được ngay
• •Đoạn mã đổi token điền sẵn theo tham số bạn nhập, tiết kiệm bước sửa tay dễ nhầm
• •Mọi giá trị sinh trong trình duyệt, không gửi đi đâu nên dùng được cả với cấu hình nội bộ
• •Cảnh báo rõ ràng khi chọn plain, tránh việc lỡ để chế độ yếu chạy lên môi trường thật

Cách sinh cặp PKCE và dựng URL authorize

1. 1Kéo thanh trượt để chọn độ dài code_verifier, mặc định 96 ký tự tương đương khoảng 580 bit entropy, cặp giá trị sinh lại ngay khi bạn thả tay.
2. 2Giữ nguyên S256 trừ khi môi trường của bạn thật sự không tính được SHA-256, đọc khối kiểm tra hợp lệ để xác nhận challenge dài đúng 43 ký tự và sạch dấu cộng, gạch chéo, dấu bằng.
3. 3Bấm một trong năm nút điền nhanh để nạp endpoint mẫu của nhà cung cấp, rồi thay client_id và redirect_uri bằng giá trị thật của ứng dụng bạn.
4. 4Chép URL authorize, dán vào trình duyệt hoặc gắn vào nút đăng nhập, đồng thời lưu code_verifier và state vào sessionStorage trước khi chuyển hướng người dùng.
5. 5Sau khi nhà cung cấp trả code về redirect_uri, chép đoạn mã đổi token và ghép vào trang callback, nhớ đối chiếu state nhận về với state đã lưu trước khi gọi token endpoint.

PKCE sinh ra để chặn kiểu tấn công nào

Trước khi có PKCE, ứng dụng di động và ứng dụng một trang chạy luồng Authorization Code theo cách sau: mở trình duyệt tới trang đăng nhập, người dùng đồng ý, nhà cung cấp chuyển hướng về redirect_uri kèm tham số code, ứng dụng lấy code đó đổi lấy token. Điểm yếu nằm ở bước chuyển hướng. Trên di động, redirect_uri thường là một custom URL scheme dạng myapp://callback, mà hệ điều hành không có cơ chế nào bảo đảm chỉ một ứng dụng được đăng ký scheme đó. Một ứng dụng độc hại cài sau có thể đăng ký trùng và nhận được authorization code thay vì ứng dụng thật. Trên ứng dụng một trang, code nằm ngay trong thanh địa chỉ nên lọt vào lịch sử duyệt web, log của proxy, hoặc header Referer gửi sang bên thứ ba. Ứng dụng loại này là client công khai, nghĩa là nó không giữ được client_secret: mã nguồn tải về máy người dùng, gỡ ra là đọc được, nên secret nhúng vào đó coi như công khai. Kẻ tấn công có code mà không cần secret là đổi được token. PKCE lấp đúng lỗ hổng này bằng sáu bước: client sinh code_verifier ngẫu nhiên, băm nó thành code_challenge, gửi challenge kèm request authorize, nhà cung cấp lưu challenge cùng với code vừa cấp, client gửi code kèm verifier gốc tới token endpoint, nhà cung cấp băm lại verifier và so với challenge đã lưu. Kẻ chặn được code không có verifier nên không đổi được gì.

S256 và plain: cách tính chính xác và những lỗi hay gặp

Với S256, code_challenge bằng BASE64URL-ENCODE(SHA256(ASCII(code_verifier))). Đọc từ trong ra ngoài: lấy chuỗi verifier, chuyển sang chuỗi byte theo bảng mã ASCII, băm chuỗi byte đó bằng SHA-256 ra đúng 32 byte, rồi mã hóa 32 byte đó bằng base64url. Base64url khác base64 thường ở ba chi tiết: ký tự thứ 62 là gạch ngang chứ không phải dấu cộng, ký tự thứ 63 là gạch dưới chứ không phải gạch chéo, và toàn bộ dấu bằng dùng để đệm bị bỏ đi. Lý do bỏ phần đệm là challenge được nhét vào query string của URL, mà dấu bằng ở đó mang nghĩa ngăn cách tên với giá trị nên phải mã hóa thêm một lớp, rườm rà và dễ sai. Kết quả cuối cùng luôn dài 43 ký tự vì 32 byte chia thành các nhóm 3 byte cho ra 44 ký tự base64 trong đó ký tự cuối là đệm. Hai lỗi phổ biến nhất: một là dùng hàm base64 có sẵn của ngôn ngữ rồi quên thay ký tự và bỏ đệm, hai là băm chuỗi ở dạng UTF-16 thay vì chuỗi byte ASCII, lỗi này hay gặp ở môi trường mà chuỗi mặc định là UTF-16 và hàm băm nhận thẳng chuỗi. Về entropy, khuyến nghị là verifier phải sinh từ ít nhất 256 bit ngẫu nhiên; với tập 66 ký tự, mỗi ký tự mang khoảng 6,04 bit nên 43 ký tự đã vượt 256 bit, còn 96 ký tự cho khoảng 580 bit. Với plain thì challenge bằng đúng verifier, không có phép băm nào, và ai đọc được request authorize là có luôn verifier.

PKCE khác JWT thế nào và khi nào dùng công cụ nào

Hai khái niệm này hay bị đặt cạnh nhau nhưng nằm ở hai tầng hoàn toàn khác. JWT là một định dạng token, tức là quy ước về cách đóng gói dữ liệu: ba phần header, payload và signature nối bằng dấu chấm, mỗi phần mã hóa base64url, phần chữ ký dùng để bên nhận xác minh token chưa bị sửa và đúng do bên phát hành ký. JWT trả lời câu hỏi token trông như thế nào và làm sao tin được nó. PKCE thì không phải định dạng gì cả, nó là một cơ chế bảo vệ đúng một bước trong luồng OAuth: bước đổi authorization code lấy token. PKCE trả lời câu hỏi làm sao bảo đảm người đem code đi đổi chính là người đã khởi tạo phiên đăng nhập. Trong một luồng OpenID Connect thực tế, hai thứ này chạy nối tiếp nhau: PKCE bảo vệ chặng lấy token, và token nhận về ở cuối chặng đó thường chính là JWT. Vì vậy sinh cặp PKCE sai thì bạn không bao giờ tới được bước có token để mà mở ra xem. Trang này lo chặng trước. Khi đã cầm token trong tay, site có ba công cụ cho chặng sau: /vi/tools/jwt-decoder để mở header và payload xem claim bên trong, /vi/tools/jwt-generator để tự dựng token mẫu thử phía nhận khi chưa đấu nối được với nhà cung cấp thật, và /vi/tools/jwt-expiration-checker để đọc trường exp và iat khi cần gỡ lỗi vòng làm mới token.

state, nonce và code_verifier: ba thứ khác nhau, thiếu cái nào hở cái đó

Ba tham số này cùng là chuỗi ngẫu nhiên sinh ở phía client nên rất dễ bị gộp làm một, nhưng mỗi thứ chặn một kiểu tấn công riêng và không thay thế được cho nhau. Tham số state chống giả mạo yêu cầu chéo trang ở bước callback. Bạn sinh state trước khi chuyển hướng, lưu nó lại, và khi nhà cung cấp gọi về redirect_uri thì đối chiếu state nhận được với state đã lưu; không khớp thì hủy phiên. Không có bước này, kẻ tấn công có thể dụ trình duyệt của nạn nhân gọi vào redirect_uri với một authorization code của tài khoản kẻ tấn công, khiến nạn nhân vô tình đăng nhập vào tài khoản đó rồi lưu dữ liệu riêng tư vào đấy. Tham số nonce thuộc về OpenID Connect, nó được nhà cung cấp nhúng thẳng vào id_token dưới dạng một claim; khi nhận token, bạn kiểm tra claim nonce có bằng chuỗi mình đã gửi không, nhờ đó một id_token cũ bị phát lại sẽ không qua được vòng kiểm tra. Còn code_verifier chống việc authorization code bị đánh cắp giữa đường như đã nói ở trên. Ba lớp này độc lập: có PKCE mà bỏ state thì vẫn dính tấn công đăng nhập ép buộc, có state mà bỏ nonce thì id_token vẫn có thể bị phát lại, có cả state lẫn nonce mà bỏ PKCE thì code vẫn bị đánh cắp. Công cụ sinh cả ba cùng lúc từ một nguồn ngẫu nhiên để bạn không quên cái nào.

Triển khai thực tế: lưu verifier ở đâu và vì sao hay dính invalid_grant

Câu hỏi đầu tiên khi đưa PKCE vào sản phẩm là cất code_verifier ở đâu trong lúc chờ người dùng đăng nhập xong. Với ứng dụng một trang, sessionStorage là lựa chọn hợp lý: nó chỉ sống trong một tab, tự xóa khi đóng tab, và không bị gửi kèm request như cookie. Đừng đặt vào cookie thiếu cờ HttpOnly, vì cookie loại đó vừa đọc được bằng JavaScript vừa bị gửi kèm mọi request tới miền của bạn, tức là vừa lộ vừa dư thừa. Với ứng dụng di động, chỗ đúng là Keychain trên iOS và Keystore trên Android, không phải file cấu hình hay thư viện lưu tùy chọn thường. Nhớ xóa verifier ngay sau khi đổi token xong. Câu hỏi thứ hai là thời gian: authorization code có tuổi thọ rất ngắn, phần lớn nhà cung cấp đặt trong khoảng 30 đến 60 giây và chỉ dùng được một lần, dùng lần thứ hai thì nhiều nhà cung cấp còn thu hồi luôn token đã cấp từ code đó. Lỗi bạn sẽ gặp nhiều nhất là invalid_grant, và nó gộp chung nhiều nguyên nhân nên rất khó đoán: verifier gửi lên không khớp challenge đã gửi ở bước authorize, code đã hết hạn hoặc đã dùng rồi, hoặc redirect_uri ở request đổi token không khớp tuyệt đối từng ký tự với redirect_uri ở request authorize, kể cả khác nhau đúng một dấu gạch chéo cuối. Cuối cùng, đừng nghĩ PKCE chỉ dành cho client công khai: OAuth 2.1 khuyến nghị bật PKCE cho mọi client dùng luồng authorization code, kể cả client bí mật chạy ở máy chủ, vì nó là một lớp phòng thủ rẻ và không xung đột với client_secret.

Câu hỏi thường gặp (FAQ)

Từ khóa liên quan

• oauth pkce generator
• code verifier code challenge
• pkce là gì
• rfc 7636
• code_challenge_method s256
• sinh code verifier online
• base64url encode sha256
• authorization code flow with pkce
• oauth 2.0 cho spa
• pkce cho ứng dụng di động
• state và nonce trong oauth
• lỗi invalid_grant oauth
• redirect_uri không khớp
• tạo url authorize oauth
• đổi authorization code lấy token
• pkce khác jwt thế nào
• oauth 2.1 pkce bắt buộc
• lưu code verifier sessionstorage
• web crypto api getrandomvalues
• pkce keycloak auth0 entra id