all*_*tar 7 openid oauth oauth-2.0 openid-connect
我现在已经阅读了很多不同的文章,但我仍然不清楚OpenID Connect在OAuth 2.0之上提供的主要价值.
我的理解:
当通过OAuth 2.0流接收访问令牌时,客户端确实知道授权服务器已对用户进行了身份验证.似乎OpenID Connect只是添加带有用户信息的ID令牌 - 但该信息可以是访问令牌的一部分,也可以通过受保护资源(如单独的userDetails资源)获得.这似乎不足以证明OpenID Connect的创建,所以我确信我错过了一些东西......
谢谢你的帮助!
添加更多详细信息,以便评论.非常感谢你的帮助.
由于你的回答,我想我越来越近了.所以我回顾了这篇文章:http://oauth.net/articles/authentication/.它说"OAuth对用户一无所知".但是,在发出访问令牌之前,您信任相同的服务来验证最终用户.在"常见陷阱部分"中,本文讨论了为什么不能使用访问令牌进行身份验证.根据我的理解,我有以下问题:
访问令牌作为身份验证 的证据访问令牌是先前某点的身份验证证明.如果客户端确实想在获取访问令牌后的某个时刻对用户进行身份验证,为什么不重复现有的Oauth流,当前最终用户尝试访问客户端？
作为证据访问受保护资源 与上述相同 - 如果客户端需要在任何时候进行身份验证,请重复Oauth流.
注入访问令牌 不清楚OpenID如何帮助这一点
缺乏受众限制 为什么向天真的客户端提供有效的ID令牌以及访问令牌更加困难？这与服务器端流程有关吗？同样,如果需要,可以重复OAuth流程.
注入无效的用户信息 这似乎需要签名,而不是单独的令牌.如果OAuth流程通过HTTPS进行,是否为身份提供商添加任何安全性以对用户详细信息签署两次？
每个潜在身份提供者的不同协议 这似乎是公平的,但如果唯一的目的是用于用户信息的令牌的标准化,它似乎仍然很奇怪.
OAuth 访问令牌对客户端来说是不透明的，并且可以由任何人提供，这意味着它不一定由登录用户交给客户端。攻击者可以向客户端提供从其自己的（不一定是恶意的）服务中的不同用户获得的访问令牌。来自 OpenID Connect 的 ID 令牌可确保用户最近在 OP 上登录，并提供可由客户端验证的有关该用户的信息。此外，ID 令牌专门针对您的客户。
http://oauth.net/articles/authentication/中很好地描述了这些差异
| 归档时间： |
|
| 查看次数： |
566 次 |
| 最近记录： |