Xác thực mã thông báo so với cookie

Sự khác biệt giữa xác thực mã thông báo và xác thực bằng cookie là gì?

Tôi đang cố gắng triển khai Bản thử nghiệm Ember Auth Rails nhưng tôi không hiểu lý do đằng sau việc sử dụng xác thực mã thông báo như được mô tả trong Câu hỏi thường gặp về Ember Auth về câu hỏi "Tại sao xác thực mã thông báo?"

Một ứng dụng web điển hình chủ yếu là không trạng thái , vì tính chất yêu cầu / phản hồi của nó. Giao thức HTTP là ví dụ tốt nhất về giao thức không trạng thái . Nhưng vì hầu hết các ứng dụng web đều cần trạng thái , để giữ trạng thái , giữa máy chủ và máy khách, cookie được sử dụng để máy chủ có thể gửi mọi phản hồi trở lại máy khách. Điều này có nghĩa là yêu cầu tiếp theo được thực hiện từ máy khách sẽ bao gồm cookie này và do đó sẽ được máy chủ nhận ra. Bằng cách này, máy chủ có thể duy trì phiên với máy khách không trạng thái , biết hầu hết mọi thứ về trạng thái của ứng dụng , nhưng được lưu trữ trong máy chủ. Trong kịch bản này, không có lúc nào khách hàng giữtrạng thái , đó không phải là cách Ember.js hoạt động.

Trong Ember.js mọi thứ khác nhau. Ember.js làm cho công việc của lập trình viên dễ dàng hơn vì nó thực sự giữ trạng thái cho bạn, trong máy khách, biết mọi lúc về trạng thái của nó mà không phải yêu cầu máy chủ yêu cầu dữ liệu trạng thái .

Tuy nhiên, trạng thái giữ trong máy khách đôi khi cũng có thể đưa ra các vấn đề tương tranh mà đơn giản là không có trong các tình huống không trạng thái . Tuy nhiên, Ember.js cũng giải quyết vấn đề này cho bạn, cụ thể là dữ liệu ember được xây dựng với ý tưởng này. Tóm lại, Ember.js là một khung được thiết kế cho các máy khách có trạng thái .

Ember.js không hoạt động như một ứng dụng web phi trạng thái thông thường trong đó phiên , trạng thái và cookie tương ứng được xử lý gần như hoàn toàn bởi máy chủ. Ember.js giữ trạng thái hoàn toàn trong javascript (trong bộ nhớ của khách hàng chứ không phải trong DOM như một số khung công tác khác) và không cần máy chủ để quản lý phiên. Điều này dẫn đến việc Ember.js linh hoạt hơn trong nhiều tình huống, ví dụ: khi ứng dụng của bạn ở chế độ ngoại tuyến.

Rõ ràng vì lý do bảo mật, nó cần một loại mã thông báo hoặc khóa duy nhất được gửi đến máy chủ mỗi khi yêu cầu được thực hiện để được xác thực , theo cách này, máy chủ có thể tra cứu mã thông báo gửi (ban đầu được cung cấp bởi máy chủ) và xác minh nếu nó hợp lệ trước khi gửi phản hồi lại cho khách hàng.

Theo tôi, lý do chính tại sao sử dụng mã thông báo xác thực thay vì cookie như được nêu trong Câu hỏi thường gặp của Ember Auth chủ yếu là do bản chất của khung Ember.js và cũng vì nó phù hợp hơn với mô hình ứng dụng web trạng thái . Do đó, cơ chế cookie không phải là cách tiếp cận tốt nhất khi xây dựng ứng dụng Ember.js.

Tôi hy vọng câu trả lời của tôi sẽ có ý nghĩa hơn cho câu hỏi của bạn.

Http là không quốc tịch. Để ủy quyền cho bạn, bạn phải "ký" mọi yêu cầu bạn gửi đến máy chủ.

Xác thực mã thông báo

• Yêu cầu đến máy chủ được ký bởi "mã thông báo" - thông thường có nghĩa là đặt tiêu đề http cụ thể, tuy nhiên, chúng có thể được gửi trong bất kỳ phần nào của yêu cầu http (phần thân POST, v.v.)

