Cách di chuyển ứng dụng web cũ để sử dụng OAuth2


10

Tôi hiện có một ứng dụng web nguyên khối cũ 15 năm với gần 1 triệu người dùng, sử dụng hệ thống xác thực & ủy quyền được trồng tại nhà: JAAS, tên người dùng và pwds lưu trữ trong DB với băm mật khẩu cơ bản, một số câu hỏi xác minh cá nhân 2FA (khác nhau thuật toán băm, vv).

Tôi sẽ đại tu ứng dụng trong vòng 12-18 tháng tới, chủ yếu tập trung vào UI, nhưng cũng từ từ nâng cấp các phần cơ bản (nâng cấp lên Spring, Spring Security, v.v.). Trong dự án này, chúng tôi đã quyết định xử lý nâng cấp giao diện người dùng trên cơ sở từng mô-đun; làm cho mỗi mô-đun có sẵn khi nó hoàn thành; một cơ hội hoàn hảo để phá vỡ khối nguyên khối thành các ứng dụng web riêng lẻ (tất cả đều duy trì cùng một thiết kế UX).

Nơi tôi đang bị mắc kẹt khi cố gắng lên kế hoạch này là ở cấp độ xác thực và ủy quyền. Tôi cần một giải pháp xuyên suốt sẽ xoay quanh tất cả các mô-đun, để khi người dùng được chuyển hướng từ ứng dụng web này sang ứng dụng web khác, đó là một quá trình chuyển đổi liền mạch - họ thậm chí sẽ không biết họ đang ở trên các ứng dụng web khác nhau. OAuth2 nghe có vẻ là giải pháp hoàn hảo.

Tôi đang cố gắng để hiểu làm thế nào để tích hợp này. Tôi có phải xây dựng máy chủ OAuth2 tùy chỉnh của riêng mình không? Điều đó đánh tôi như một ý tưởng khủng khiếp. Nhưng làm thế nào để tôi:

  1. di chuyển tất cả tài khoản người dùng và quy trình ủy quyền của tôi sang máy chủ OAuth2 của bên thứ 3
  2. tùy chỉnh giao diện để phù hợp với phần còn lại của ứng dụng của tôi (không chắc điều này sẽ dễ dàng / có khả năng như thế nào)
  3. ngăn cửa sổ bật lên "Ứng dụng XYZ muốn cấp quyền truy cập vào tài khoản của bạn ..." khi kết nối qua máy chủ của bên thứ 3? (ví dụ: Google OpenID, Facebook, v.v.).

Mục tiêu của tôi là cung cấp một sự chuyển tiếp liền mạch cho người dùng từ trạng thái hiện tại sang trạng thái mới, nhưng cung cấp khả năng tạo các ứng dụng web riêng biệt mà tất cả xác thực & ủy quyền bên ngoài ứng dụng web.


Tôi tự hỏi nếu một SSO sẽ là đủ. OAuth dường như không phải là loại hệ thống bạn cần ở đây. Hãy xem CAS
Laiv

Câu trả lời:


2

Tiết lộ : Tôi là một kỹ sư tại Auth0 .

Nó phụ thuộc vào một điểm chính ... bạn cần quyết định xem:

  1. bạn muốn trực tiếp dành một lượng thời gian đáng kể (và gián tiếp chi tiền) để xây dựng và / hoặc duy trì nhà cung cấp nhận dạng và máy chủ ủy quyền của riêng bạn
  2. hoặc bạn muốn chi tiền trực tiếp và sử dụng nhà cung cấp xác thực của bên thứ ba như Auth0.

Cả hai tùy chọn đều hoàn toàn khả thi theo quan điểm của các yêu cầu chức năng của bạn. Với sự phát triển tùy chỉnh, bạn có toàn quyền kiểm soát chức năng mà bạn quyết định hỗ trợ, vì vậy tôi sẽ tập trung một phần câu trả lời vào cách Auth0 có thể đáp ứng các yêu cầu bạn đã liệt kê .

Tuy nhiên, trước khi chuyển sang vấn đề đó, bất kể quyết định của bạn là gì, để xác thực, bạn nên tập trung vào OpenID Connect thay vì OAuth2. Cái sau sẽ được áp dụng nhiều hơn nếu bạn dự định cũng có API trong hỗn hợp và không chỉ tách khối nguyên khối thành các ứng dụng web riêng biệt.


Làm cách nào để di chuyển người dùng hiện tại sang hệ thống dựa trên Auth0?

Bạn có thể quyết định tiếp tục sử dụng cơ sở dữ liệu của mình và dựa vào Auth0 để cung cấp tất cả việc tuân thủ các giao thức liên quan đến xác thực mà bạn có thể cần sử dụng hoặc bạn có thể di chuyển người dùng của mình sang cơ sở dữ liệu được quản lý Auth0 và ngừng lo lắng về cách bạn lưu trữ và xác thực mật khẩu.

Nếu bạn muốn tiếp tục sử dụng cơ sở dữ liệu của mình, hãy xem Xác thực người dùng bằng tên người dùng và mật khẩu bằng cơ sở dữ liệu tùy chỉnh

Các ứng dụng thường dựa vào cơ sở dữ liệu người dùng để xác thực. Auth0 cho phép bạn dễ dàng kết nối với các kho lưu trữ này và sử dụng chúng làm nhà cung cấp nhận dạng trong khi vẫn giữ thông tin đăng nhập của người dùng và cung cấp nhiều tính năng bổ sung.

(Các tài liệu đề cập đến MySQL như một ví dụ, các công cụ cơ sở dữ liệu khác được hỗ trợ)

