Tôi đang triển khai hệ thống xác thực dựa trên mã thông báo cho API REST bằng cách sử dụng mã thông báo truy cập ngắn hạn và mã thông báo làm mới tồn tại lâu. Đây là tổng quan trừu tượng về các điểm cuối API có liên quan (HTTPS được thi hành cho tất cả các điểm cuối):
Điểm cuối:
POST /register/
POST /login/
POST /logout/
POST /password/change/
Thực hiện:
POST /register/:
- Yêu cầu: Khách hàng gửi tên người dùng, email và mật khẩu trong JSON.
- Hành động của máy chủ:
- Xác thực đầu vào, tạo người dùng trong cơ sở dữ liệu (lưu trữ id người dùng, tên người dùng, email và mật khẩu băm).
- Tạo mã thông báo truy cập ngắn hạn ở định dạng JWT (chứa id người dùng, ngày phát hành và ngày hết hạn).
- Tạo mã thông báo làm mới tồn tại lâu dưới dạng chuỗi UUID và lưu trữ nó trong cơ sở dữ liệu (lưu trữ mã người dùng và mã thông báo làm mới).
- Trả lời: Máy chủ trả về mã thông báo truy cập và làm mới mã thông báo trong JSON.
POST /login/:
- Yêu cầu: Khách hàng gửi tên người dùng và mật khẩu trong JSON.
- Hành động của máy chủ:
- Xác thực đầu vào, kiểm tra nếu thông tin đăng nhập hợp lệ bằng cách kiểm tra cơ sở dữ liệu.
- Nếu thông tin đăng nhập hợp lệ, hãy tạo mã thông báo truy cập ngắn hạn và mã thông báo làm mới tồn tại lâu như đã đề cập trước đó.
- Trả lời: Tương tự như
/register/, trả về mã thông báo truy cập và mã thông báo làm mới trong JSON.
POST /logout/:
- Yêu cầu: Khách hàng gửi mã thông báo làm mới trong
Authorizationtiêu đề dưới dạngBearermã thông báo. - Hành động của máy chủ:
- Xác thực mã thông báo làm mới bằng cách kiểm tra cơ sở dữ liệu mã thông báo làm mới.
- Xóa mã thông báo làm mới khỏi cơ sở dữ liệu.
Lưu ý: Điều này để mã thông báo truy cập hợp lệ, nhưng vì nó sẽ tồn tại trong thời gian ngắn (1 giờ hoặc lâu hơn, tôi nghĩ rằng nó sẽ ổn).
- Trả lời: Trả về việc yêu cầu đăng xuất đã được xử lý thành công trong JSON.
POST /password/change/:
- Yêu cầu: Khách hàng gửi mã thông báo truy cập trong
Authorizationtiêu đề dưới dạngBearermã thông báo và cũng gửi mật khẩu cũ và mật khẩu mới trong JSON thông qua HTTPS. - Hành động của máy chủ:
- Giải mã mã thông báo truy cập để truy xuất người dùng và kiểm tra mật khẩu cũ của người dùng với cơ sở dữ liệu.
- Đặt băm mật khẩu của người dùng trong cơ sở dữ liệu thành băm mật khẩu mới.
- Xóa tất cả các mã thông báo làm mới được liên kết với người dùng trong cơ sở dữ liệu mã thông báo làm mới để cơ bản đăng xuất các phiên hiện có (để lại các mã thông báo truy cập ngắn hạn hợp lệ).
- Trả lời: Trả về việc yêu cầu thay đổi mật khẩu đã được xử lý thành công trong JSON.
Câu hỏi:
- Cách tiếp cận này có an toàn không? Đặc biệt:
- Việc gửi tên người dùng và mật khẩu qua JSON có an toàn không nếu được thực hiện qua HTTPS? Làm cách nào để ngăn chặn các tên miền trái phép thực hiện cuộc gọi đến điểm cuối này? Hơn nữa, làm thế nào tôi có thể ngăn chặn đăng nhập theo chương trình?
- Các mã thông báo làm mới có nên được băm trước khi lưu trữ chúng trong cơ sở dữ liệu hay tôi chỉ bị hoang tưởng?
- Nếu ứng dụng khách là trình duyệt web, làm cách nào tôi có thể lưu trữ mã thông báo làm mới trên máy khách một cách an toàn?
- Một ý tưởng tôi có để lưu trữ mã thông báo làm mới là: khi người dùng đăng nhập, ngoài việc gửi mã thông báo làm mới cho khách hàng, máy chủ lưu trữ mã thông báo trong
HttpOnlycookie cósecurecờ. Việc ủy quyền vẫn sẽ được thực hiện thông quaAuthorizationtiêu đề, nhưng khi máy khách ban đầu tải lên, nó có thể gửiGETyêu cầu đến điểm cuối để kiểm tra xem cookie có chứa mã thông báo làm mới hợp lệ hay không, và nếu vậy, hãy trả lại cho người dùng trong JSON. Nói cách khác, lần duy nhất cookie thực sự sẽ được sử dụng là trả lại mã thông báo làm mới bên trong cookie cho khách hàng. Cách tiếp cận này có an toàn không? Tôi nghĩ rằng nó sẽ ngăn CSRF vì không có tác dụng phụ khi yêu cầu mã thông báo làm mới từ cookie, nhưng có cách nào khác để kẻ tấn công có thể chặn mã thông báo làm mới (giả sử HTTPS) không?
- Một ý tưởng tôi có để lưu trữ mã thông báo làm mới là: khi người dùng đăng nhập, ngoài việc gửi mã thông báo làm mới cho khách hàng, máy chủ lưu trữ mã thông báo trong
2
Tại sao không sử dụng Open ID Connect thay vì cố gắng thực hiện cơ chế bảo mật đăng nhập của riêng bạn?
—
Erik Eidt
Tôi không muốn phải xử lý một máy chủ bổ sung để hoạt động như nhà cung cấp kết nối OpenID. Ngoài ra, tôi muốn có toàn quyền kiểm soát luồng xác thực để tôi có thể dễ dàng xác định các lỗi và lỗ hổng bảo mật.
—
Kootling
Tôi không nghĩ rằng cần một máy chủ bổ sung nếu bạn chỉ sử dụng nó. Ngoài ra, thực hiện việc thực hiện của riêng bạn với giao thức của riêng bạn có những rủi ro bảo mật riêng có thể nhiều hơn so với sử dụng phương pháp tiêu chuẩn mới nổi, nhưng ai biết chắc chắn?
—
Erik Eidt