Lưu trữ thông tin OpenID cần thiết

Question

Tôi đang cố triển khai xác thực OpenID cho trang web của mình. Đây là kịch bản:
tôi muốn người dùng để có thể

• đăng nhập chỉ sử dụng OpenID (. Người dùng có thể chỉ yêu cầu xác minh bằng cách truy cập cung cấp OpenID không cần phải tạo một tài khoản tùy chỉnh với email mật khẩu),
• Qua email/mật khẩu (người dùng đã đăng ký tại chỗ bằng cách điền vào biểu mẫu)
• Đính kèm (các) id mở vào tài khoản của mình (openids + email cho một tài khoản).

Bây giờ tôi không biết thông tin đăng nhập nào tôi nên lưu trữ cho id mở. và không chắc chắn về lược đồ DB. Dưới đây là giản đồ cơ sở dữ liệu:

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

Bây giờ khi người dùng đăng nhập vào, cho dù bằng cách sử dụng thành viên openid/tùy chỉnh, tôi chỉ cần nhìn vào bảng xác thực và tìm kiếm thông tin và có được người dùng thích hợp. Nếu không có người dùng nào tồn tại, tôi tạo người dùng mới và thêm mục nhập trong bảng xác thực.

• Câu hỏi chính: Sản phẩm lưu trữ Provider và LoginId (xem các ý kiến ​​ở trên để xem những gì đang được lưu trữ trong các lĩnh vực này) đủ để lưu trữ chứng thực openid? Tôi có nên lưu trữ bất kỳ dữ liệu bổ sung nào để khi người dùng trả lại, tôi có thể xác thực họ dựa trên dữ liệu đã lưu của tôi không?

• Bạn có đề xuất phương pháp nào khác (hiệu quả hơn) để thực hiện việc này không?
  Cảm ơn bạn.

Answer 1

Lưu trữ ClaimedIdentifier cho người dùng mở - không phải địa chỉ nhà cung cấp. Mã định danh được xác nhận quyền sở hữu là giao thức OpenID xác minh là duy nhất cho người dùng và cũng có khả năng cung cấp tính di động trên các Nhà cung cấp OpenID. Ngoài ra, bởi vì OpenID 2.0's Claimed Identifiers có thể không được chấp nhận bởi OpenID Connect (người kế nhiệm chưa hoàn thành OpenID 2.0), bạn cũng có thể quan tâm tốt nhất để ghi lại Url điểm cuối nhà cung cấp OpenID và địa chỉ email được xác nhận bởi Nhà cung cấp trong hồ sơ người dùng. Hiện tại, hãy làm không sử dụng chúng như một phần trong quy trình xác thực của bạn, nhưng bằng cách ghi lại chúng, bạn sẽ có thể xác định địa chỉ email nào bạn tin cậy sau này (ví dụ: giả sử bạn quyết định địa chỉ email được Google xác nhận là đáng tin cậy) cho phép người dùng di chuyển tài khoản của họ sang một tài khoản OpenID Connect bằng địa chỉ email đã được xác minh đó. Điều này cũng sẽ giảm thiểu sự nguy hiểm của trang web của bạn (thường là http://yourdomainname.com) thay đổi và khiến tất cả người dùng Google xác nhận quyền sở hữu của bạn thay đổi, điều này chỉ thực sự có thể được khôi phục từ địa chỉ email của họ, một cách bi thảm.

Tôi cũng khuyên bạn nên sử dụng các bảng khác nhau cho các loại xác thực khác nhau. Có một vài lợi thế ở đây. Điều quan trọng nhất là về mặt kiến ​​trúc nó làm cho việc giới thiệu lỗ hổng bảo mật vào trang web của bạn khó khăn hơn có thể cho phép ai đó nhập vào (ví dụ) một OpenID vào trường tên người dùng và mật khẩu trống và hiển thị nó dưới dạng kết hợp cơ sở dữ liệu và đăng nhập mà không có bất kỳ xác thực thực nào xảy ra. Thứ hai, nó cung cấp một mô hình linh hoạt hơn trong trường hợp bạn muốn thêm một cơ chế xác thực thứ ba thay vì làm cho bảng 'Xác thực' của bạn phát triển theo chiều ngang cho tất cả người dùng. Ví dụ: OAuth 2.0 và "OpenID Connect" có thể giới thiệu các loại xác thực mới cho trang web của bạn khi bạn thêm hỗ trợ cho chúng qua nhiều năm và thêm các bảng mới để xử lý các loại dữ liệu mới có vẻ phù hợp hơn.

Answer 2

Chúng tôi chỉ lưu trữ URL xác nhận quyền sở hữu mở. Bạn có thể muốn yêu cầu thông tin bổ sung từ nhà cung cấp như tên người dùng. Điều quan trọng nhất là tách biệt tư cách thành viên và xác thực.

schema của chúng tôi là

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId chỉ đơn giản là một tài sản chuỗi cửa hàng hoặc người sử dụng tên truy cập nội bộ hoặc url tuyên bố OpenID của họ, tùy thuộc vào cách họ đã đăng ký.

Khi xác thực thành công (sử dụng tên người dùng/mật khẩu nội bộ hoặc nhà cung cấp bên ngoài), chúng tôi chỉ đặt cookie xác thực của họ bằng tên người dùng nội bộ hoặc url xác nhận quyền sở hữu của họ. Lấy hồ sơ của người dùng sau đó chỉ là vấn đề tìm kiếm hồ sơ ở đâu (UserId == User.Identity.Name).

Điều này có lợi thế là người dùng có thể chọn thay đổi cách họ xác thực tại bất kỳ thời điểm nào (có thể chuyển sang tài khoản nội bộ hoặc sử dụng nhà cung cấp khác).