我在论坛上搜索了一些资源:
我在实现基于单点登录/令牌的身份验证过程的想法上蹦蹦跳跳。粗略地说,要求是:
getUserData
)考虑银行或类似Mint.com之类的东西,在初始设置之后,用户可以通过Mint登录一次,然后Mint可以访问您的银行(可能还有多个银行机构) - 从而可以访问不同的系统单点登录。但是,在我的情况下,它不仅仅是Mint.com正在进行的只读访问。
我最初的想法大致如下:
User Sign In ----> System 1, login verification generate token for itself (call it token1)
System 1 ---> generate token and pass it to System 2 (call it token2)
System 1 ---> generate token and pass it to System 3 (call it token3)
System 1 ---> return [token1, token2, token3]
从这里开始,用户(即应用程序或网站等)可以使用3个令牌进行通信。如果用户需要从系统1执行操作/检索数据,它将使用系统2和系统3的请求等传递token1
这种方法有意义吗?
当然存在安全问题 - 如果令牌在途中某处被盗,现在有人使用该令牌可以在令牌系统上执行操作 - 显然,这对于像银行系统这样的事情会很糟糕
系统如何验证提供令牌的请求发件人实际上是为其生成令牌的合法用户?
一个想法是第二个认证级别,即。对于用户提出的每个请求,它需要输入一个特殊代码(例如,像您的银行卡PIN)以与请求中的令牌一起使用 - 但这不会令人烦恼吗?每个请求,用户都必须输入PIN。
非常感谢您的想法和评论。
修改 我已经查看了OAuth ......就我的理解而言,您需要实现一个生成令牌的OAuth提供程序,并允许您将其与OAuth提供程序本身一起使用,换句话说,OAuth提供程序是System#1 - 但是如何让System 2和3也接受OAuth令牌?或者可能是我误解了OAuth。
此外,即使使用OAuth将以我想要的方式工作(系统1,系统2,系统3等),问题仍然存在:如果外部恶意方获得对该令牌的访问权限该怎么办?如何识别以确保使用令牌的人是授权方?
答案 0 :(得分:3)
“这种做法有意义吗?”
如果您正在询问如何在StackOverflow上发明强大的身份验证方案,那么根据定义,您无法发明强大的方案。实际上,我认为该领域的任何一位专家目前都无法做到这一点。
这是你无法重新发明的一个轮子。使用OpenID / OAuth或Kerberos或类似的专家团队分析他们的弱点,你和我都无法理解。