• Ưu điểm:

  • Bạn chỉ có thể ủy quyền cho các yêu cầu bạn muốn ủy quyền. (Cookies - thậm chí cookie ủy quyền được gửi cho mỗi yêu cầu.)
  • Miễn dịch với XSRF (Ví dụ ngắn về XSRF - Tôi sẽ gửi cho bạn một liên kết trong email sẽ giống như thế <img src="http://bank.com?withdraw=1000&to=myself" />và nếu bạn đăng nhập qua xác thực cookie đến bank.com và bank.com không có bất kỳ phương tiện nào của XSRF bảo vệ, tôi sẽ rút tiền từ tài khoản của bạn chỉ bằng thực tế là trình duyệt của bạn sẽ kích hoạt yêu cầu GET được ủy quyền cho url đó.) Lưu ý có các biện pháp chống giả mạo bạn có thể làm với xác thực dựa trên cookie - nhưng bạn phải thực hiện những yêu cầu đó.
  • Cookies được ràng buộc với một tên miền duy nhất. Một cookie được tạo trên miền foo.com không thể được đọc bởi tên miền bar.com, trong khi bạn có thể gửi mã thông báo đến bất kỳ tên miền nào bạn muốn. Điều này đặc biệt hữu ích cho các ứng dụng một trang đang tiêu thụ nhiều dịch vụ cần được ủy quyền - vì vậy tôi có thể có một ứng dụng web trên tên miền myapp.com có ​​thể thực hiện các yêu cầu phía khách hàng được ủy quyền cho myservice1.com và myservice2.com.
• Nhược điểm:
  • Bạn phải lưu trữ mã thông báo ở đâu đó; trong khi cookie được lưu trữ "ra khỏi hộp". Các vị trí xuất hiện trong tâm trí là localStorage (con: mã thông báo vẫn tồn tại ngay cả sau khi bạn đóng cửa sổ trình duyệt), sessionStorage (pro: mã thông báo bị loại bỏ sau khi bạn đóng cửa sổ trình duyệt, con: mở một liên kết trong tab mới sẽ hiển thị tab đó ẩn danh) và cookie (Pro: mã thông báo bị loại bỏ sau khi bạn đóng cửa sổ trình duyệt. Nếu bạn sử dụng cookie phiên, bạn sẽ được xác thực khi mở liên kết trong tab mới và bạn miễn dịch với XSRF vì bạn bỏ qua cookie để xác thực, bạn chỉ đang sử dụng nó làm bộ lưu trữ mã thông báo. Con: cookie được gửi cho mỗi yêu cầu duy nhất. Nếu cookie này không được đánh dấu là https, bạn sẽ mở cho con người trong các cuộc tấn công ở giữa.)
  • Việc tấn công XSS chống lại xác thực dựa trên mã thông báo dễ dàng hơn một chút (nghĩa là nếu tôi có thể chạy tập lệnh được chèn trên trang web của bạn, tôi có thể đánh cắp mã thông báo của bạn; tuy nhiên, xác thực dựa trên cookie cũng không phải là viên đạn bạc - trong khi cookie được đánh dấu là Khách hàng chỉ có thể đọc http, khách hàng vẫn có thể yêu cầu thay mặt bạn sẽ tự động bao gồm cookie ủy quyền.)
  • Yêu cầu tải xuống một tệp, được cho là chỉ hoạt động đối với người dùng được ủy quyền, yêu cầu bạn sử dụng API tệp. Yêu cầu tương tự hoạt động ngoài hộp để xác thực dựa trên cookie.

Xác thực cookie

• Một yêu cầu đến máy chủ luôn được đăng nhập bằng cookie ủy quyền.
• Ưu điểm:
  • Cookies có thể được đánh dấu là "chỉ http" khiến chúng không thể được đọc ở phía máy khách. Điều này tốt hơn cho bảo vệ tấn công XSS.
  • Đi ra khỏi hộp - bạn không phải thực hiện bất kỳ mã nào ở phía máy khách.
