Bước này có vẻ hoàn toàn ổn. Hiện có hướng dẫn về những điều cần lưu ý trong quá trình đăng ký người dùng, nhưng vì đó không phải là trọng tâm của câu hỏi nên hãy cứ coi như bạn đang làm tốt Show
Bước 2. ) Đăng nhậpBạn nói rằng bạn sử dụng hàm PHP
Bước 3. ) Tạo mã thông báoBạn tạo mã thông báo bằng RS256, đây là thuật toán bất đối xứng. Về cơ bản, khóa riêng RSA được sử dụng để ký tải trọng JWT và chữ ký sau đó được xác thực bằng khóa chung Ưu điểm ở đây là nhà cung cấp JWT không nhất thiết phải là cùng một thực thể với trình xác thực JWT. Nếu điều này có ý nghĩa trong kiến trúc của bạn, thì nên sử dụng thuật toán bất đối xứng Một giải pháp thay thế là HS256, đây là một thuật toán đối xứng. Chìa khóa để tạo JWT hợp lệ và để xác minh xem JWT có hợp lệ hay không là giống hệt nhau. Nếu nhà cung cấp JWT cũng là trình xác thực JWT, thì bạn có thể yên tâm sử dụng HS256 Liên quan đến các lỗ hổng, có một lỗ hổng trong một số thư viện với RS256, trong đó mã thông báo có thể được ký dưới dạng HS256 bằng khóa chung cho RS256. Thư viện sẽ cố gắng sử dụng khóa công khai RSA làm khóa bí mật HMAC và chữ ký sẽ hợp lệ. Không phải là một vấn đề lớn những ngày này, nhưng một cái gì đó để ghi nhớ Hơn nữa, hiệu lực của 2 phút là cực kỳ ngắn. Hãy nhớ rằng kể từ thời điểm người dùng đăng nhập, họ có tổng cộng 2 phút để sử dụng ứng dụng của bạn trước khi bị đuổi. Như một sự so sánh. Hầu hết các trang web ngân hàng sử dụng thời gian chờ là 15 phút. Vì vậy, trừ khi bạn có lý do thực sự chính đáng để chỉ cung cấp cho người dùng 2 phút trên ứng dụng của mình trước khi họ cần xác thực lại, bạn nên cho họ thêm thời gian Bước 4. ) Gửi JWT đến FrontendMiễn là điều này được thực hiện thông qua TLS thì sẽ ổn thôi Bước 5. ) Lưu trữ mã thông báoMã thông báo JWT không nên được lưu trữ dưới dạng biến JS, cũng như trong bộ lưu trữ cục bộ hoặc trong bộ lưu trữ phiên. Lý do cho điều này là những nơi này rất dễ tiếp cận đối với những kẻ tấn công, những kẻ có thể tận dụng các cuộc tấn công XSS Một nơi tốt hơn sẽ là cookie có cờ HTTPOnly được đặt. Điều này không cho phép JavaScript (độc hại) truy cập vào mã thông báo, nhưng bạn vẫn có thể sử dụng mã thông báo cho các yêu cầu XHR. Vì vậy logic hợp pháp của bạn không nên bị ảnh hưởng bởi nó Bước 6. ) Xác minh và tái tạo mã thông báoCó một số vấn đề với logic của bạn ở đây. Trước hết, mã thông báo không được giải mã vì chúng chưa bao giờ được mã hóa ngay từ đầu. Mã thông báo được xác thực. Điều này nghe có vẻ rườm rà, nhưng khi nói đến bảo mật, thuật ngữ chính xác rất quan trọng Việc kiểm tra thời gian hết hạn là hoàn toàn hợp lý và chuyển hướng sau để xác thực lại cũng vậy Vấn đề là với tái tạo mã thông báo. đây là một ý tưởng tồi. Một ý tưởng rất tồi. Trong thực tế, nó có vẻ đủ hợp lý. Sử dụng thời gian hết hạn nhanh và tạo lại khi cần, sau đó mã thông báo sẽ trở nên không hợp lệ ngay sau khi người dùng sử dụng xong ứng dụng, phải không? Vấn đề phát sinh từ khi kẻ tấn công đánh cắp mã thông báo. Sau khi bị đánh cắp, kẻ tấn công về cơ bản có thể giữ mã thông báo vô thời hạn, hay nói đúng hơn là đổi vô thời hạn một mã thông báo hợp lệ này lấy một mã thông báo khác. Ngay cả việc vô hiệu hóa một mã thông báo cũng sẽ có tác dụng rất ít, bởi vì mã thông báo cũng có thể được đổi lấy nhiều mã thông báo khác Trên thực tế, nếu mã thông báo được tạo lại mỗi khi bạn thực hiện thao tác nào đó trong ứng dụng, thì bạn có thể sử dụng một mã thông báo để tạo vô số mã thông báo mới, sau đó sử dụng các mã thông báo đó để tạo nhiều mã hơn nữa. Một kẻ tấn công đã giành được quyền truy cập vào một mã thông báo, chúng không bao giờ có thể bị dừng lại Đây rõ ràng là một điều xấu, và có thể ngăn chặn dễ dàng. Cung cấp cho người dùng của bạn hai mã thông báo. Mã thông báo làm mới và mã thông báo truy cập. Mã thông báo truy cập phải có thời hạn hết hạn nhỏ nhưng vẫn có thể sử dụng được (từ 15 đến 120 phút). Mã thông báo làm mới phải có hiệu lực lâu hơn. Nếu bạn muốn người dùng vẫn được xác thực, như thường lệ với hầu hết các ứng dụng web (Stack Exchange, Twitter, v.v. ), thì mã thông báo làm mới có thể tồn tại vài tháng đến một năm Về cơ bản, người dùng sẽ cố gắng truy cập tài nguyên bằng mã thông báo truy cập (nếu nó vẫn còn hiệu lực). Nếu mã thông báo truy cập đã hết hạn, thì mã thông báo làm mới tồn tại lâu dài có thể được sử dụng để nhận mã thông báo truy cập tồn tại trong thời gian ngắn mới Tại sao điều này lại thuận lợi? . Thứ hai, mã thông báo truy cập bị đánh cắp không thể được sử dụng để duy trì quyền truy cập. Cuối cùng, mã thông báo làm mới bị đánh cắp có thể bị vô hiệu hóa bởi người dùng, do đó hạn chế thiệt hại mà kẻ tấn công có thể gây ra. Đây là một bài viết hay về danh sách đen JWT Làm cách nào để đặt thời gian hết hạn mã thông báo JWT trong PHP?Điều bạn có thể làm là đặt thời gian hết hạn trong config/jwt. tệp php trong 7 ngày vì vậy nếu người dùng xác thực thì mã thông báo sẽ hết hạn sau 7 ngày. 'ttl' => env('JWT_TTL', 60*24*7), Giá trị tính bằng phút.
Chúng tôi có thể thay đổi thời gian hết hạn mã thông báo JWT không?Thời gian hết hạn có thể được thiết lập tối đa là 24 giờ kể từ thời điểm phát hành . Ghi chú. Đây là thời gian hết hạn cho mã thông báo JWT chứ không phải mã thông báo truy cập. Hết hạn mã thông báo truy cập được đặt thành 24 giờ theo mặc định.
Làm cách nào tôi có thể gia hạn thời hạn sử dụng mã thông báo JWT của mình?Để làm mới mã thông báo, API của bạn cần một điểm cuối mới nhận JWT hợp lệ, chưa hết hạn và trả về cùng một JWT đã ký với trường hết hạn mới. Then the web application will store the token somewhere.
Thời hạn sử dụng của mã thông báo JWT là gì?Mã thông báo truy cập JWT chỉ có hiệu lực trong một khoảng thời gian hữu hạn. Sử dụng JWT đã hết hạn sẽ khiến các thao tác không thành công. Như bạn đã thấy ở trên, chúng tôi được cho biết mã thông báo có hiệu lực trong bao lâu cho đến hết expires_in. Giá trị này thường là 1200 giây hoặc 20 phút . |
