Chúng ta hãy từ chối ngay từ đầu:
JWT là một cách tiếp cận rất hiện đại, đơn giản và an toàn mở rộng cho Json Web Tokens. Json Web Tokens là một giải pháp không trạng thái để xác thực. Vì vậy, không cần lưu trữ bất kỳ trạng thái phiên nào trên máy chủ, điều này tất nhiên là hoàn hảo cho các API nghỉ ngơi. Các API đầy đủ phải luôn luôn không trạng thái và cách thay thế được sử dụng rộng rãi nhất để xác thực với JWT là chỉ lưu trữ trạng thái đăng nhập của người dùng trên máy chủ bằng các phiên. Nhưng tất nhiên sau đó không tuân theo nguyên tắc nói rằng các API nghỉ ngơi nên không trạng thái và đó là lý do tại sao các giải pháp như JWT trở nên phổ biến và hiệu quả.
Vì vậy, bây giờ hãy biết cách xác thực thực sự hoạt động với Json Web Tokens. Giả sử chúng tôi đã có một người dùng đã đăng ký trong cơ sở dữ liệu của chúng tôi. Vì vậy, ứng dụng khách của người dùng bắt đầu bằng cách tạo một yêu cầu bài đăng với tên người dùng và mật khẩu, sau đó ứng dụng sẽ kiểm tra xem người dùng có tồn tại không và nếu mật khẩu là chính xác, thì ứng dụng sẽ tạo Mã thông báo web Json duy nhất cho người dùng đó.
Mã thông báo được tạo bằng chuỗi bí mật được lưu trữ trên máy chủ . Tiếp theo, máy chủ sau đó gửi JWT đó trở lại máy khách sẽ lưu nó trong cookie hoặc trong bộ nhớ cục bộ.
Giống như thế này, người dùng được xác thực và về cơ bản đăng nhập vào ứng dụng của chúng tôi mà không để lại bất kỳ trạng thái nào trên máy chủ.
Vì vậy, máy chủ thực tế không biết người dùng nào thực sự đăng nhập, nhưng tất nhiên, người dùng biết rằng anh ta đã đăng nhập vì anh ta có Mã thông báo Json Web hợp lệ, giống như hộ chiếu để truy cập các phần được bảo vệ của ứng dụng.
Vì vậy, một lần nữa, chỉ để đảm bảo bạn có ý tưởng. Một người dùng đã đăng nhập ngay khi nhận lại Mã thông báo Json Web hợp lệ duy nhất của mình mà không được lưu ở bất kỳ đâu trên máy chủ. Và do đó, quá trình này là hoàn toàn không quốc tịch.
Sau đó, mỗi lần người dùng muốn truy cập một tuyến được bảo vệ như dữ liệu hồ sơ người dùng của mình. Anh ta gửi Mã thông báo Json Web của mình cùng với một yêu cầu, vì vậy nó giống như hiển thị hộ chiếu của anh ta để có quyền truy cập vào tuyến đường đó.
Khi yêu cầu đến máy chủ, ứng dụng của chúng tôi sẽ xác minh xem Json Web Token có thực sự hợp lệ hay không và nếu người dùng thực sự là người mà anh ta nói, thì dữ liệu được yêu cầu sẽ được gửi đến máy khách và nếu không, thì sẽ là một lỗi cho người dùng biết rằng anh ta không được phép truy cập tài nguyên đó.
Tất cả các giao tiếp này phải diễn ra qua https, Vì vậy, mã hóa http được bảo mật an toàn để ngăn chặn mọi người có thể truy cập vào mật khẩu hoặc Mã thông báo web Json. Chỉ sau đó chúng tôi có một hệ thống thực sự an toàn.
Vì vậy, Mã thông báo web Json trông giống như một phần bên trái của ảnh chụp màn hình này được lấy từ trình gỡ lỗi JWT tại jwt.ioSo, về cơ bản, đó là một chuỗi mã hóa gồm ba phần. Tiêu đề, tải trọng và chữ ký Bây giờ tiêu đề chỉ là một số siêu dữ liệu về chính mã thông báo và tải trọng là dữ liệu mà chúng ta có thể mã hóa vào mã thông báo, bất kỳ dữ liệu nào chúng ta thực sự muốn. Vì vậy, càng nhiều dữ liệu chúng tôi muốn mã hóa ở đây thì JWT càng lớn. Dù sao, hai phần này chỉ là văn bản đơn giản sẽ được mã hóa, nhưng không được mã hóa.
Vì vậy, bất cứ ai cũng sẽ có thể giải mã chúng và đọc chúng , chúng tôi không thể lưu trữ bất kỳ dữ liệu nhạy cảm nào ở đây. Nhưng đó không phải là một vấn đề gì cả vì trong phần thứ ba, vì vậy trong chữ ký, là nơi mọi thứ thực sự trở nên thú vị. Chữ ký được tạo bằng tiêu đề, tải trọng và bí mật được lưu trên máy chủ.
Và toàn bộ quá trình này sau đó được gọi là ký mã thông báo web Json . Thuật toán ký có tiêu đề, tải trọng và bí mật để tạo chữ ký duy nhất. Vì vậy, chỉ có dữ liệu này cộng với bí mật có thể tạo chữ ký này, được chứ? Sau đó, cùng với tiêu đề và tải trọng, các chữ ký này tạo thành JWT, sau đó được gửi đến máy khách.
Khi máy chủ nhận được JWT để cấp quyền truy cập vào tuyến được bảo vệ, nó cần xác minh nó để xác định xem người dùng có thực sự là người mà anh ta tuyên bố là. Nói cách khác, nó sẽ xác minh nếu không ai thay đổi tiêu đề và dữ liệu tải trọng của mã thông báo. Vì vậy, một lần nữa, bước xác minh này sẽ kiểm tra xem không có bên thứ ba nào thực sự thay đổi tiêu đề hoặc tải trọng của Mã thông báo web Json.
Vì vậy, làm thế nào để xác minh này thực sự hoạt động? Vâng, nó thực sự khá đơn giản. Khi JWT được nhận, xác minh sẽ lấy tiêu đề và tải trọng của nó và cùng với bí mật vẫn được lưu trên máy chủ, về cơ bản tạo chữ ký kiểm tra.
Nhưng chữ ký ban đầu được tạo khi JWT lần đầu tiên được tạo vẫn nằm trong mã thông báo, phải không? Và đó là chìa khóa để xác minh này. Bởi vì bây giờ tất cả những gì chúng ta phải làm là so sánh chữ ký kiểm tra với chữ ký gốc. Và nếu chữ ký kiểm tra giống với chữ ký gốc, thì điều đó có nghĩa là tải trọng và tiêu đề chưa được sửa đổi.
Bởi vì nếu chúng đã được sửa đổi, thì chữ ký kiểm tra sẽ phải khác. Do đó, trong trường hợp không có sự thay đổi dữ liệu, chúng tôi có thể xác thực người dùng. Và tất nhiên, nếu hai chữ ký thực sự khác nhau, thì điều đó có nghĩa là ai đó đã can thiệp vào dữ liệu. Thông thường bằng cách cố gắng thay đổi tải trọng. Nhưng bên thứ ba đó thao túng tải trọng tất nhiên không có quyền truy cập vào bí mật, vì vậy họ không thể ký JWT. Vì vậy, chữ ký gốc sẽ không bao giờ tương ứng với dữ liệu bị thao túng. Và do đó, việc xác minh sẽ luôn thất bại trong trường hợp này. Và đó là chìa khóa để làm cho toàn bộ hệ thống này hoạt động. Đó là phép thuật làm cho JWT trở nên đơn giản, nhưng cũng vô cùng mạnh mẽ.
md5('original messaged' + secret) != md5('changed message' + secret)
do đó, nếu ai đó thay đổi tin nhắn, bạn có thể phát hiện ra nó