• Nhược điểm:
  • Giới hạn cho một tên miền duy nhất. (Vì vậy, nếu bạn có một ứng dụng trang duy nhất yêu cầu nhiều dịch vụ, cuối cùng bạn có thể làm những thứ điên rồ như một proxy ngược.)
  • Dễ bị tổn thương đối với XSRF. Bạn phải thực hiện các biện pháp bổ sung để làm cho trang web của bạn được bảo vệ chống lại giả mạo yêu cầu trang web chéo.
  • Được gửi cho mỗi yêu cầu, (ngay cả đối với các yêu cầu không yêu cầu xác thực).

Nhìn chung, tôi muốn nói rằng các mã thông báo cho phép bạn linh hoạt hơn, (vì bạn không bị ràng buộc với một tên miền). Nhược điểm là bạn phải tự làm một số mã hóa.

• Mã thông báo cần được lưu trữ ở đâu đó (lưu trữ cục bộ / phiên hoặc cookie)

• Mã thông báo có thể hết hạn như cookie, nhưng bạn có nhiều quyền kiểm soát hơn

• Lưu trữ cục bộ / phiên sẽ không hoạt động trên các miền, sử dụng cookie đánh dấu

• Yêu cầu chiếu trước sẽ được gửi trên mỗi yêu cầu CORS

• Khi bạn cần truyền phát thứ gì đó, hãy sử dụng mã thông báo để nhận yêu cầu đã ký

• Dễ dàng đối phó với XSS hơn XSRF

• Mã thông báo được gửi theo mọi yêu cầu, xem kích thước của nó

• Nếu bạn lưu trữ thông tin bí mật, hãy mã hóa mã thông báo

• Mã thông báo Web JSON có thể được sử dụng trong OAuth

• Mã thông báo không phải là viên đạn bạc, hãy suy nghĩ cẩn thận về các trường hợp sử dụng ủy quyền của bạn

http://blog.auth0.com/2014/01/27/ten-things-you-should-ledge-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Dành cho nhân viên của Google :

• KHÔNG trộn lẫn trạng thái với các cơ chế chuyển trạng thái

TUYÊN BỐ

• Stateful = lưu thông tin ủy quyền về phía máy chủ, đây là cách truyền thống
• Statless = lưu thông tin ủy quyền về phía khách hàng, cùng với chữ ký để đảm bảo tính toàn vẹn

CƠ CHẾ

• Cookie = tiêu đề đặc biệt với xử lý đặc biệt (truy cập, lưu trữ, hết hạn, bảo mật, tự động chuyển)
• Tiêu đề tùy chỉnh = ví dụ: Authorizationchỉ là tiêu đề mà không có bất kỳ xử lý đặc biệt nào, khách hàng phải quản lý tất cả các khía cạnh của chuyển khoản
• Khác . Các cơ chế chuyển khác có thể được sử dụng, ví dụ chuỗi truy vấn là một lựa chọn để chuyển ID xác thực trong một thời gian nhưng bị bỏ qua vì sự không an toàn của nó

SO SÁNH TUYỆT VỜI

• "Ủy quyền nhà nước" có nghĩa là máy chủ lưu trữ và duy trì thông tin ủy quyền người dùng trên máy chủ, làm cho ủy quyền trở thành một phần của trạng thái ứng dụng
• Điều này có nghĩa là khách hàng chỉ cần giữ "ID xác thực" và máy chủ có thể đọc chi tiết xác thực từ cơ sở dữ liệu của nó
• Điều này ngụ ý rằng máy chủ giữ một nhóm các xác thực hoạt động (người dùng đã đăng nhập) và sẽ truy vấn thông tin này cho mọi yêu cầu
• "Ủy quyền không quốc tịch" có nghĩa là máy chủ không lưu trữ và duy trì thông tin xác thực người dùng, đơn giản là họ không biết người dùng nào đã đăng nhập và dựa vào máy khách để tạo thông tin xác thực
• Khách hàng sẽ lưu trữ thông tin xác thực hoàn chỉnh như bạn là ai (ID người dùng) và có thể là quyền, thời gian hết hạn, v.v., đây không chỉ là ID xác thực, do đó, nó được cấp mã thông báo tên mới
• Rõ ràng khách hàng không thể tin cậy được, vì vậy dữ liệu xác thực được lưu trữ cùng với chữ ký được tạo từ đó hash(data + secret key), nơi khóa bí mật chỉ được biết đến với máy chủ, do đó có thể xác minh tính toàn vẹn của dữ liệu mã thông báo
• Lưu ý rằng cơ chế mã thông báo chỉ đảm bảo tính toàn vẹn, nhưng không bảo mật, khách hàng phải thực hiện điều đó
• Điều này cũng có nghĩa là mọi khách hàng yêu cầu phải gửi một mã thông báo hoàn chỉnh, phát sinh thêm băng thông

