Thực hiện điểm xác thực duy nhất


8

Tôi đang xây dựng một loạt các ứng dụng web được kết nối với một điểm xác thực duy nhất. Về cơ bản, người dùng cố gắng truy cập một trang web, nếu không được xác thực, họ sẽ được chuyển hướng đến trang đăng nhập của hệ thống xác thực trung tâm. Khi họ đăng nhập thành công, họ được chuyển hướng đến ứng dụng của họ. Từ đó trở đi, nếu họ truy cập bất kỳ ứng dụng nào khác, họ sẽ tự động đăng nhập.

Một vài chi tiết bổ sung: 1) tất cả các ứng dụng sẽ chạy trong cùng một tên miền, vì vậy tôi có thể sử dụng cookie miền, điều này giúp mọi việc dễ dàng hơn; 2) người dùng có thể được cấp quyền truy cập vào một số ứng dụng chứ không phải các ứng dụng khác, do đó cần phải tính đến; 3) người dùng cần có thể truy xuất các quyền cụ thể cho từng ứng dụng.

Tôi đã thực hiện một cái gì đó, nhưng tôi không hài lòng 100% với nó. Ngay bây giờ, đây là những gì tôi có: 1) ứng dụng web kiểm tra sự tồn tại của phiên (cụ thể cho ứng dụng) và cookie là mã thông báo JWT được gửi từ hệ thống xác thực tập trung; 2) nếu cookie không tồn tại, tôi chuyển hướng đến trang đăng nhập trên hệ thống xác thực; 3) khi người dùng đăng nhập, họ được chuyển hướng đến ứng dụng của họ chuyển qua mã thông báo JWT; 4) ứng dụng xác minh mã thông báo qua lệnh gọi API REST đến hệ thống xác thực (làm cho các lệnh gọi API REST này dựa trên mã thông báo truy cập riêng), nếu nó hợp lệ, thì mã thông báo JWT sẽ được lưu dưới dạng cookie và phiên được bắt đầu bằng người dùng đăng nhập; 5) nếu phiên ứng dụng hết hạn, nó sẽ kiểm tra xem cookie có tồn tại không và nếu có thì ứng dụng sẽ thực hiện giống như bước # 4, xác minh mã thông báo và tạo lại phiên; 6) khi đăng xuất, hệ thống chỉ cần xóa cookie, đảm bảo người dùng đăng xuất khỏi tất cả các ứng dụng; 7) nếu mã thông báo hết hạn, ứng dụng sẽ sử dụng mã thông báo đã hết hạn để yêu cầu mã mới, trong đó chữ ký mã thông báo và các khiếu nại khác được xác thực trước khi phát hành mã mới, điều duy nhất không được xác thực là yêu cầu hết hạn.

Để làm rõ, sự tồn tại của một phiên cụ thể cho ứng dụng được sử dụng để bạn không phải liên tục thực hiện các cuộc gọi API REST để xác minh mã thông báo. Nhưng do mã thông báo đã được xác minh một lần, liệu có an toàn không khi chỉ sử dụng cookie đó làm chỉ báo có phiên hợp lệ?

Một điều mà tôi không chắc chắn là mã thông báo của tôi cần phải có thứ gì đó cho biết ứng dụng đó là gì vì các lệnh gọi API REST khác có thể được thực hiện bằng cách sử dụng mã thông báo để nhận một số tài nguyên dành riêng cho ứng dụng. Nhưng nếu tôi nhận được mã thông báo cho app1 và sau đó đăng nhập vào app2, app2 sẽ dựa vào cookie được tạo bởi app2. Vì vậy, có vẻ như tôi muốn có hai mã thông báo, một mã có thể được lưu trữ dưới dạng cookie miền để cho biết người dùng được xác thực và một mã khác thực sự là ứng dụng cụ thể và có thể được sử dụng để thực hiện các lệnh gọi API REST cho ứng dụng khác- nguồn lực cụ thể.

Tôi có quá phức tạp điều này không, hay dòng suy nghĩ của tôi có khớp với những gì người khác đang nhìn thấy / đang làm ngoài kia không? Hoặc có một cách thanh lịch hơn để làm điều này? Tôi đã nghĩ đến việc triển khai một cái gì đó như Open ID, nhưng có vẻ hơi quá mức cho nhu cầu của chúng tôi. Tôi muốn điều này đơn giản đến mức có thể để tôi có thể ghi lại quá trình và các nhóm nhà phát triển khác có thể phát triển các ứng dụng cắm vào hệ thống xác thực mà không cần quá nhiều trợ giúp.

Câu trả lời:


5

Đừng có điên Không ai trong tâm trí của họ sẽ cố gắng viết một cái gì đó như thế này từ đầu. Sử dụng OAuth. Bạn có thể sử dụng thông số mã thông báo JWT Bearer cho mã thông báo và sử dụng phạm vi để xác định ứng dụng hoặc tài nguyên nào mà người dùng có quyền truy cập. Đây không phải là một khu vực tốt để bắt đầu phát minh lại bánh xe!


0

Gần đây tôi chỉ làm theo một hướng dẫn ở đây giải thích quá trình thiết lập để xác thực dựa trên mã thông báo. Một cách mà tôi có thể tưởng tượng thông qua một số hình thức nhận dạng cụ thể của ứng dụng sẽ là sử dụng khiếu nại.

Vì vậy, bạn có trang web A chuyển hướng bạn đến trang hệ thống đăng nhập của bạn. Trang web A cũng được chuyển vào một số dữ liệu khác như nơi đưa người dùng sau khi đăng nhập và trang web A ở đâu. Hệ thống xác thực của bạn xem xét dữ liệu này và sử dụng một chuyển đổi của một số hình thức bạn nối thêm khiếu nại với mã thông báo người dùng xác định phạm vi ứng dụng hiện tại của họ.

Ngoài ra, để giúp chống lại người dùng chuyển đổi ứng dụng rất nhanh và vẫn có quyền truy cập vào tài nguyên ứng dụng cho app1 trong khi trên app2, access_tokens của bạn hết hạn rất nhanh. Trong trang web demo chạy của tôi được xây dựng bằng hướng dẫn trên của tôi hết hạn mỗi phút, cũng như việc thực hiện refresh_token giúp mọi thứ dễ dàng hơn. Một bước khác có thể hữu ích là trong khi nối thêm khiếu nại cho người dùng cũng sẽ thêm vai trò cho người dùng đó nêu họ đang ở trên một trang web.

Sau đó, trên app1 ' thực hiện kiểm tra logic cho các lỗi như không truy cập vào điểm cuối cụ thể và có thể người dùng cần nhận access_token mới bằng cách sử dụng mã thông báo làm mới, v.v.

Sử dụng cùng một hướng dẫn mà tôi đã liệt kê ở trên, theo liên kết đó và tìm kiếm này:

var nhận dạng = ClaimsIdentity mới (bối cảnh.Options.AuthenticationType);

Như bạn có thể thấy danh tính đang thêm các khiếu nại, về cơ bản chỉ là các giá trị sẽ được gói gọn trong access_token.

Bây giờ khi người dùng gọi vào api web của bạn có thuộc tính được ủy quyền ở trên, bạn chỉ cần kiểm tra xem người dùng có yêu cầu gì không.

Một ví dụ về điều này có thể được tìm thấy ở đây .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.