JWT có thực sự đã chết, hay chúng chỉ bị hiểu lầm? Gần đây, tôi đã thấy một số bài báo gợi ý rằng sự ra đời của Web3 và việc sử dụng ví ngày càng lan rộng sẽ dẫn đến việc người dùng từ bỏ hệ thống tài khoản dựa trên email / mật khẩu truyền thống và thay vào đó, đăng nhập bằng ví của họ. Thành thật mà nói, sau khi sử dụng một vài dApp, quy trình làm việc siêu đơn giản của một hoặc hai lần nhấp vào ví của bạn thực sự là một trải nghiệm tuyệt vời. Nhiều người trong số những bài báo này tiếp tục nói rằng “có lẽ chúng ta không cần JWT nữa!”. Đây là điểm tôi không đồng ý. JWT, mặc dù hơi khó hiểu lúc đầu, nhưng cực kỳ hữu ích cho các kỹ sư phụ trợ, đặc biệt là những người của hệ thống dịch vụ vi mô. , khi xem xét rằng các hệ thống này - một số lượng lớn - đã tồn tại và đã tích hợp với JWT! Ethereum là tuyệt vời và tất cả, nhưng chúng tôi thực sự không cần phải phát minh lại bánh xe. Thật tốt khi có thể tiếp tục sử dụng các công cụ phụ trợ tương tự mà bạn đã quen dùng khi cần. Đặc biệt Đăng nhập bằng MetaMask chứng minh đó là bạn - nhưng làm thế nào để bạn chứng minh với các lệnh gọi API trong tương lai, đó là bạn? Đám đông “vít-JWT” đề xuất sử dụng các ID phiên đơn giản, nhưng đây là một bước lùi so với đầu những năm 2000, hãy nhớ bạn, khi các kiến trúc phân lớp đơn giản là tiêu chuẩn, không có sự phức tạp như các hệ thống phụ trợ ngày nay. Thật không may, ID phiên không thể được xác minh nếu không có một chuyến đi vòng bổ sung vào cơ sở dữ liệu để xác định xem ID phiên được cấp có thuộc về một phiên hợp lệ hay không. Điều này có nghĩa là khi dịch vụ phụ trợ nhận được yêu cầu có chứa ID phiên, sau đó nó sẽ tự đưa ra yêu cầu tới máy chủ xác thực để hỏi “cái này có hoạt động không” - và sau đó mọi dịch vụ khác trong hệ thống Microservice cũng hỏi như vậy. Nếu có một số dịch vụ liên quan, đó có thể là một số chuyến đi khứ hồi bổ sung đến dịch vụ xác thực. Để khắc phục tình trạng này, các chuyên gia mật mã đã suy nghĩ. Những gì họ nghĩ ra là JWT - bây giờ là một phần của tiêu chuẩn OpenID, bạn biết đấy, tiêu chuẩn mà Keycloak, Auth0 và những người khác giúp bạn thực hiện. JWT, các bạn Giải pháp là cấp một bộ mã thông báo - chính xác là Mã thông báo web JSON. Bộ đó bao gồm , và . Các mã thông báo này sau đó đã được “ký” bằng một bí mật - thường được gọi là . Ký, vì vậy chúng ta đang ở trên cùng một trang, là một thuật toán băm mật mã, trong trường hợp của JWT - thường là (mặc định cho Auth0). Trong trường hợp , được sử dụng làm đầu vào và do đó, trở thành khóa cần thiết để giải mã thành công hàm băm đó - hoặc “xác minh” nó. Với và , một cặp khóa công khai / riêng tư được sử dụng, nghĩa là được ký bằng khóa riêng và được xác minh bằng khóa công khai trên máy khách. AccessToken RefreshToken IdToken ClientSecret HS256 HS256 ClientSecret RS256 ES256 Điều này có nghĩa là nếu dịch vụ phụ trợ nhận được một trong những mã thông báo này và nó biết , nó có thể xác minh rằng mã thông báo thực sự được phát hành bởi dịch vụ xác thực đã ký mã thông báo đó. Mã thông báo được sử dụng khi cố gắng truy cập dịch vụ phụ trợ là . Những mã thông báo này đặc biệt chứa thông tin về người dùng cũng như “yêu cầu” của họ, hay nói cách khác, những gì họ được phép làm được định dạng cho hệ thống quan tâm đến nó. ClientSecret AccessToken Đối với các hệ thống microservice, điều này có nghĩa là mỗi dịch vụ quan tâm đến việc xác minh danh tính chỉ cần biết về vì họ có thể xác minh JWT là xác thực bằng cách sử dụng nó, chứ không phải là một vòng đối với cơ sở dữ liệu. Trong một hệ thống có nhiều microservices, điều này có thể làm giảm nhiều chuyến đi vòng bổ sung vào cơ sở dữ liệu, làm cho toàn bộ hệ thống có thể mở rộng hơn. ClientSecret Mã thông báo truy cập, nếu bị đánh cắp, có thể được sử dụng với mục đích xấu và vì lý do đó, điều quan trọng là phải thực hiện các biện pháp phòng ngừa thích hợp khi thiết kế một hệ thống để sử dụng chúng. Tập hợp các biện pháp phòng ngừa , ngoài việc ký và xác minh mã thông báo bao gồm: tối thiểu Đặt ngày hết hạn trên Mã thông báo truy cập JWT là 5-15 phút và đảm bảo rằng mã thông báo không bị hết hạn khi nhận được Không lưu trữ Mã truy cập ngoại trừ trong bộ nhớ Phát hành Mã thông báo làm mới có thể được lưu trữ và gửi đến máy chủ để xác minh và được làm mới cùng với việc sử dụng và đã phát hành nó. ClientSecret ClientId Chỉ sử dụng khi truyền qua kết nối TLS (HTTPS) Sử dụng cookie Chỉ HTTP để không thể sửa đổi chúng ở phía trình duyệt Cài đặt CORS Khóa có cùng kích thước với đầu ra băm (ví dụ: 256 bit cho "HS256") hoặc lớn hơn PHẢI được sử dụng với thuật toán này. - , lưu ý: bit cho HS256. RFC7518 Auth0 sử dụng 512 Một máy khách bí mật cần một máy chủ trung gian, chẳng hạn như Node.js - máy chủ này là một proxy cho dịch vụ xác thực nên máy khách không cần biết về bí mật của máy khách. Ứng dụng khách công khai tiết lộ bí mật của ứng dụng khách và không có máy chủ proxy giữa trình duyệt và dịch vụ xác thực. Điều này có thể được hạn chế hơn nữa với cài đặt CORS vì vậy chỉ cho phép các yêu cầu từ một số miền nhất định. Các biện pháp phòng ngừa bổ sung bao gồm: Sử dụng Mã làm mới xoay vòng - mỗi mã chỉ có thể được sử dụng một lần. Khi được sử dụng, nó được đổi lấy một bộ mã hoàn toàn mới và mã làm mới đã trao đổi sẽ bị thu hồi. Nếu chiến lược này được sử dụng, cần lưu ý rằng người dùng có kết nối internet kém đôi khi không thể nhận được phản hồi cho yêu cầu làm mới và thử lại. Vì lý do này, khoảng thời gian gia hạn ngắn khoảng 30 giây sẽ cho phép họ nhấn làm mới và thử lại. Cho phép người dùng thu hồi tất cả các mã làm mới hiện có của họ bằng cách đăng xuất. Và có thể hơn thế nữa - ví dụ: nếu bạn phát hiện ai đó đang cố gắng sử dụng mã thông báo làm mới đã bị thu hồi, bạn có thể thu hồi tất cả mã thông báo làm mới đang hoạt động của người dùng đó. Tất cả những biện pháp phòng ngừa này, phải thừa nhận rằng, có thể làm cho nó trở nên khó khăn một chút. Có rất nhiều điều để hiểu. Cũng có những lo ngại về khả năng sử dụng. Một người dùng đăng xuất khỏi trang web của bạn cứ sau 5 phút sẽ cảm thấy khá phiền phức đối với họ. Để tránh điều này, một vòng lặp làm mới im lặng phải được triển khai trong ứng dụng tiêu thụ để liên tục làm mới bộ mã thông báo. Điều đó nói rằng, mặt khác của việc làm đúng, là có thể tích hợp an toàn với tất cả các hệ thống phụ trợ của bạn theo cách có thể mở rộng, cũng như nhiều công cụ hiện có - chẳng hạn như , có thể tự động tạo tất cả các API của bạn cho bạn dựa trên một lược đồ DB của Postgres được kết nối. Do đó, có thể tích hợp dễ dàng với công cụ hiện có có thể tiết kiệm rất nhiều thời gian phát triển. Hasura Nếu bạn đã sử dụng OpenId, có thể bạn đã có sẵn những thứ này. Rốt cuộc, nó là một tiêu chuẩn xác thực. Vì vậy, làm thế nào chúng ta có thể giữ sự thuận tiện của việc sử dụng JWT trong Web3 và đăng nhập với thế giới MetaMask? JWT và Web3? Hãy bắt đầu bằng cách tìm hiểu quy trình xác thực OpenId được sử dụng cho SSO. Bạn truy cập một trang web và muốn đăng nhập bằng tài khoản của mình - bạn nhấp vào nút đăng nhập Bạn được chuyển hướng đến trang đăng nhập SSO - bạn đăng nhập bằng email / tên người dùng và mật khẩu Bạn được chuyển hướng trở lại ứng dụng ban đầu với một tập hợp các JWT được lưu trữ thích hợp và được sử dụng trong các luồng nền làm mới im lặng. Trong thế giới web3auth, chúng tôi sẽ thay thế bước hai bằng việc sử dụng cặp khóa riêng tư và khóa công khai trong ví của bạn để ký một thử thách. Chuyển hướng là không cần thiết hoặc không mong muốn. Bạn truy cập một trang web và muốn đăng nhập bằng tài khoản của mình - bạn nhấp vào nút đăng nhập Bạn đang nhận được một thử thách từ máy chủ xác thực, máy chủ này sẽ mở ví của bạn yêu cầu bạn “Đăng nhập” thử thách. Ấn ký. Máy chủ xác thực xác minh chữ ký của bạn và cấp cho bạn một bộ JWT được lưu trữ thích hợp và được sử dụng trong các luồng nền làm mới im lặng. Chúng tôi chỉ đơn giản là thay thế luồng chuyển hướng kiểu SSO bằng một thử thách được ký bởi ví của bạn. Luồng sau khi nhận các mã thông báo vẫn giống như OpenID. Điều đó có nghĩa là bạn có thể ví dụ: chuyển từ sử dụng OpenID sang sử dụng web3auth với máy chủ cấp JWT và không cần thay đổi gì về việc sử dụng các mã thông báo đó sau khi chúng được cấp. Tất cả các tích hợp phụ trợ hiện có của bạn với các công cụ như Hasura vẫn hoàn toàn giống nhau. Đây chính xác là những gì tôi muốn với tư cách là một nhà phát triển Chu kỳ đầy đủ. Tôi không muốn phát minh lại bánh xe. Tôi muốn thay thế OpenID bằng web3auth và vẫn có thể sử dụng tất cả các công cụ mạnh mẽ mà tôi đã quen. Rất tiếc, tôi không thể tìm thấy máy chủ web3auth thực hiện điều này cũng như các biện pháp phòng ngừa bảo mật. Tôi đã tìm thấy một vài dự án trình diễn các kỹ thuật trong quá trình này, nhưng không phải toàn bộ quy trình đều kết thúc. Vì vậy, tôi phải xây dựng… Tôi đã xây dựng máy chủ xác thực này tại đây: https://github.com/CloudNativeEntosystemur/web3auth-service Và đây là tích hợp để đi cùng với nó, thực hiện tất cả mọi thứ - làm mới im lặng, yada yada - tất cả những thứ tôi đã đề cập ở trên: SvelteKit https://github.com/CloudNativeEntosystemur/sveltekit-web3auth Tất nhiên nếu sẽ có một ứng dụng khách GraphQL và ví dụ, thì cũng cần phải có một máy chủ và cơ sở dữ liệu GraphQL, vì vậy tôi cũng cung cấp các ví dụ về điều đó: + https://github.com/CloudNativeEntosystemur/example-hasura https: //github.com/CloudNativeEntooterur/example-readmodel Ví dụ này sử dụng và , vì vậy tất cả những gì bạn cần làm là khai báo các DB và mô tả lược đồ của bạn trong YAML và Hasura sẽ tự động tạo tất cả các API GraphQL mà bạn cần. VÀ, tôi đã nghĩ đến máy chủ xác thực với Hasura, vì vậy nó có các yêu cầu thích hợp để tích hợp với RBAC và các quyền của Hasura, khá mạnh mẽ. toán tử Zalando Postgres SchemaHero Và tất nhiên, bạn cần một nơi để chạy tất cả những thứ đó, và như vậy, một cụm nhà phát triển cục bộ thiết lập tất cả các công cụ như istio, và các toán tử, và SchemaHero cho bạn! https://github.com/CloudNativeEntosystemur/local-dev-cluster Nhưng ai biết cách sử dụng tất cả những thứ đó? Vì vậy, đó là lý do tại sao tôi thực hiện repo này: meta https://github.com/CloudNativeEntosystemur/web3auth-meta Sử dụng meta repo đó sẽ sao chép tất cả các dự án bạn cần vào đúng vị trí và chạy tất cả chúng cùng nhau. Cuối cùng, để chạy tất cả các dự án cùng nhau, bạn cần cài đặt các công cụ và việc cài đặt các công cụ rất khó chịu - vì vậy tôi đã thực hiện repo này ở đây sẽ cài đặt tất cả chúng cho bạn! https://github.com/CloudNativeEntosystemur/onboard Tôi cũng đã xuất bản trên npm và tạo một mẫu từ một dự án SvelteKit sử dụng nó và đã thiết lập GraphQL và tích hợp với xác thực cho một phiên bản Hasura để khi bạn sẵn sàng tạo dự án của riêng mình, bạn có thể sử dụng như một mẫu! sveltekit-web3auth https://github.com/CloudNativeEntosystemur/sveltekit-web3auth-template Nếu bạn chưa sẵn sàng cho thế giới web3 auth, bạn cũng có thể sử dụng , được định cấu hình sẵn để kết nối với cụm nhà phát triển cục bộ của bạn và phiên bản Keycloak được thiết lập bên trong nó. Xem cách cả hai dự án phát hành JWT, mục tiêu là để hệ thống xác thực có thể hoán đổi cho nhau - sử dụng web3auth hoặc OIDC cổ điển - việc sử dụng ngược dòng các mã thông báo là như nhau. https://github.com/CloudNativeEntosystemur/sveltekit-oidc Bây giờ, hãy tạo một số dApp kết hợp với các API GraphQL được tạo tự động và RBAC mạnh mẽ và các quyền cũng như đăng ký và các trang SSR đã xác thực và các vòng lặp làm mới im lặng cũng như xoay vòng các mã thông báo và nội dung làm mới! Sự kết luận Tóm lại, không, JWT và đăng nhập bằng Ethereum / metamask không loại trừ lẫn nhau. Trên thực tế, nếu bạn thích năng suất của nhà phát triển và tích hợp với các công cụ hiện có, tôi nghĩ bạn sẽ làm khá tốt khi sử dụng JWTs VÀ web3auth. Chúc mừng! Tôi sẵn sàng tư vấn! Nếu bạn quan tâm đến sự trợ giúp của tôi về một dự án mà bạn đang thực hiện, hãy gửi cho tôi một tin nhắn trên Twitter!
