移动和 Web 用户身份验证/授权的架构
这对我来说似乎是一个反复出现的问题，因为过去几年我似乎更倾向于移动应用程序。除了 Web 用户之外，我还想对移动用户进行身份验证和授权。我需要让这一切变得足够无缝，以便用户可以轻松拥有网络帐户，而不会造成数据中断。我希望解决方案是主题架构的，而不是特定于任何语言/框架的。
要求/假设
- 移动用户必须能够在无需登录的情况下使用本机应用程序，包括贡献内容（标记收藏夹、上传照片等）。
- 即使没有指定帐户凭据，移动用户也应该安全且唯一地对 Web 服务进行身份验证。
- 移动用户可能拥有多个设备，这些设备彼此不知道。
- 移动用户应该能够注册/登录，这应该将任何内容转入帐户的所有权中。这种“同步”应该发生在随后登录的每个帐户上。
- 无论帐户是在移动设备还是网络上创建的，都应该无关紧要。
考虑的架构
- 没有衬衫，没有鞋子，没有登录=没有贡献。需要登录才能贡献任何类型的内容。这样就无需将设备帐户与主帐户“同步”。只需一个用户名/密码 + 令牌即可让设备登录。服务器对象：用户、角色
- 多设备自我身份验证。服务器与设备协商并向其传递设备存储的凭据。每个设备都会进行自我验证并与匿名帐户关联，直到发生注册/登录。如果注册发生，匿名帐户将转换为已知帐户。如果发生登录，来自匿名帐户的内容将被移至已知帐户，然后被丢弃。丢失自我身份验证详细信息的设备将获得新的身份验证详细信息，并且先前的匿名帐户将被放弃（然后希望稍后被丢弃）并且不可恢复，因为它从未转换为已知帐户。服务器对象：用户、角色、设备
您认为什么是好的解决方案？其中之一，还是其他？
This seems to be a reoccurring problem for me as I seem to gravitate around mobile applications the last few years. I want to authenticate and authorize mobile users in addition to web users. I need to make this seamless enough so that users can ease into having a web account without causing interruption to their data. I want the solution to be architectural in topic, not specific to any language/framework.
Requirements/Assumptions
- Mobile users must be able to use the native application without a login, including for contributing content (marking favorites, uploading photos, etc).
- Mobile user should be securely and uniquely authenticating to the web service even without specifying account credentials.
- Mobile user may have multiple devices, which will be unaware of each other.
- Mobile user should be able to Register/Login, which should roll in any content into the account's ownership. This "synchronization" should occur with each account that is subsequently logged in.
- It should not matter whether an account was created on mobile or web.
Architectures Considered
- NO SHIRT, NO SHOES, NO LOGIN = NO CONTRIBUTION. Require login to contribute content of any kind. This prevents the need to "synchronize" device accounts with a master account. Simply require a single username/password + tokens in order for devices to login. Server objects: User, Role
- Multi-device self-authentication. Server negotiates with device and hands it credentials which the device stores. Each device self-authenticates and is associated with an anonymous account until Register/Login occurs. If Register occurs, anonymous account is converted into known account. If Login occurs, content from anonymous account is moved over to known account and then thrown away. Devices that lose the self-authentication details will get new authentication details, and the previous anonymous account is abandoned (and then hopefully later thrown away) and not restorable since it was never converted into a known account. Server objects: User, Role, Device
What do you think is a good solution? One of these, or something else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想提出一个类似于2.
为每个移动设备生成UUID的想法。当用户生成内容并将内容发送到服务器时，它将用于识别设备。
如果用户以后任何时候想要创建网络帐户，他可以在网络上或在设备上注册。如果用户已经拥有网络帐户，他可以选择在他的移动设备（或多个设备）上提供现有凭证一次，并且该设备在服务器端链接到他的网络帐户。
在服务器端，我允许两种不同类型的实体充当身份：通过凭据进行身份验证的 Web 用户（我想到的是 OpenID 作为补充）和通过其 GUID 进行身份验证而无需用户干扰的设备。当然，网络用户实体可以拥有多个设备实体。当用户选择将其设备链接到现有帐户时，设备实体将链接到帐户。内容通常与身份相关联。
用户和设备之间的链接被保留，并且还可以用于显示内容的来源。
您不需要使用为移动用户生成的凭据创建/删除/转换帐户。您也不需要将凭据存储在移动设备上。
仍然存在一些安全考虑因素，具体取决于应用程序上下文的重要性。如果没有任何安全措施，攻击者很容易滥用 UUID。
I would like to propose an idea similar to 2.
Generate an UUID per mobile device. It will serve to identify the device on later occurences when the user generates content and the content is sent to the server.
If, at any time later, the user wants to create an web account, he may register either on the web or on the device. If the user already owns a web account, he may opt to provide the existing credentials on his mobile device once (or devices) and the device is linked to his web account on the server-side.
On the server side, I would allow two different types of entities serving as identities: Web Users which are authenticated by credentials (OpenID comes to my mind as an addition) and devices which are authenticated by their GUID without user interference. Naturally, a web user entity may own several device entities. A device entity is linked to an account when the user opts to link his device to an existing account. Content is generally associated with an identity.
The linkage between user and device is kept and could also be used to display the origination of content.
You would not need to create/drop/convert accounts with generated credentials for mobile users. You would also not need to store the credentials on the mobile device.
There are still some security considerations left open, depending on the criticality of the context of your application. Without any security measures, an attacker would find it easy to abuse the UUID.
我认为这是从错误的方向来看的。将服务器上的身份定义为由任意值定义。可能只是一个数据库序列。将任何人口统计信息（姓名、电子邮件...）和使用历史记录与此身份相关联。
单独在服务器上定义一个身份验证实体。这可以是用户/密码。它可以是设备 GUID/UUID。它可以是像 OpenID 这样的联合 ID。给定的身份可以具有（并且在您的用例中通常会）多个关联的身份验证实体。很可能有多个相同类型的身份验证身份。 （例如，我的智能手机的 GUID、我的 iPad 的 GUID...）
您的前端（无论是基于 Web 还是基于应用程序）使用定义的 API 来验证用户身份；使用前端支持的任何机制。
在某些情况下（特别是本机应用程序），未知 ID 的呈现会触发新身份的创建。但是，正如有人指出的那样，在这种情况下，您应该询问用户是否想要连接到现有身份。他们需要提供身份验证（一次）才能建立该连接。
另一点是，服务器用来唯一指定身份的任何内容都应该是一个永远不会提供给客户端的值。客户端只知道身份验证机制及其数据。也就是说，GUID/UUID、用户名/密码……
除了上面列出的技术之外，OAuth 之类的东西比本地生成的 GUID 更安全。它们是a：容易确定或b：容易丢失之一。如果该值是高度可预测的（例如电话号码），则很容易被欺骗。如果它是在运行时生成的，并且包含一个难以预测的值，例如首次生成时的当前时间的哈希值，那么它必须存储在设备上，并且如果设备被擦除，很容易丢失。可以生成良好的 GUID，但它们通常非常特定于设备类型。从 ROM、IMEI 等检索设备序列号之类的事情很容易实现。但是，它对特定设备的依赖性比我可能会感到舒服的多得多。
我在整个方法中看到的最大的真正障碍是，允许现有的仅设备（无用户名/密码）用户坐在 PC 浏览器前并连接到他现有的帐户会很尴尬。
I think this is being looked at from the wrong direction. Define an identity on the server as being defined by an arbitrary value. Probably just a DB sequence. Associate any demographic information (name, email...) and usage history with this identity.
Separately, define an authentication entity on the server. This could be a user/password. It could be a device GUID/UUID. It could be a federated ID like OpenID. A given identity can have (and often will in your use-case) multiple associated authentication-entities. Very possibly multiple authentication-identities of the same type. (e.g. GUID for my smartphone, GUID for my iPad...)
Your front-ends (whether web or app-based), use a defined API to authenticate a user; using whichever of the mechanisms that front-end supports.
In some cases (particularly the native app), the presentation of an unknown ID triggers the creation of a new identity. However, as someone pointed out, in this situation you should ask the user if they want to connect to an existing identity. They need to provide authentication as that identity (once) in order to establish that connection.
One other point, whatever the server uses to uniquely specify an identity should be a value that is never provided to a client. Clients only know about the authentication mechanism and its data. That is, the GUID/UUID, username/password,...
In addition to the techniques listed above, something like OAuth is more secure than a locally-generated GUID. Those are one of a: easily-determined or b: easily-lost. If the value is highly predictable (say telephone #) it is easily spoofed. If it is generated at runtime and includes a hard-to-predict value like the hash of the current time when it is first generated, then it must be stored on the device and can be easily lost if the device is wiped. Good GUIDs can be generated, but they are often very type-of-device specific. Things like device serial numbers retrieved from ROM, IMEIs,... This is readily doable. But, is a lot more specific-device dependent than I'd likely be comfortable with.
The biggest real hurdle I see in this whole approach is that it will be awkward to allow an existing device-only (no username/password) user to sit down at a PC browser and connect to his existing account.
作为基本决策，2 号已经足够好了。用户讨厌注册；）因此无需注册即可使用服务是个好主意。
您可以使用 GUID/UUID 来识别设备。并在用户登录之前将其用作匿名登录。
但是，如果 2 个（或更多）人使用 1 台设备怎么办？或者设备会丢失、被盗？
我认为没有任何一点涵盖这些情况。
我不知道您构建了哪种 Web 服务，因此无法提供更多建议。
Number 2 is good enough as base decision. Users hate registration ;) So ability to use service without registration is good idea.
You can use GUID/UUID to identify devise. And use it as anonymous login before user login.
But what to do if 2 (or more) people use 1 device? Or device will be losed, stolen?
I think no one of the points cover these cases.
I have no idea what kind of web service you architect so can't advise more.
一种解决方案是使用生物识别技术。如果移动设备具有生物识别传感器，例如指纹读取器，则用户将在购买时在设备上注册生物识别（仅由于隐私问题）。可以编写应用程序，使得每个安全交易都需要用户验证生物特征。
这似乎并不遥远。摩托罗拉 Atrix 配备指纹传感器...
One solution is with a biometric. If the mobile device has biometric sensor, such as a finger print reader, user will enroll biometric with the device (only- due to privacy issues) at the time of purchase. The applications can be written such that every secure transaction requires the user to authenticate the biometric.
This does not seem to be too far off. Motorola Atrix has a fingerprint sensor...