CƠ CHẾ

• "Cookie" chỉ là một tiêu đề, nhưng với một số thao tác được tải sẵn trên trình duyệt
• Cookie có thể được đặt bởi máy chủ và tự động lưu bởi khách hàng và sẽ tự động gửi cho cùng một tên miền
• Cookie có thể được đánh dấu là httpOnlydo đó ngăn truy cập JavaScript của khách hàng
• Các hoạt động được tải sẵn có thể không khả dụng trên các nền tảng khác ngoài trình duyệt (ví dụ: thiết bị di động), điều này có thể dẫn đến những nỗ lực bổ sung
• "Tiêu đề tùy chỉnh" chỉ là các tiêu đề tùy chỉnh mà không có các hoạt động được tải sẵn
• Khách hàng có trách nhiệm nhận, lưu trữ, bảo mật, gửi và cập nhật phần tiêu đề tùy chỉnh cho mỗi yêu cầu, điều này có thể giúp ngăn chặn một số nhúng URL độc hại đơn giản

TỔNG HỢP

• Không có phép thuật, trạng thái xác thực phải được lưu trữ ở đâu đó, tại máy chủ hoặc máy khách
• Bạn có thể triển khai trạng thái / không trạng thái với cookie hoặc các tiêu đề tùy chỉnh khác
• Khi mọi người nói về những điều đó, suy nghĩ mặc định của họ chủ yếu là: statless = token + tiêu đề tùy chỉnh, stateful = auth ID + cookie; Đây KHÔNG phải là những lựa chọn duy nhất có thể
• Chúng có những ưu và nhược điểm, nhưng ngay cả đối với các mã thông báo được mã hóa, bạn không nên lưu trữ thông tin nhạy cảm

Liên kết

Tôi tin rằng có một số nhầm lẫn ở đây. Sự khác biệt đáng kể giữa xác thực dựa trên cookie và hiện có thể có với HTML5 Web Storage là các trình duyệt được xây dựng để gửi dữ liệu cookie bất cứ khi nào chúng yêu cầu tài nguyên từ miền đặt chúng. Bạn không thể ngăn chặn điều đó mà không tắt cookie. Các trình duyệt không gửi dữ liệu từ Web Storage trừ khi mã trong trang gửi nó . Và các trang chỉ có thể truy cập dữ liệu mà họ lưu trữ, không phải dữ liệu được lưu trữ bởi các trang khác.

Vì vậy, một người dùng lo lắng về cách dữ liệu cookie của họ có thể được Google hoặc Facebook sử dụng có thể tắt cookie. Nhưng, họ có ít lý do hơn để tắt Lưu trữ web (cho đến khi các nhà quảng cáo tìm ra cách sử dụng điều đó).

Vì vậy, đó là sự khác biệt giữa dựa trên cookie và mã thông báo, cái sau sử dụng Lưu trữ web.

Xác thực dựa trên mã thông báo là không trạng thái, máy chủ không cần lưu trữ thông tin người dùng trong phiên. Điều này mang lại khả năng mở rộng ứng dụng mà không cần lo lắng người dùng đã đăng nhập vào đâu. Có mối quan hệ với Khung máy chủ web đối với cookie trong khi đó không phải là vấn đề với mã thông báo. Vì vậy, cùng một mã thông báo có thể được sử dụng để tìm nạp tài nguyên an toàn từ một tên miền khác với tên miền mà chúng tôi đã đăng nhập để tránh xác thực uid / pwd khác.

