Quy trình đăng nhập một lần sử dụng JWT để xác thực tên miền chéo

Có rất nhiều thông tin trên mạng về việc sử dụng JWT ( Json Web Token) để xác thực. Nhưng tôi vẫn không tìm thấy lời giải thích rõ ràng về quy trình phải như thế nào khi sử dụng mã thông báo JWT cho giải pháp đăng nhập một lần trong môi trường nhiều miền .

Tôi làm việc cho một công ty có rất nhiều trang web trên các máy chủ khác nhau. Hãy sử dụng example1.com và example2.com . Chúng tôi cần một giải pháp đăng nhập một lần, có nghĩa là nếu người dùng xác thực trên example1.com , chúng tôi muốn anh ta cũng được xác thực trên example2.com , tự động.

Sử dụng luồng OpenId Connect , tôi hiểu rằng người dùng muốn xác thực trên example1.com trước tiên sẽ được chuyển hướng đến máy chủ xác thực (hoặc OP: "Nhà cung cấp OpenId"). Người dùng xác thực trên máy chủ đó, sau đó chuyển hướng anh ta trở lại trang web example1.com ban đầu bằng mã thông báo JWT đã ký. (Tôi hiểu rằng có một luồng khác trả về mã thông báo trung gian mà chính nó có thể được trao đổi lấy mã thông báo JWT thực sau này, nhưng tôi không nghĩ rằng điều này là bắt buộc đối với chúng tôi) ...

Vì vậy, bây giờ người dùng đã trở lại example1.com và được xác thực! Anh ta có thể đưa ra yêu cầu, chuyển mã thông báo JWT trong Authenticationtiêu đề và máy chủ có thể xác minh JWT đã ký và do đó có thể xác định người dùng. Đẹp!

Câu hỏi đầu tiên:

Mã thông báo JWT nên được lưu trữ trên máy khách như thế nào? Một lần nữa, có rất nhiều thông tin về điều này, và mọi người dường như đồng ý rằng sử dụng Web Storagelà cách để đi thay vì tốt cũ cookies. Chúng tôi muốn JWT liên tục giữa các lần khởi động lại trình duyệt, vì vậy hãy sử dụng Local Storage, không Session Storage...

Bây giờ người dùng có thể khởi động lại trình duyệt của mình và anh ta sẽ vẫn được xác thực trên example1.com , miễn là mã thông báo JWT chưa hết hạn!

Ngoài ra, nếu example1.com cần thực hiện một yêu cầu Ajax tới một miền khác của chúng tôi, tôi hiểu việc định cấu hình CORS sẽ cho phép điều đó. Nhưng trường hợp sử dụng chính của chúng tôi không phải là yêu cầu tên miền chéo mà là có một giải pháp đăng nhập duy nhất !

Do đó, câu hỏi chính:

Bây giờ, quy trình sẽ như thế nào, nếu người dùng truy cập example2.com và chúng tôi muốn anh ta được xác thực bằng cách sử dụng mã thông báo JWT mà anh ta đã có? Local Storagedường như không cho phép truy cập tên miền chéo vì vậy tại thời điểm này, trình duyệt không thể đọc mã thông báo JWT để thực hiện yêu cầu tới example2.com !

Nên :

• Người dùng lại được chuyển hướng đến máy chủ xác thực ? Khi người dùng xác thực cho example1.com , máy chủ xác thực có thể đã đặt một cookie cho người dùng nên yêu cầu xác thực mới này cho example2.com có thể sử dụng cookie đó để biết rằng người dùng đã được xác thực và ngay lập tức chuyển hướng người đó trở lại example2.com với cùng một mã thông báo JWT?
• Hoặc trình duyệt, trên example2.com , có thể truy cập mã thông báo JWT mà không cần phải truy cập lại máy chủ xác thực không? Tôi thấy có những giải pháp lưu trữ chéo , nhưng những giải pháp đó có được sử dụng rộng rãi không? Chúng có phải là giải pháp được đề xuất cho môi trường SSO tên miền chéo không?

