Một nhà phát triển đã gây ra cuộc tranh luận trong cộng đồng khi đề xuất sử dụng JSON Web Token (JWT) tự ký như một giải pháp thay thế cho các hệ thống quản lý API key truyền thống. Đề xuất này nhằm loại bỏ quy trình thiết lập phức tạp thường bao gồm việc tạo tài khoản, xác minh email, quản lý các key riêng biệt cho client và server, cũng như xử lý cẩn thận các thông tin xác thực bí mật.
Đơn giản hóa xác thực API
Ý tưởng cốt lõi tập trung vào việc các nhà phát triển tự tạo ra cặp khóa mật mã của riêng mình thay vì phụ thuộc vào các nhà cung cấp dịch vụ để cấp API key. Sử dụng các thư viện JavaScript như ' jose ', các nhà phát triển có thể tạo cặp khóa công khai-riêng tư chỉ với vài dòng code. Cách tiếp cận này sẽ cho phép truy cập ngay lập tức vào các API với gói miễn phí mà không cần trải qua quy trình tạo tài khoản rườm rà.
Đề xuất này gợi ý việc lưu trữ private key trên server trong khi đưa public key trực tiếp vào header của JWT. Điều này loại bỏ nhu cầu sử dụng các publishable key và secret key riêng biệt mà nhiều dịch vụ API hiện tại yêu cầu. Thay vào đó, các hành động có đặc quyền sẽ được thể hiện dưới dạng claim trong payload của JWT, với server quyết định những hành động nào được ủy quyền dựa trên logic riêng của nó.
JWT (JSON Web Token): Một cách gọn nhẹ để truyền tải thông tin an toàn giữa các bên dưới dạng đối tượng JSON, được ký số để xác minh tính xác thực.
Ví dụ mã tạo JWT:
import { generateKeyPair, exportJWK } from 'jose'
const keyPair = await generateKeyPair('ES256', {
extractable: true,
})
const publicKeyJWK = await exportJWK(keyPair.publicKey)
const privateKeyJWK = await exportJWK(keyPair.privateKey)
Những lo ngại của cộng đồng về bảo mật
Một số nhà phát triển đã đặt ra những câu hỏi quan trọng về bảo mật đối với đề xuất này. Mối quan tâm chính xoay quanh việc cho phép client tự thiết lập các claim ủy quyền, điều này có thể tạo ra những lỗ hổng bảo mật đáng kể nếu được triển khai không đúng cách.
Tác giả đã làm rõ rằng cơ quan ký JWT vẫn nên kiểm soát những claim nào được bao gồm, gợi ý rằng các server có thể cung cấp token đã được ký trước cho client hoặc sử dụng các phương pháp reverse-proxy để thêm các claim được ủy quyền. Tuy nhiên, một số thành viên cộng đồng vẫn hoài nghi về độ phức tạp mà điều này có thể mang lại.
Nghịch lý với các giải pháp thay thế là nếu bạn đủ thông minh để biết vấn đề nó giải quyết, thì bạn không nên gặp phải vấn đề đó ngay từ đầu.
Claim: Các tuyên bố về một thực thể (thường là người dùng) được bao gồm trong JWT, chẳng hạn như quyền hạn hoặc thuộc tính người dùng.
Thách thức triển khai và các giải pháp thay thế
Những người chỉ trích chỉ ra rằng nhiều bước thiết lập mà đề xuất này nhằm loại bỏ vẫn sẽ cần thiết. Các nhà phát triển vẫn sẽ cần quản lý cặp khóa, lưu trữ chúng một cách an toàn, và tránh commit chúng vào source control. Sự khác biệt chính sẽ là thay thế API key bằng private key trong hầu hết tài liệu.
Một số thành viên cộng đồng đã gợi ý PASETO (Platform-Agnostic Security Token) như một giải pháp thay thế tốt hơn cho tiêu chuẩn JOSE làm nền tảng cho JWT. PASETO được thiết kế để tránh nhiều cạm bẫy bảo mật có thể xảy ra với các triển khai JWT, đặc biệt là xung quanh việc lựa chọn thuật toán và xác thực token.
Cuộc thảo luận cũng đã đề cập đến các tình huống nâng cao hơn, chẳng hạn như các trường hợp sử dụng business-to-business-to-consumer (B2B2C), nơi có thể cần đến hierarchical key derivation để cho phép các nhà phát triển cấp key cho người dùng cuối của riêng họ.
PASETO: Một định dạng token an toàn được thiết kế để đơn giản và an toàn hơn JWT, với ít cơ hội hơn cho các lỗi triển khai.
Quy trình API Key truyền thống so với Self-Signed JWT:
| API Key truyền thống | Self-Signed JWT |
|---|---|
| Truy cập website và tạo tài khoản | Tạo cặp khóa cục bộ |
| Xác minh địa chỉ email | Không cần xác minh email |
| Tạo dự án và thêm thanh toán | Truy cập API trực tiếp với gói miễn phí |
| SDK riêng biệt cho client/server | SDK duy nhất cho mọi môi trường |
| Quản lý khóa công khai và khóa bí mật | Cặp khóa duy nhất với xác thực dựa trên claims |
Kết luận
Mặc dù đề xuất JWT tự ký mang đến một cách tiếp cận thú vị để giảm bớt rào cản onboarding API, phản ứng của cộng đồng làm nổi bật sự phức tạp của các hệ thống xác thực. Cuộc tranh luận phản ánh một căng thẳng rộng lớn hơn trong phát triển phần mềm giữa sự đơn giản và bảo mật, với các nhà phát triển có kinh nghiệm cảnh báo rằng xác thực là một lĩnh vực mà các mẫu thiết lập sẵn tồn tại vì những lý do chính đáng. Đề xuất này có thể tìm thấy ứng dụng trong các trường hợp sử dụng cụ thể, nhưng việc áp dụng rộng rãi có thể sẽ yêu cầu giải quyết các mối quan tâm về bảo mật được cộng đồng đặt ra.
Tham khảo: self-signed JWTs