如果我正确地解释了你的问题,你正在寻找这样的东西:
- 用户启动您的浏览器应用程序或您的本机应用程序(可能是移动应用程序)
- 由于用户还没有帐户,因此您向他们提供适当的对话框以创建所述帐户。
- 然后,您要求“身份服务”为该用户创建配置文件
- 身份服务返回访问令牌
这是我们在移动网络行业一直在做的事情。从技术上讲,我们有 TAC/ACS 或 HSS 配置文件服务,但在任何一种情况下,它都是一样的——专用服务和网络进程:
- 接受来自各种客户端(网络、移动、桌面...)的连接
- 沿数据库 CRUD(创建、读取、更新、删除)模型具有各种原语
- Answers 请求数据库
如果您想要一个预配置的解决方案,您可以使用任何带有 REST 样式连接器的网络数据库(例如可能是 MongoDB?),但您也可以在与 NoSQL 或 SQLLite 数据库对话的过程中通过它。最终结果是一样的。
对于商业解决方案,我可能会喜欢 OpenStack,因为您可以在其上运行您的代码,并且他们有身份代理,您可能可以 CoOpt。
就个人而言,我只需要在 Amazon 的 EC2 之类的云上运行一个数据存储,它可以回答 RESTful 请求,例如:
- 创建具有给定配置文件集的用户,返回唯一令牌
- 删除给定令牌的用户
- 更新给定令牌的配置文件元素
我在这里省略了安全等必要的事情,但你明白了。
这还有一个优势,即您可以为所有应用程序/应用程序服务提供单一身份服务。给定应用程序元素的细节只是配置文件中的子字段。这不仅为您提供了适用于 Web、桌面和移动设备的通用身份代理,还为您的所有应用程序提供了单点登录。用户只需登录一次,就可以对您拥有的所有内容进行身份验证。从一个站点移动到另一个站点,现在变得无缝了。
最后,您将身份管理、备份、安全令牌管理等置于应用程序之外。如果您以后想要添加 Google Authenticator 以进行第二因素身份验证,则不必将其添加到您拥有的每个应用程序中。
我还应该补充一点,您不想将身份数据库保留在直接的 Internet 连接点上。有人可能会让你的生活变得困难,然后再坚持下去。相反,您希望您的身份服务器具有到它的专用链接。然后做这样的事情:
- 创建帐户时,不要存储密码,存储哈希值——更安全
- 让您的应用程序(网络或其他)计算一个密钥作为登录
在这种情况下,用户可能会输入用户名和密码,但应用程序或网站会将其转换为令牌。这就是您发送的内容。
- 接下来,使用该令牌(和适当的安全魔法),将其用作所有者密钥
- 将该密钥发送到数据存储并检索任何需要的值
- 使用令牌将它们加密回 blob
- 发送块
- 应用程序解密 blob 以获取值
我们为什么要做这个?
首先,如果有人试图访问您的身份数据库,那么没有任何用处。它仅包含用于登录的不透明令牌和加密数据块。继续 - 获取数据库。我们不在乎。
其次,嗅探传输使攻击者一无所获——同样,它都是加密的 blob。
这意味着稍后,当您有五个应用程序使用代理,并且有人入侵网络并窃取数据库时,您不在乎,因为您的用户从一开始就从未提供过登录名和密码,即使他们这样做了,对于没有用户密钥的任何人来说,数据本身都是垃圾。
这有帮助吗?