Chúng tôi không muốn bất cứ thứ gì lạ mắt, chúng tôi sẽ hài lòng với giải pháp được sử dụng nhiều nhất!

Người dùng sẽ được chuyển hướng lại đến máy chủ xác thực và nhận mã thông báo mới (JWT), một mã được nhắm mục tiêu cụ thể cho example2.com. Đây là cách OpenID Connect và bất kỳ giao thức SSO liên kết miền chéo nào khác hoạt động.

Chuyển hướng người dùng đến dịch vụ xác thực trung tâm khi người dùng chưa đăng nhập để yêu cầu thông tin xác thực và phát hành mã xác thực mới là tình huống phổ biến trong các hệ thống Đăng nhập Một lần sử dụng các giao thức nổi tiếng như oauth2 hoặc OpenId Connect

Tuy nhiên, khi lược đồ này được sử dụng trên các miền, nhược điểm chính là người dùng sẽ được chuyển hướng và xác thực mỗi khi anh ta điều hướng đến miền khác do chính sách cùng nguồn gốc : không thể chia sẻ mã thông báo truy cập giữa các miền ( example2.comkhông thể truy cập dữ liệu của example1.com), vì vậy miền đích sẽ coi người dùng là người dùng chưa được xác thực, chuyển hướng người dùng đến dịch vụ SSO trung tâm.

Để ngăn dịch vụ xác thực yêu cầu lại thông tin đăng nhập, thông thường sẽ có cookie phiên (không phải mã thông báo truy cập), nhưng có một kỹ thuật để chia sẻ dữ liệu giữa các miền bằng cách sử dụng localStorage / cookie của trình duyệt và iframe trỏ đến miền trung gian sso.example.com

1. Để xác thực người dùng trong example1.com, hãy chuyển hướng anh ta đến máy chủ xác thực trong sso.example.com, cấp JWT sau khi xác thực và lưu trữ nó trong localStorage của miền này. Sau đó, chuyển hướng người dùng đến miền gốc example1.com

2. Tạo iframe example2.comđể trỏ tới sso.example.com. Iframe trong sso.example.com đọc mã thông báo JWT và gửi thông báo đến trang mẹ

3. Trang mẹ nhận được thông báo và nhận được mã thông báo đính kèm tiếp tục với quy trình SSO

Không có vấn đề với chính sách cùng nguồn gốc vì sso.example.comcó quyền truy cập vào localStorage của nó và giao tiếp giữa iframe và trang mẹ được phép nếu miền gốc và miền đích nhận ra nhau (xem http://blog.teamtreehouse.com/cross-domain- nhắn tin với bưu điện )

Để đơn giản hóa việc phát triển, gần đây chúng tôi đã phát hành SSO tên miền chéo với JWT tại https://github.com/Aralink/ssojwt

Phương pháp này hoàn toàn tương thích với các luồng SSO. Đây chỉ là một cách để chia sẻ mã thông báo xác thực mà không cần chuyển hướng và tránh những lần đăng nhập không cần thiết khi các miền được liên kết

Không chắc liệu điều này có trả lời cho bạn câu hỏi hay không, nhưng nếu mục tiêu chính của bạn là đăng nhập một lần, tôi nghĩ một proxy ngược đơn giản sẽ giải quyết được vấn đề của bạn (ít nhất là một bộ lưu trữ tên miền chéo).

Vì vậy example1.com example2.com

sẽ trở thành một cái gì đó giống như

example.com/example1

example.com/example2

(Và từ phía người dùng, điều này thường rõ ràng hơn)

Nếu đó không phải là một tùy chọn, bạn có thể phải thiết lập để khi người dùng xác thực trong 1 miền, nó sử dụng AJAX / iframe ẩn để tạo xác thực với các miền khác (gửi mã thông báo 1 lần qua url nếu bạn phải ).

và nếu ĐÓ không phải là một tùy chọn, bạn có thể phải sử dụng tên người dùng + mã pin, vì các trình duyệt ngày càng khắt khe hơn về tương tác giữa nhiều miền.