Mặt khác, bạn có thể di chuyển liền mạch thông tin đăng nhập của người dùng vào cơ sở dữ liệu Auth0 bằng cách tận dụng quy trình di chuyển được mô tả trong Di chuyển người dùng sang Auth0

Auth0 hỗ trợ tự động di chuyển người dùng sang Auth0 từ kết nối cơ sở dữ liệu tùy chỉnh. Tính năng này thêm người dùng của bạn vào cơ sở dữ liệu Auth0 cùng một lúc vì mỗi lần đăng nhập và tránh yêu cầu người dùng của bạn đặt lại tất cả mật khẩu của họ cùng một lúc.

Bạn cũng có thể tạo tất cả người dùng của mình trong Auth0 thông qua API quản lý nếu bạn muốn tất cả họ bắt đầu sử dụng thuật toán băm mật khẩu của chúng tôi cùng một lúc. Điều này có tác dụng phụ là yêu cầu người dùng đặt lại mật khẩu của họ.

Làm cách nào để tiếp tục sử dụng xác thực hai bước tùy chỉnh (câu hỏi xác minh)?

Đường ống xác thực được cung cấp bởi Auth0 hoàn toàn có thể tùy chỉnh thông qua việc sử dụng các quy tắc . Điều này có nghĩa là mặc dù bạn không phải thực hiện bất kỳ nội dung nào liên quan đến giao thức, bạn vẫn có thể tinh chỉnh các chi tiết nhỏ về cách xác thực xảy ra trong ứng dụng của mình.

Điều này bao gồm khả năng tiếp tục sử dụng các câu hỏi xác minh hiện có của bạn như một cách để thực hiện quy trình xác thực hai bước trong đó người dùng cung cấp mật khẩu ban đầu được xác minh bởi Auth0 và sau đó bạn hỏi họ để biết thêm thông tin từ quy tắc tùy chỉnh. (quy tắc chỉ là Javascript nên khả năng là vô hạn)

Tuy nhiên, bạn cũng có thể quyết định bỏ các câu hỏi xác minh và thay vào đó hãy đi với Auth0 Guardian như một cách để tăng tính bảo mật của quy trình xác thực.

Làm cách nào để tùy chỉnh giao diện của giao diện người dùng xác thực?

Với Auth0, bạn có thể có giao diện người dùng xác thực sạch ngay lập tức bằng cách tận dụng các trang đăng nhập mặc định hoặc các tiện ích xác thực như Khóa . Tất cả những điều này hỗ trợ một số mức độ tùy chỉnh và bạn luôn có thể tự quyết định tự làm UI của mình và thay vào đó tận dụng các thư viện Auth0 cấp thấp hơn ( Auth0.js ) không gây ra ràng buộc nào trên giao diện người dùng.

Để biết thêm thông tin về tùy biến:

Làm thế nào để ngăn chặn các trang đồng ý rõ ràng?

Bạn có thể sử dụng Auth0 cả với tư cách là nhà cung cấp nhận dạng cho mục đích xác thực và cũng như máy chủ ủy quyền OAuth2 (hiện chỉ khả dụng ở khu vực Hoa Kỳ) cho API của bạn.

Là nhà cung cấp nhận dạng, bạn không phải lo lắng về các trang đồng ý, người dùng xác thực bằng thông tin đăng nhập của họ được quản lý bởi Auth0 và sau đó được chuyển hướng đến ứng dụng của bạn - đó là điều đó.

Trong OAuth2 dưới dạng kịch bản dịch vụ khi bật đồng ý, bản đồ đường bộ bao gồm cho phép bỏ qua các trang đồng ý cho một số ứng dụng nhất định.


Trong một lưu ý cuối cùng, đó có vẻ như là một dự án rất thú vị và đầy thách thức mà bạn đã đạt được, vì vậy, may mắn nhất là độc lập với quyết định cuối cùng của bạn.

Tôi đã trải qua một cái gì đó tương tự trong một công việc trước đây khi tôi phải triển khai lại hệ thống xác thực của một ứng dụng cũ. Chúng tôi đã triển khai nhà cung cấp nhận dạng và máy chủ ủy quyền của riêng mình và thành thật mà nói tôi vẫn có cảm giác rằng chúng tôi có thể đã quên một cái gì đó thực sự cần thiết.

Tôi nghĩ đó là vấn đề lớn nhất với việc bảo mật của chính bạn, sẽ có những thời hạn áp đặt các phím tắt và bảo mật không thực sự là một lĩnh vực tốt để tạo các phím tắt.

Nếu bạn có thêm câu hỏi hãy cho tôi biết nếu bạn nghĩ tôi có thể hữu ích.


Cảm ơn tất cả các chi tiết. Tôi nhớ là đã nhìn vào Auth0, nhưng từ những gì tôi có thể nói, Auth0 chỉ ở trên đám mây; đúng không? Vì lý do bảo mật và quyền riêng tư, tôi bị hạn chế chỉ xem xét các giải pháp mà tôi có thể lưu trữ trong trung tâm dữ liệu / đám mây cá nhân của riêng tôi. Auth0 có cung cấp loại tùy chọn đó không?
Eric B.

Có, Auth0 rất linh hoạt về mặt triển khai / lưu trữ. Giải pháp đám mây ngoài công cộng hiện được gọi là Công cụ Auth0 và bạn có thể triển khai nó trong một khu vực dành riêng cho đám mây của Auth0, đám mây của bạn hoặc trung tâm dữ liệu của riêng bạn . Kiểm tra tài liệu Công cụ để biết thêm thông tin. Nếu bạn cần thông tin chi tiết hơn hãy cho tôi biết, tôi có thể cố gắng giúp bạn trực tiếp hoặc chỉ cho bạn đúng người.
João Angelo
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.