7

Điều này có vẻ là một vấn đề tái diễn cho tôi khi tôi dường như bị hấp dẫn xung quanh các ứng dụng di động trong vài năm qua. Tôi muốn xác thực và ủy quyền cho người dùng thiết bị di động ngoài người dùng web. Tôi cần phải làm cho điều này đủ liền mạch để người dùng có thể dễ dàng có tài khoản web mà không gây gián đoạn cho dữ liệu của họ. Tôi muốn giải pháp là kiến ​​trúc trong chủ đề, không cụ thể cho bất kỳ ngôn ngữ/khuôn khổ nào.Kiến trúc để xác thực/ủy quyền của người dùng di động và web

Yêu cầu/Giả định

  1. Người dùng di động phải có khả năng sử dụng các ứng dụng bản địa mà không cần đăng nhập, trong đó có đóng góp nội dung (đánh dấu yêu thích, tải lên hình ảnh, vv).
  2. Người dùng thiết bị di động phải được xác thực an toàn và duy nhất cho dịch vụ web ngay cả khi không chỉ định thông tin đăng nhập tài khoản.
  3. Người dùng thiết bị di động có thể có nhiều thiết bị sẽ không biết lẫn nhau.
  4. Người dùng thiết bị di động sẽ có thể Đăng ký/Đăng nhập, sẽ cuộn vào bất kỳ nội dung nào trong quyền sở hữu của tài khoản. Điều này "đồng bộ hóa" nên xảy ra với mỗi tài khoản mà sau đó đăng nhập.
  5. Nó không quan trọng cho dù một tài khoản được tạo ra trên điện thoại di động hoặc web.

Kiến trúc coi

  1. NO SHIRT, NO GIÀY, NO LOGIN = không có đóng góp. Yêu cầu đăng nhập để đóng góp nội dung dưới bất kỳ hình thức nào. Điều này ngăn không cho "đồng bộ hóa" tài khoản thiết bị với tài khoản chính. Chỉ cần yêu cầu một tên người dùng/mật khẩu + mã thông báo để thiết bị đăng nhập. Đối tượng máy chủ: Người dùng, Vai trò
  2. Tự xác thực nhiều thiết bị. Máy chủ thương lượng với thiết bị và trao bằng chứng xác thực mà thiết bị lưu trữ. Mỗi thiết bị tự xác thực và được liên kết với một tài khoản ẩn danh cho đến khi Đăng ký/Đăng nhập diễn ra. Nếu Đăng ký xảy ra, tài khoản ẩn danh sẽ được chuyển thành tài khoản đã biết. Nếu Đăng nhập xảy ra, nội dung từ tài khoản ẩn danh được chuyển sang tài khoản đã biết và sau đó bị vứt bỏ. Các thiết bị mất chi tiết tự xác thực sẽ nhận được chi tiết xác thực mới và tài khoản ẩn danh trước đó bị hủy (và sau đó hy vọng sẽ bị vứt bỏ) và không thể khôi phục vì nó chưa bao giờ được chuyển đổi thành tài khoản đã biết. Đối tượng máy chủ: Người dùng, Vai trò, Thiết bị

Bạn nghĩ gì là giải pháp tốt? Một trong số đó, hoặc cái gì khác?

Trả lời

0

Số 2 đủ tốt làm quyết định cơ bản. Người dùng ghét đăng ký;) Vì vậy, khả năng sử dụng dịch vụ mà không cần đăng ký là ý tưởng hay.

Bạn có thể sử dụng GUID/UUID để xác định. Và sử dụng nó như là đăng nhập vô danh trước khi đăng nhập người dùng.

Nhưng phải làm gì nếu 2 (hoặc nhiều hơn) người sử dụng 1 thiết bị? Hoặc thiết bị sẽ được losed, bị đánh cắp? Tôi nghĩ rằng không có một trong những điểm bao gồm những trường hợp này.

Tôi không biết bạn có kiến ​​trúc sư dịch vụ web nào để không thể tư vấn thêm.

2

Tôi muốn đề xuất một ý tưởng tương tự như 2.

Tạo UUID cho mỗi thiết bị di động. Nó sẽ phục vụ để xác định thiết bị trên các lần xuất hiện sau này khi người dùng tạo nội dung và nội dung được gửi đến máy chủ.

Nếu, bất cứ lúc nào sau đó, người dùng muốn tạo tài khoản web, anh ấy có thể đăng ký trên web hoặc trên thiết bị. Nếu người dùng đã sở hữu tài khoản web, anh ấy có thể chọn cung cấp bằng chứng xác thực hiện có trên thiết bị di động của mình một lần (hoặc thiết bị) và thiết bị được liên kết với tài khoản web của anh ấy ở phía máy chủ. Về phía máy chủ, tôi sẽ cho phép hai loại thực thể khác nhau phục vụ như danh tính: Người dùng Web được xác thực bằng thông tin đăng nhập (OpenID đến với tôi như là một bổ sung) và thiết bị được xác thực bởi GUID của họ mà không có sự can thiệp của người dùng. Đương nhiên, một thực thể người dùng web có thể sở hữu một số thực thể thiết bị. Một thực thể thiết bị được liên kết với một tài khoản khi người dùng chọn liên kết thiết bị của mình với một tài khoản hiện có. Nội dung thường được liên kết với danh tính.