Bài viết rất hay ở đây:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Sử dụng mã thông báo khi ...

Liên đoàn là mong muốn. Ví dụ: bạn muốn sử dụng một nhà cung cấp (Bộ phân phối mã thông báo) làm nhà phát hành mã thông báo, sau đó sử dụng máy chủ api của bạn làm trình xác thực mã thông báo. Một ứng dụng có thể xác thực với Bộ phân phối mã thông báo, nhận mã thông báo và sau đó xuất trình mã thông báo đó cho máy chủ api của bạn để được xác minh. (Tương tự hoạt động với Đăng nhập Google. Hoặc Paypal. Hoặc Salesforce.com, v.v.)

Không đồng bộ là bắt buộc. Ví dụ: bạn muốn khách hàng gửi yêu cầu và sau đó lưu trữ yêu cầu đó ở đâu đó, sẽ được hành động bởi một hệ thống riêng "sau". Hệ thống riêng biệt đó sẽ không có kết nối đồng bộ với máy khách và nó có thể không có kết nối trực tiếp đến phòng cấp phát mã thông báo trung tâm. Hệ thống xử lý không đồng bộ có thể được đọc JWT để xác định xem mục công việc có thể và nên được hoàn thành sau đó hay không. Theo một cách nào đó, điều này có liên quan đến ý tưởng Liên đoàn ở trên. Hãy cẩn thận ở đây, mặc dù: JWT hết hạn. Nếu hàng đợi giữ mục công việc không được xử lý trong vòng đời của JWT, thì các khiếu nại sẽ không còn được tin cậy nữa.

Yêu cầu đã ký Cient là bắt buộc. Tại đây, yêu cầu được ký bởi khách hàng bằng khóa riêng của anh ấy và máy chủ sẽ xác thực bằng khóa công khai đã đăng ký của khách hàng.

Một trong những khác biệt chính là cookie phải tuân theo Chính sách xuất xứ tương tự trong khi mã thông báo thì không. Điều này tạo ra tất cả các loại hiệu ứng dòng xuống.

Vì cookie chỉ được gửi đến và từ một máy chủ lưu trữ cụ thể mà máy chủ phải chịu gánh nặng xác thực người dùng và người dùng phải tạo một tài khoản có dữ liệu bảo mật với máy chủ đó để có thể xác minh được.

Mặt khác, các mã thông báo được phát hành và không phải tuân theo chính sách xuất xứ tương tự. Nhà phát hành có thể là bất kỳ ai theo nghĩa đen và tùy thuộc vào chủ nhà quyết định nhà phát hành nào sẽ tin tưởng. Một công ty phát hành như Google và Facebook thường được tin tưởng tốt để chủ nhà có thể chuyển gánh nặng xác thực người dùng (bao gồm lưu trữ tất cả dữ liệu bảo mật người dùng) sang một bên khác và người dùng có thể hợp nhất dữ liệu cá nhân của họ theo một công ty phát hành cụ thể và không phải nhớ một loạt các mật khẩu khác nhau cho mỗi máy chủ mà họ tương tác.

Điều này cho phép ký một lần vào các tình huống làm giảm ma sát tổng thể trong trải nghiệm người dùng. Về lý thuyết, web cũng trở nên an toàn hơn khi các nhà cung cấp nhận dạng chuyên biệt xuất hiện để cung cấp dịch vụ xác thực thay vì mỗi trang web ma và pa quay vòng các hệ thống xác thực của họ, có thể là một nửa. Và khi các nhà cung cấp này nổi lên chi phí cung cấp tài nguyên web an toàn cho các xu hướng tài nguyên rất cơ bản thậm chí là không.

Vì vậy, các mã thông báo nói chung làm giảm ma sát và chi phí liên quan đến việc cung cấp xác thực và chuyển gánh nặng của các khía cạnh khác nhau của một trang web bảo mật sang các bên tập trung có khả năng tốt hơn để thực hiện và duy trì hệ thống bảo mật.