Bạn đang xem bài viết So Sánh Json Web Token(Jwt) Và Session Cookies Trong Việc Authentication được cập nhật mới nhất tháng 9 năm 2023 trên website Channuoithuy.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.
Chắc các bạn cũng biết rằng HTTP là một chiếc cầu nối giữa client và server (giao thức truyền tải). Và nó là một giao thức stateless (stateless protocol).
Vậy stateless là gì nhể? Giải thích một cách dễ hiểu thì một giao thức stateless là giao thức mà sau khi client gửi dữ liệu lên server, server thực thi xong, trả kết quả lại về cho client thì “quan hệ” giữa client và server bị “cắt đứt”, server không lưu lại bất cứ dữ liệu trạng thái gì của client.
Trong cuộc đời nào được như ý muốnNhiều lúc yêu thương đã không trọn vẹnNên chấp nhận cuộc tình chia hai lốiCòn níu kéo cũng chẳng để làm chi
Để giải thích bằng ví dụ thì điều này có nghĩa là nếu như chúng ta đăng nhập vào tài khoản Facebook. Sau đó chúng ta di chuyển sang trang Settings thì chúng ta sẽ phải đăng nhập lại vì server không giữ trạng thái của chúng ta. Tuy vậy bài toán này đã được giải quyết với session và cookies. Bằng cách lưu giữ thông tin tại 2 phía client và server thông qua session và cookies mà server có thể biết được client này đã đăng nhập được hay chưa.
Ngoài Session và Cookies ra thì vẫn còn 1 vài kỹ thuật nữa được sử để xác thực đăng nhập (authentication). Trong đó có JWT.
JWT là gì?JWT là viết tắt của JSON Web Token – một tiêu chuẩn mở (RFC 7519) cho việc bảo việc trong truyền tải dữ liệu giữa các endpoint.
JSON Web Token bao gồm 3 phần, được ngăn cách nhau bởi dấu chấm (.), đó là:
HeaderGồm 2 phần, đầu tiên là loại token (ở đây là JWT) và phần tiếp theo là loại thuật toán sử dụng để mã hóa ví dụ như HMAC SHA256 hay RSA. Nếu không định nghĩa thì mặc định sẽ sử dụng thuật toán mã hóa HS256.
{ "typ": "JWT", "alg": "HS256" } PayloadPayload sẽ chứa các thông tin cơ bản của user cần xác thực. Ví dụ như: tên, tuổi, permissions,…
Có 2 lưu ý khi định nghĩa payload đó là:
Không cho password, thông tin cần bảo mật vào payload có thể bị decode
Không cho quá nhiều thông tin vào payload vì sẽ tạo ra độ trễ cho server
Ví dụ:
{ "user_name": "vantien", "user_id": "1", "role": "ADMIN", } SignaturePhần cuối cùng là chữ ký, nó được tạo ra bằng cách kết hợp và mã hóa 4 thứ sau:
header
payload
Chuỗi khóa bí mật (secret key)
Thuật toán mã hóa
Ví dụ như sau:
HS256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret_key ) Cuối cùngSau khi kết hợp 3 phần header, payload và signature chúng ta sẽ có một chuỗi JWT hoàn chỉnh.
Cơ chế xác thực đăng nhập bằng Session và Cookies (Session-Based Authentication)Với cơ chế này thì sau khi đăng nhập, server sẽ tạo ra session cho user và lưu vào đâu đó (có thể là file, memory, database,…). Sau đó một session ID sẽ được lưu vào trong cookies của trình duyệt. Trong khi user truy cập vào website thì session ID đó sẽ được trình duyệt lấy ra và gửi kèm theo trong request. Nhờ vậy mà server có thể tham chiếu đến session đã lưu trên server để biết user này đã đăng nhập hay chưa. Sau khi user log-out (đăng xuất) thì session sẽ bị xóa đi.
Cơ chế xác thực đăng nhập bằng Token – (Token-Based Authentication)Khi nhắc đến cơ chế xác thực đăng nhập bằng Token (Token-Based Authentication) thì đa phần người ta thường nhắc đến JWT. Trước đây thì các trang web chỉ sử dụng cơ chế Session và Cookies tuy vậy hiện nay cơ chế sử dụng Token vô cùng phổ biến và dần trở thành một tiêu chuẩn cho việc xác thực đăng nhập.
Cơ chế của JWT là như thế nào? Khi user đăng nhập thì server sẽ tạo ra một đoạn token được mã hóa và gửi lại nó cho client. Khi nhận được token này thì client sẽ lưu trữ vào bộ nhớ (thường sẽ là local storage). Sau đó mỗi khi client request lên server thì sẽ gửi kèm theo token. Từ token này server sẽ biết được user này là ai.
Nên dùng cách nào?Xác thực bằng JWT là phương pháp được mà mình nghĩ sẽ trở thành 1 tiêu chuẩn trong tương lai để dần thay thế cho Session, Cookies khi mà SPA đang trở thành xu thế. Ngoài ra nó có thể scale tốt hơn so với Session Cookies vì token sẽ được lưu trữ ở phía client trong khi Session thì phải lưu ở máy chủ và đây có thể là vấn đề khi một số lượng lớn người dùng sử dụng hệ thống cùng một lúc.
Tuy nhiên, một nhược điểm với JWT là có kích thước lớn hơn nhiều so với session ID vì JWT chứa nhiều thông tin người dùng hơn. Ngoài ra chúng ta cần phải cần thận trong việc cho thông tin người dùng vào JWT vì nó có thể bị decode.
Tìm Hiểu Jwt(Json Web Token) Authentication
Mở đầu.
JWT(JSON Web Token) là công nghệ phổ biến ngày nay, nhưng cũng đồng thời cũng gây tranh cãi rất nhiều.
Có nhiều người nói đừng bao giờ dùng nó, trong khi những người khác lại nói nó thật tuyệt vời. Vậy sự thật là gì? Nên hay không nên dùng? Đó là lý do chúng ta ở đây.
1. Giới thiệu ngắn gọn về JWT.JWT về mặt kỹ thuật là một cơ chế để xác minh chính chủ một số dữ liệu JSON. Nó là một chuỗi biến đổi, có thể chứa một lượng dữ liệu không giới hạn (không giống như một cookie) và nó đã được mã hóa bằng chữ ký.
Khi một máy chủ nhận được JWT, nó có thể đảm bảo dữ liệu mà nó chứa có thể được tin cậy bởi vì nó đã được xác thực với chữ ký đã được lưu trữ. Không yếu tố trung gian nào có thể sửa đổi JWT sau khi nó được gửi.
Điều quan trọng cần lưu ý là JWT đảm bảo quyền sở hữu dữ liệu nhưng không mã hóa; bất kỳ ai cũng có thể xem dữ liệu JSON chúng ta lưu trữ trong JWT một khi họ có được JWT đấy, vì nó chỉ được tuần tự hóa, không được mã hóa. Vì lý do này, nên sử dụng JWT với HTTPS.
2. Vậy nó tốt trong trường hợp nào?JWT là một công nghệ tuyệt vời để xác thực API và ủy quyền từ máy chủ đến máy chủ.
Nó không phải là một lựa chọn tốt cho các session.
3. Sử dụng JWT để xác thực APIỨng dụng nhiều nhất của JWT Token, và mục đích duy nhất bạn nên sử dụng JWT là dùng nó như một cơ chế xác thực API.
Điều này hiện nay là quá phổ biến và được sử dụng rộng rãi, kể cả Google cũng sử dụng JWT để xác thực các APIs của họ.
Ý tưởng rất đơn giản:
Bạn sẽ nhận được secret token từ service khi bạn thiết lập API
Ở phía client, bạn sẽ sử dụng secret token để kí tên và gắn nó vào token (hiện nay có rất nhiều thư viện hỗ trợ việc này)
Bạn sẽ gắn nó như một phần của API request và server sẽ biết nó là ai dựa trên request được ký với 1 unique identifier duy nhất:
4. Vô hiệu hoá 1 single tokenLàm thế nào bạn có thể làm mất hiệu lực môt single token? Một cách đơn giản là thay đổi secret key của server, làm mất hiệu lực tất cả các token. Nhưng làm vậy sẽ khiến khách hàng choáng váng, không hiểu vì sao mà token của họ “toang” như vậy.
Một cách khác để xử lý vấn đề này là thêm yếu tố thời gian vào đối tượng người dùng. Mã token tự động lưu trữ giá trị created at trong thuộc tính iat. Mỗi lần bạn kiểm tra token, bạn chỉ cần so sánh giá trị created at với giá trị thời gian ở đối tượng user.
Để vô hiệu hóa token, chỉ cần cập nhật giá trị phía máy chủ và nếu iat cũ hơn, bạn có thể reject token.
5. Lưu trữ JWTs an toànJWT cần được lưu trữ ở nơi an toàn bên trong trình duyệt của người dùng.
Nếu bạn lưu trữ nó bên trong localStorage, nó có thể truy cập bằng bất kỳ script nào trong trang của bạn (điều này thực sự tệ, vì một cuộc tấn công XSS có thể cho phép kẻ tấn công bên ngoài lấy được token).
Đừng lưu token trong localStorage (hoặc sessionStorage). Nếu bất kỳ mã script bên thứ ba nào bạn đưa vào trang của mình bị xâm phạm, nó có thể truy cập tất cả các token của người dùng. JWT cần được lưu trữ bên trong httpOnly cookie, một loại cookie đặc biệt mà chỉ có thể gửi trong các yêu cầu HTTP đến server và nó không bao giờ có thể truy cập (cả để đọc hoặc viết) từ JavaScript chạy trên trình duyệt.
6. Sử dụng JWT để trao đổi thông tin an toàn giữa hai máy chủVì JWT đã được ký, người nhận có thể chắc chắn rằng khách hàng thực sự là người mà họ nghĩ.
6.1. Sử dụng JWT cho xác thực SPAJWTs có thể được sử dụng như một cơ chế xác thực không cần đến cơ sở dữ liệu. Server có thể tránh sử dụng cơ sở dữ liệu vì dữ liệu lưu trữ trong JWT được gửi cho khách hàng là an toàn.
6.2. Sử dụng JWT để uỷ quyền hoạt động trên các máy chủGiả sử bạn đăng nhập vào 1 máy chủ, SERVER1, sau khi đăng nhập thành công thì được chuyển hướng đến một máy chủ khác SERVER2 để thực hiện một số xử lý.
SERVER1 có thể cấp cho bạn 1 JWT để ủy quyền cho phép bạn kết nối đến SERVER2. Hai máy chủ không cần chia sẻ cùng 1 session hoặc bất cứ điều gì để xác thực bạn. Sử dụng token để xử lý trường hợp này là rất hoàn hảo.
7. Session tokens cho các regular web appsBạn có thể nghĩ rằng việc sử dụng JWTs cho session token là một ý tưởng hay lúc đầu, chẳng hạn:
Bạn có thể lưu trữ bất kỳ loại thông tin user nào trên client Server có thể tin tưởng client vì JWT đã được ký và không cần phải gọi cơ sở dữ liệu để lấy thông tin bạn đã lưu trữ trong JWT Bạn không cần phải kết hợp các sessions trong cơ sở dữ liệu tập trung khi bạn gặp vấn đề cần horizontal scaling Cuối cùng, nếu bạn đã có cơ sở dữ liệu cho ứng dụng của mình, chỉ cần sử dụng bảng session và sử dụng các regular session được hỗ trợ bởi các framework server side là đủ.
Tại sao? Sẽ mất nhiều công sức nếu sử dụng JWT: vì chúng được gửi trong mọi request đến máy chủ và nó luôn luôn mất công sức hơn là sử dụng server-side sessions.
8. Cách chọn thư viện JWT hoàn hảoHãy vào trang chúng tôi và xem danh sách thư viện. Nó có danh sách các thư viện phổ biến nhất để triển khai JWT.
Chọn ngôn ngữ bạn dùng và chọn thư viện mà bạn thích, thư viện tốt nhất là thư viện có số lượng tích xanh nhiều nhất.
9. Kết luậnJWT là một tiêu chuẩn rất phổ biến mà bạn có thể sử dụng để xác thực requests bằng cách sử dụng chữ ký và trao đổi thông tin giữa các bên. Hãy chắc chắn rằng bạn lúc nào thì sử dụng nó, lúc nào thì không và cách ngăn chặn các vấn đề bảo mật cơ bản nhất.
Nguồn: https://blog.logrocket.com/jwt-authentication-best-practices/
Json Web Token (Jwt) Là Gì ?
Jwt là gì?
JWT là một phương tiện đại diện cho các yêu cầu chuyển giao giữa hai bên Client – Server , các thông tin trong chuỗi JWT được định dạng bằng JSON . Trong đó chuỗi Token phải có 3 phần là header , phần payload và phần signature được ngăn bằng dấu “.”
Vậy theo lý thuyết trên thì mình sẽ có một chuỗi Token như sau:
header . payload . signatureNhư ở trên đã nói JSON Web Token bao gồm 3 phần, được ngăn cách nhau bởi dấu chấm (.):
Header
Payload
Signature (chữ ký)
Phần header sẽ chứa kiểu dữ liệu , và thuật toán sử dụng để mã hóa ra chuỗi JWT
{ "typ" : "JWT" , "alg" : "HS256" }
“typ” (type) chỉ ra rằng đối tượng là một JWT
“alg” (algorithm) xác định thuật toán mã hóa cho chuỗi là HS256
PayloadPhần payload sẽ chứa các thông tin mình muốn đặt trong chuỗi Token như username , userId , author , … ví dụ:
{ "user_name" : "admin" , "user_id" : "1513717410" , "authorities" : "ADMIN_USER" , "jti" : "474cb37f-2c9c-44e4-8f5c-1ea5e4cc4d18" } SignaturePhần chử ký này sẽ được tạo ra bằng cách mã hóa phần header , payload kèm theo một chuỗi secret (khóa bí mật) , ví dụ:
data = base64urlEncode ( header ) + "." + base64urlEncode ( payload ) signature = Hash ( data , secret );base64UrlEncoder : thuật toán mã hóa header và payload
Đoạn code trên sau khi mã hóa header và payload bằng thuật toán base64UrlEncode ta sẽ có chuỗi như sau
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 eyJhdWQiOlsidGVzdGp3dHJlc291cmNlaWQiXSwidXNlcl9uYW1lIjoiYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiZXhwIjoxNTEzNzESau đó mã hóa 2 chuỗi trên kèm theo secret (khóa bí mật) bằng thuật toán HS256 ta sẽ có chuỗi signature như sau:
9nRhBWiRoryc8fV5xRpTmw9iyJ6EM7WTGTjvCM1e36Q Cuối cùngKết hợp 3 chuỗi trên lại ta sẽ có được một chuỗi JWT hoàn chỉnh
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJhdWQiOlsidGVzdGp3dHJlc291cmNlaWQiXSwidXNlcl9uYW1lIjoiYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiZXhwIjoxNTEzNzE . 9nRhBWiRoryc8fV5xRpTmw9iyJ6EM7WTGTjvCM1e36QNhư vậy các bạn cũng đã hiểu được các thành phần của một chuỗi JWT.
Authentication: Đây là trường hợp phổ biến nhất thường sử dụng JWT. Khi người dùng đã đăng nhập vào hệ thống thì những request tiếp theo từ phía người dùng sẽ chứa thêm mã JWT. Điều này cho phép người dùng được cấp quyền truy cập vào các url, service, và resource mà mã Token đó cho phép. Phương pháp này không bị ảnh hưởng bởi Cross-Origin Resource Sharing (CORS) do nó không sử dụng cookie.
Trao đổi thông tin: JSON Web Token là 1 cách thức khá hay để truyền thông tin an toàn giữa các thành viên với nhau, nhờ vào phần signature của nó. Phía người nhận có thể biết được người gửi là ai thông qua phần signature. Và chữ ký được tạo ra bằng việc kết hợp cả phần header, payload lại nên thông qua đó ta có thể xác nhận được chữ ký có bị giả mạo hay không.
Mã Thông Báo Web Json – Json Web Token (Jwt)
Bài viết dựa trên tài liệu theo dõi tiêu chuẩn mở Internet. Đây là sản phẩm của nhóm chuyên viên kỹ thuật Internet (IETF) và hoành thành vào tháng 05 năm 2023. Những tác giả chính của tiêu chuẩn là M. Jones làm việc tại Microsoft, J. Bradley đến từ Ping indentity và N. Sakirumra đến từ NRI. Nó là sản phẩm thể hiện sự chung sức của cộng đồng IETF đồng thời nó đã nhận được đánh giá công khai và được phê duyệt đề xuất bản bởi khối chỉ đạo kỹ thuật Internet (IESG). Đây là tài liệu mở nhưng dễ hiểu và dễ sử dụng, đến nay JWT đã vô cùng phổ biến và được sử dụng rộng dãi trên toàn cầu. Đây là phiên bản duy nhất và vẫn được giữ được sự tin cậy cao trong các tiêu chuẩn mạng.
Hình 1: Mô phòng cho JWT
Nội dung chi tiết
1. Khái quát JSON Web Token
Như đã nói ở phần giới thiệu, JWT nhỏ gọn định nghĩa cách thức truyền tin an toàn giữa các thành viên bằng một đối tượng JSON. Thông tin này có thể xác thực và đánh dấu tin cậy nhờ vào “chữ ký” của nó. Phần chữ ký này được mã hóa lại bằng HMAC hoặc RSA.
Hình 2 : Kết cấu của JWT
Header bao gồm hai phần chính: loại token và thuật toán đã dùng để mã hóa. Trong đó loại token có thể mặc định là JWT, một loại thông tin mà cho biết đoạn mã là một token JWT. Thuật toán có thể là HMAC SHA256 – HS256 hoặc RSA.
Payload chứa các “Claims”. Claims là một khối thông tin về một thực thể chẳng hạn người dùng là ai và một số metadata bắt buộc, số còn lại tuân theo về JWT hợp lệ và đầy đủ thông tin: iss (issuer), iat (issued-at time) exp (expiration time), sub (subject), aud (audience), … độ trễ phải hồi lại từ máy chủ khi tiếp nhận là do độ dài của Payload.
Singnature là chữ ký trong JWT hay một chuỗi đã được được mã hóa bởi header, payload cùng với một chuỗi bí mật theo nguyên tắc sau:
Hình 3 : Nguyên tắc của chuỗi chữ ký JWT
2. Cách thức hoạt động của JWT
Hình 4: Cách thức hoạt động của JWT
Như lượng đồ ở trên, chuỗi JWT được thực hiện theo một chu trình sau:
1. Người dùng (user) sử dụng trình duyệt đăng nhập vào một miền nào đó mà yêu cầu đăng nhập với tên đăng nhập và mật khẩu.
2. Máy chủ sẽ nhận được yêu cầu của người dùng, đồng thời kiểm tra thông tin tên đăng nhập và mật khẩu.
3. Máy chủ sau khi kiểm tra thông tin người dùng, nếu đúng sẽ trả một JWT về cho người dùng, nếu không quay lại bước 1.
4. Người dùng sẽ sử dụng mã JWT để tiếp tục sử dụng cho các yêu cầu kế tiếp trên miền của máy chủ.
5. Máy chủ sẽ không cần phải kiểm tra lại thông tin người dùng mà chỉ cần kiểm tra đúng JWT đã được cấp từ đó tăng tốc độ sử dụng trên miền giảm thời gian truy vấn.
6. Máy chủ trả phản hồi phù hợp cho người dùng.
Qua quá trình được nêu, rất rõ ràng JWT được tạo ra như một cách để trao đổi thông tin xác thực an toàn giữa hai bên. Vì vậy, JWT không ẩn, không làm mờ, không che giấu dữ liệu mà chỉ nhằm chức minh dữ liệu được tạo ra bởi một nguồn xác thực.
3. Tạo mã thông báo Web JSON
Để tạo một JWT, cần phải qua các bước sau, thứ tự của các bước không bắt buộc trong trường hợp không có sự phụ thuộc giữa đầu vào và đầu ra của các bước:
– Bước 1: Tạo bộ yêu cầu JWT chứa các giá trị Claim mong muốn. Lưu ý rằng biểu diễn khoảng trắng được cho phép tường minh mà không cần hợp thức hoá trước khi mã hoá.
– Bước 2: Đặt một tin nhắn là các octet của đại diện UTF-8 trong bộ Claim JWT.
– Bước 3: Tạo một Tiêu đề JOSE chứa bộ Thông số Header mong muốn. JWT PHẢI tuân thủ thông số kỹ thuật [JWS] hoặc [JWE]. Lưu ý rằng khoảng trắng được cho phép rõ ràng trong biểu diễn và không cần phải chuẩn hóa trước khi mã hóa.
– Bước 4: Tùy thuộc vào việc JWT là JWS hay JWE, có hai trường hợp:
+ Nếu JWT là JWS, hãy tạo JWS bằng Thông báo dưới dạng Tải trọng JWS; tất cả các bước được chỉ định trong [JWS] để tạo JWS PHẢI được tuân theo.
+ Khác, nếu JWT là JWE, hãy tạo JWE bằng cách sử dụng Tin nhắn làm văn bản gốc cho JWE; tất cả các bước được chỉ định trong [JWE] để tạo JWE PHẢI được tuân theo.
– Bước 5: Nếu thao tác ký hoặc mã hóa lồng nhau sẽ được thực hiện, hãy để Tin nhắn là JWS hoặc JWE và quay lại Bước 3, sử dụng giá trị “cty” (loại nội dung) của “JWT” trong JOSE header mới được tạo trong bước đó.
– Bước 6: Mặt khác, giá trị JWT kết quả là JWS hoặc JWE.
4. Xác thực JWT
a. Xác thực rằng JWT chứa ít nhất một ký tự (‘.’).
b. Đoạn mã hóa JOSE Header phải được dặt ở vị trí trước ký tự (‘.’) đầu tiên của JWT.
c. Basse64 mã hóa JOSE header theo nguyên tắc là không có ngắt dòng, khoảng trắng hoặc các ký tự bổ sung khác đã được sử dụng.
d. Xác minh rằng chuỗi kết quả octet là một đại diện được mã hóa UTF-8 xủa một đối tượng JSON hoàn toàn hợp lệ tuân thủ RFC 7159 [RFC7159]; và để JOSE Header là một đối tượng JSON.
e. Xác minh rằng JOSE Header kết quả chỉ bao gồm các tham số, giá trị có cú pháp, ngữ nghĩa được hiểu và hỗ trợ hoặc được chỉ định là bị bỏ qua khi không hiểu.
f. Xác định xem JWT là JWS hay JWE bằng bất kỳ phương pháp khác thuộc JWE.
g. Tùy thuộc vào việc JWT là JWS hay JWE, có hai trường hợp:
– Nếu JWT là JWS, hãy làm theo các bước được chỉ định thuộc JWS để xác thực JWS. Đặt tin nhắn là kết quả của việc giải mã Base64url cho dữ liệu của JWS.
– Mặt khác, nếu JWT là JWE, hãy làm theo các bước được chỉ định trong JWE để xác thực JWE. Hãy để tin nhắn là bản mã JWE.
i. Mặt khác, base64url mã hóa tin nhắn theo hạn chế rằng không có ngắt dòng, khoảng trắng hoặc các ký tự bổ sung khác đã được sử dụng.
j. Xác minh rằng chuỗi kết quả octet là một đoạn mã UTF-8 đại diện cho một đối tượng JSON hoàn toàn hợp lệ tuân thủ RFC 7159 [RFC7159]; hãy để Bộ công bố JWT là đối tượng JSON này.
Cuối cùng, lưu ý rằng đây là một quyết định của ứng dụng mà thuật toán có thể được sử dụng trong ngữ cảnh cụ thể. Ngay cả khi JWT có thể được xác nhận thành công, trừ khi (các) thuật toán được sử dụng trong JWT được ứng dụng chấp nhận, nó vẫn có thể từ chối JWT.
5. Quy tắc so sánh chuỗi
Việc xử lý JWT chắc chắn đòi hỏi phải so sánh các chuỗi đã biết với các thành phần và giá trị nằm trong các JSON Object. Các quy tắc JSON để thực hiện so sánh tên thành phần được mô tả trong Định dạng trao đổi dữ liệu ký hiệu đối tượng JavaScript (JSON).
Các quy tắc so sánh này PHẢI được sử dụng cho tất cả các so sánh chuỗi JSON ngoại trừ trong trường hợp định nghĩa của thành phần gọi rõ ràng rằng quy tắc so sánh khác sẽ được sử dụng riêng cho giá trị thành phần đó. Và vì vậy, chỉ các giá trị thành viên “typ” và “cty” không sử dụng các quy tắc so sánh này.
Một số ứng dụng có thể bao gồm thông tin không phân biệt chữ hoa chữ thường trong giá trị phân biệt chữ hoa chữ thường, chẳng hạn như bao gồm tên DNS như một phần của giá trị khiếu nại “iss” (nhà phát hành). Trong các trường hợp đó, ứng dụng có thể cần xác định một quy ước cho trường hợp chính tắc được sử dụng để biểu diễn các phần không phân biệt chữ hoa chữ thường, chẳng hạn như yêu cầu viết thường, nếu nhiều bên có thể cần tạo ra cùng một giá trị thì mục đích để có thể so sánh chúng. (Tuy nhiên, nếu tất cả các bên sử dụng giá trị bên sản xuất đã phát hành mà không tham chiếu với giá trị độc lập nào khác thì giá trị được sử dụng bởi nhà sản xuất có thể không có ý nghĩa.)
6. Việc lưu trữ JWT trên máy chủ.
Trên thực tế, JWT được lưu trữ trên 2 cách chính đó là:
– HTML5 Web Storeage (localStorage hoặc sessionStorage)
– Cookies
Cả hai phương thức đều nhận JWT ở trình duyệt của người dùng, cả hai đều không lưu trạng thái vì tất cả các thông tin mà API cần là JWT. Cả hai phương thức đều gửi mã thông báo (token) lên Api một cách đơn giản nhưng điều khác biệt lớn nằm ở tính bảo mật.
Đối với bảo mật JWT lưu trữ trên sessionStroreage và localStoreage, máy chủ có thể truy cập được thông qua javaScript trên cùng domain. Hay nghĩa là bất cứ code javaScript nào chạy trên chính miền của máy chú đó có thể bị tấn công bằng XSS (một dạng lỗ hổng làm kẻ tấn công chèn được một đoạn code vào miền của máy chủ). Do đó phương pháp thông thường là loại bỏ và mã hóa tất cả các dữ liệu không tin tưởng được, tuy nhiên điều này là khó và không thể bảo mật toàn bộ.
Đối với bảo mật JWT lưu trữ trên cookie, thì khi được dùng cùng với cookie flag (HttpOnly) thì không thể bị truy cập bởi các đoạn code hay nhiễm XSS. Đồng thời có thể đặt cookie flag (đảm bảo chỉ trả JWT khi đi qua htttp đã được mã hóa hoặc xác thực) để đảm bảo rằng cookie chỉ được gửi qua HTTPS. Do đây việc lưu trữ JWT trên cookie là được khuyến nghị.
Một số trường hợp, nếu là trình duyệt web thì JWT có thể lưu vào localStoreage, Ứng dụng IOS thì sẽ là Keychain và ứng dụng Android thì sẽ lưu vào SharedPrefernces.
7. Khía cạnh bảo mật
Tất cả các cân nhắc bảo mật trong đặc điểm kỹ thuật JWS cũng áp dụng cho JWT, cũng như các cân nhắc bảo mật JWE khi sử dụng mã hóa. Đặc biệt, Cân nhắc về bảo mật JWS JSON và Cân nhắc về bảo mật so sánh Unicode áp dụng như nhau đối với Bộ yêu cầu JWT theo cách tương tự như đối với Tiêu đề JOSE.
JWT có thể chứa các thông tin bí mật về quyền riêng tư của người dùng. Trong trường hợp này, PHẢI thực hiện các biện pháp để ngăn chặn việc tiết lộ thông tin này cho các bên ngoài ý muốn. Một cách để đạt được điều này là sử dụng JWT được mã hóa và xác thực người nhận, ứng dụng, máy chủ ứng dụng. Một cách khác là đảm bảo rằng các JWT chứa thông tin bí mật về quyền riêng tư không được mã hóa chỉ được truyền bằng các giao thức sử dụng mã hóa hỗ trợ xác thực điểm cuối, chẳng hạn như TLS (Transport layer security) – giao thức bảo mật tần giao vận. Bỏ qua thông tin nhạy cảm về quyền riêng tư khỏi JWT là cách đơn giản nhất để giảm thiểu các vấn đề về quyền riêng tư.
Ngoài yếu tố bảo mật về quyền riêng tư, JWT gần như tuyệt đối an toàn nằm xác thực ủy quyền.
Kết luận
JWT là một cơ chế xác thực vô cùng phổ biến và tuyệt vời. Nó cho phép người dùng khai báo thông tin người dùng và phạm vi truy cập của họ một cách có cấu trúc. Nó có thể được mã hóa và ký để chống giả mạo từ phía ứng dụng. Đồng thời việc hiểu rõ JWT cũng giúp việc nắm bắt một số tiêu chuẩn như tiêu chuẩn OpenID, OpenAPI, v.v một cách chính xác hơn, hiểu một cách rõ ràng và logic nhất.
Thông qua tiêu chuẩn mở này, ta có thêm các khía cạnh về bảo mật để xây dựng các nền tảng mới, đặc biệt nó là thành phần quan trọng trong tiêu chuẩn OpenID Connect 1.0. Nó cũng sẽ thành phần quan trọng để xây dựng khung chính phủ điện tử hướng tới xây dựng và phát triển chính phủ điện tử 2.0.
Vũ Cao Minh Đức
Tài liệu tham khảo
https://viblo.asia/
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32
Jones, M., “JSON Web Algorithms (JWA)”, draft-ietf-jose-json-web-algorithms , December 2014.
Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE)”, draft-ietf-jose-json-web-encryption , December 201
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS)”, draft-ietf-jose-json-web-signature , December 2014.
Tìm Hiểu Về Json Web Token (Jwt)
JSON Web Mã (JWT) là một chuẩn mở (RFC 7519) định nghĩa một cách nhỏ gọn và khép kín để truyền một cách an toàn thông tin giữa các bên dưới dạng đối tượng JSON. Thông tin này có thể được xác minh và đáng tin cậy vì nó có chứa chữ ký số. JWTs có thể được ký bằng một thuật toán bí mật (với thuật toán HMAC) hoặc một public / private key sử dụng mã hoá RSA.
Một ví dụ về JWT Token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjEzODY4OTkxMzEsImlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQxZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdiNDYxNGI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.uKqU9dTB6gKwG6jQCuXYAiMNdfNRw98Hw_IWuA5MaMoThoạt trông phức tạp là thế nhưng nếu hiểu, cấu trúc của một JWT chỉ đơn giản như sau:
Nói một cách khác, JWT là sự kết hợp (bởi dấu .) một Object Header dưới định dạng JSON được encode base64, một payload object dưới định dạng JSOn được encode base64 và một Signature cho URI cũng được mã hóa base64 nốt.
Giải thích thêm về 3 thành phần của JWTHeader
Header bao gồm hai phần chính: loại token (mặc định là JWT – Thông tin này cho biết đây là một Token JWT) và thuật toán đã dùng để mã hóa (HMAC SHA256 – HS256 hoặc RSA).
Payload
Payload chứa các claims. Claims là một các biểu thức về một thực thể (chẳng hạn user) và một số metadata phụ trợ. Có 3 loại claims thường gặp trong Payload: reserved, public và private claims.
Reserved claims: Đây là một số metadata được định nghĩa trước, trong đó một số metadata là bắt buộc, số còn lại nên tuân theo để JWT hợp lệ và đầy đủ thông tin: iss (issuer), iat (issued-at time) exp (expiration time), sub (subject), aud (audience), jti (Unique Identifier cho JWT, Can be used to prevent the JWT from being replayed. This is helpful for a one time use token.) … Ví dụ:
Public Claims – Claims được cộng đồng công nhận và sử dụng rộng rãi.
Private Claims – Claims tự định nghĩa (không được trùng với Reserved Claims và Public Claims), được tạo ra để chia sẻ thông tin giữa 2 parties đã thỏa thuận và thống nhất trước đó.
Signature
Chữ ký Signature trong JWT là một chuỗi được mã hóa bởi header, payload cùng với một chuỗi bí mật theo nguyên tắc sau:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)Do bản thân Signature đã bao gồm cả header và payload nên Signature có thể dùng để kiểm tra tính toàn vẹn của dữ liệu khi truyền tải.
When should you use JSON Web Tokens?
Một trong những tình huống ứng dụng JWT thường gặp, đó là:
Authentication: Tình huống thường gặp nhất, khi user logged in, mỗi request tiếp đó đều kèm theo chuỗi token JWT, cho phép người dùng có thể truy cập đường dẫn, dịch vụ và tài nguyên được phép ứng với token đó. Single Sign On cũng là một chức năng có sử dụng JWT một cách rộng rãi, bởi vì chuỗi JWT có kích thước đủ nhỏ để đính kèm trong request và sử dụng ở nhiều hệ thống thuộc các domain khác nhau.
Information Exchange: JSON Web Token cũng là một cách hữu hiệu và bảo mật để trao đổi thông tin giữa nhiều ứng dụng, bởi vì JWT phải được ký (bằng cặp public / private key), bạn có thể chắc rằng người gửi chính là người mà họ nói rằng họ là (nói tóm tắt hơn là không hoặc khó để mạo danh bằng JWT), ngoài ra, chữ ký cũng được tính toán dựa trên nội dung của header và nội dung payload, nhờ đó, bạn có thể xác thực được nội dung là nguyên bản, chưa được chỉnh sửa hoặc can thiệp. Tuy nhiên, một lưu ý hết sức quan trọng là do cấu trúc của JWT đơn giản nên JWT có thể dễ dàng bị decode, do vậy, bạn không nên dùng JWT để transfer các thông tin nhạy cảm.
How do JSON Web Tokens work?
Ở đây, mình ví dụ cụ thể ứng dụng của JWT trong bài toán Authenticate (xác thực) – Trong việc xác thực, khi user đăng nhập thành công (Browser sẽ post username và mật khẩu về Server), Server sẽ trả về một chuỗi JWT về Browser, và Token JWT này cần được lưu lại trong Browser của người dùng (thường là LocalStorage hoặc Cookies), thay vì cách truyền thống là tạo một session trên Server và trả về Cookie.
Bất cứ khi nào mà User muốn truy cập vào Route được bảo vệ (mà chỉ có User đã đăng nhập mới được phép), Browser sẽ gửi token JWT này trong Header Authorization, Bearer schema của request gửi đi.
Đây là cách mà stateless (phi trạng thái) authentication làm việc, trạng thái của user không được lưu trong bộ nhớ của Server mà được đóng gói hẳn vào trong JWT. Server sẽ kiểm tra Token JWT này có hợp lệ hay không (Bởi vì JWT có tính chất self-contained, mọi thông tin cần thiết để kiểm tra JWT đều đã được chứa trong Token JWT).
Do tính chất stateless nên chúng ta không còn phải lo lắng về domains nào được sử dụng cho API của bạn, như không còn gặp rắc rối với CORS (Cross-Origin Resource Sharing) vì nó không sử dụng cookies.
JWT Introduction
All Rights Reserved
So Sánh Session Và Cookies
Là phiên làm việc để lưu trữ 1 biến và biến đó có thể tồn tại từ trang này đến trang khác(cùng tên miền)
Session được lưu trữ trên server
Thời gian sống của nó sẽ kết thúc khi ta xoá nó hoặc hết tuổi thọ (tắt trình duyệt)
Cách làm việc của session
Khi Session được tạo ra, php tạo 1 định danh duy nhất cho session đó, định danh này là chuỗi ký tự ngẫu nhiên của 32 số hexa.
Ví dụ như: 3c7foj34c3jj973hjkop2fc937e3443
Khi đó 1 cookies được gọi là PHPSESSID sẽ được tự động gửi đến máy người dùng để lưu trữ chuỗi định danh session duy nhất ở trên
Một file được tự động tạo và lưu trên server trong 1 thư mục tạm thời đã được chỉ định và nó mang tên của định danh duy nhất và được bắt đầu bằng sess_.
Ví dụ: sess_3c7foj34c3jj973hjkop2fc937e3443
Sử dụng session
Cookies là 1 phần dữ liệu được lưu trên máy khách, mỗi khi máy khách yêu cầu đến máy chủ nào đó, thì nó sẽ gửi phần dữ liệu được lưu trong cookies tương ứng tới máy chủ đó
Một cookies có độ lớn giới hạn bởi trình duyệt là 4kb
Browsers giới hạn số cookies lưu trữ trên 1 server là khoảng 50 cookies
Cookie có một số thông số như sau:setcookie(name, value, time, path, domain, security);
name: tên của biến cookies (bắt buộc)
value: value của cookies
time: thời gian sống của cookies
path: thư mục mà cookies có hiệu lực
domain: tên miền mà cookies có hiệu lực
security: Nếu là 1 thì cookies chỉ được gửi bằng đường dẫn an toàn HTTPS, nếu là 0 thì cookies có thể gửi bằng HTTP thông thường
Xác định người dùng với cookiesVới Cookies, có 3 bước để xác định người dùng cũ:
Server gửi 1 tập tin bao gồm thông tin của người dung(tên, tuổi, ….)
Trình duyệt sẽ lưu lại trên local để sử dụng trong tương lai
Khi trình duyệt gửi bất cứ request nào đến server thì nó sẽ gửi luôn thông tin của cookies đó lên server và server đó sẽ sử dụng thông tin đó để xác thực người dùng này
Thao tác với cookies
Session có thêm 1 ưu điểm nữa là: Nếu trình duyệt từ chối lưu trữ cookies chúng ta vẫn có thể truyền session từ trang này sang trang khác thông qua url: ví dụ: test.php?session=abcVậy với session và cookies thì ta nên sử dụng gì?
Câu trả lời là còn tuỳ vào ý đồ của lập trình viên.
Rất cám ơn anh chị và các bạn đã đọc và rất mong giúp các bạn biết thêm về session và cookies.
Cập nhật thông tin chi tiết về So Sánh Json Web Token(Jwt) Và Session Cookies Trong Việc Authentication trên website Channuoithuy.edu.vn. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất. Chúc bạn một ngày tốt lành!