Mối liên hệ giữa người dùng và thiết bị được lưu giữ và cũng có thể được sử dụng để hiển thị nguồn gốc của nội dung.

Bạn sẽ không cần phải tạo/thả/chuyển đổi tài khoản với thông tin đăng nhập được tạo cho người dùng thiết bị di động. Bạn cũng sẽ không cần lưu trữ thông tin xác thực trên thiết bị di động.

Vẫn còn một số cân nhắc bảo mật còn mở, tùy thuộc vào mức độ nghiêm trọng của ngữ cảnh ứng dụng của bạn. Không có bất kỳ biện pháp an ninh nào, kẻ tấn công sẽ dễ dàng lạm dụng UUID.

2

Tôi nghĩ rằng điều này đang được xem xét theo hướng sai. Xác định danh tính trên máy chủ như được xác định bằng giá trị tùy ý. Có lẽ chỉ là một chuỗi DB. Liên kết mọi thông tin nhân khẩu học (tên, email ...) và lịch sử sử dụng với danh tính này.

Tách riêng, xác định thực thể xác thực trên máy chủ. Đây có thể là người dùng/mật khẩu. Nó có thể là một thiết bị GUID/UUID. Nó có thể là một ID được liên kết như OpenID. Danh tính nhất định có thể có (và thường sẽ trong trường hợp sử dụng của bạn) nhiều thực thể xác thực được liên kết. Rất có thể nhiều xác thực danh tính của cùng một loại. (ví dụ: GUID cho điện thoại thông minh, GUID cho iPad của tôi ...)

Giao diện người dùng của bạn (cho dù trên web hoặc ứng dụng), sử dụng API được xác định để xác thực người dùng; sử dụng bất kỳ cơ chế nào mà giao diện người dùng hỗ trợ.

Trong một số trường hợp (đặc biệt là ứng dụng gốc), bản trình bày một ID không xác định sẽ kích hoạt việc tạo danh tính mới. Tuy nhiên, như một người nào đó đã chỉ ra, trong tình huống này, bạn nên hỏi người dùng xem họ có muốn kết nối với danh tính hiện có hay không. Họ cần cung cấp xác thực là nhận dạng đó (một lần) để thiết lập kết nối đó.

Một điểm khác, bất kể máy chủ nào sử dụng để chỉ định duy nhất danh tính phải là giá trị không bao giờ là được cung cấp cho khách hàng. Khách hàng chỉ biết về cơ chế xác thực và dữ liệu của nó. Đó là, GUID/UUID, tên người dùng/mật khẩu, ...

Ngoài các kỹ thuật được liệt kê ở trên, điều gì đó giống như OAuth an toàn hơn GUID được tạo cục bộ. Đó là một trong một: dễ dàng xác định hoặc b: dễ bị mất. Nếu giá trị có thể dự đoán cao (nói số điện thoại #), nó dễ bị giả mạo. Nếu nó được tạo ra trong thời gian chạy và bao gồm một giá trị khó dự đoán như băm của thời điểm hiện tại khi nó được tạo lần đầu tiên, thì nó phải được lưu trữ trên thiết bị và có thể dễ dàng bị mất nếu thiết bị bị xóa. GUIDs tốt có thể được tạo ra, nhưng chúng thường rất cụ thể về loại thiết bị. Những thứ như số sê-ri thiết bị được lấy từ ROM, IMEI, ... Điều này có thể thực hiện được.Nhưng, phụ thuộc vào thiết bị cụ thể hơn rất nhiều so với khả năng tôi cảm thấy thoải mái.

Rào cản thực sự lớn nhất tôi thấy trong cách tiếp cận này là sẽ khó xử khi cho phép người dùng chỉ có thiết bị (không có tên người dùng/mật khẩu) ngồi xuống trình duyệt PC và kết nối với tài khoản hiện có của mình.

+0

Tôi thực sự thích dòng suy nghĩ của bạn. Tôi không chắc chắn nó thực sự minh họa các kỹ thuật phổ biến để tiếp cận vấn đề cụ thể này, nhưng tôi rất đánh giá cao phản ứng của bạn. (Lưu ý rằng tôi đã đọc phản hồi này vào năm 2010, nhưng tôi cảm thấy bắt buộc phải cho bạn biết bây giờ rằng nó đã được đánh giá cao và hữu ích) –

-3

Một giải pháp là với sinh trắc học. Nếu thiết bị di động có cảm biến sinh trắc học, chẳng hạn như đầu đọc vân tay, người dùng sẽ đăng ký sinh trắc học với thiết bị (chỉ do các vấn đề về quyền riêng tư) tại thời điểm mua. Các ứng dụng có thể được viết sao cho mọi giao dịch an toàn yêu cầu người dùng xác thực sinh trắc học.

Điều này có vẻ không quá xa. Motorola Atrix có cảm biến vân tay ...

+0

Phản hồi này không thực sự giải quyết bài đăng như đã được trình bày. Chắc chắn sinh trắc học có thể giúp xác định người dùng, nhưng việc kết nối thiết bị đó và xác thực người dùng với một chương trình phụ trợ vẫn sẽ yêu cầu một số cân nhắc thiết kế. Tôi vẫn chưa đi qua một giải pháp hoàn hảo. –

Các vấn đề liên quan