【漏洞挖掘】——144、 逻辑漏洞之OAuth 2.0认证缺陷刨析(下)

OpenID类

基本介绍

OpenID Connect扩展了OAuth协议并提供了一个位于基本OAuth实现之上的专用身份和身份验证层，它添加了一些简单的功能，可以更好地支持OAuth的身份验证用例。OAuth最初的设计并没有考虑到身份验证，它旨在成为在应用程序之间为特定资源委派授权的一种方式，然而许多网站开始自定义OAuth以用作身份验证机制，为了实现这一点他们通常请求对一些基本用户数据的读取访问权限，如果他们被授予此访问权限，则假设用户在OAuth提供程序方面对自己进行了身份验证

简单的OAuth身份验证机制远非理想，首先客户端应用程序无法知道何时、何地或如何对用户进行身份验证，由于这些实现中的每一个都是某种自定义的变通方法，因此也没有为此目的请求用户数据的标准方法，为了正确支持OAuth，客户端应用程序必须为每个提供程序配置单独的OAuth机制，每个提供程序都有不同的端点、唯一的作用域集等等，OpenID Connect通过添加标准化的、与身份相关的功能，使通过OAuth的身份验证以更可靠、更统一的方式工作，从而解决了许多这些问题

角色划分

OpenID Connect的角色与标准OAuth的角色基本相同，主要区别在于规范使用的术语略有不同：

• Relying party(依赖方)—请求对用户进行身份验证的应用程序，这与OAuth客户端应用程序是同义词
• End user(最终的用户)—正在进行身份验证的用户，这与OAuth资源所有者同义
• OpenID provider(OpenID提供程序)-配置为支持OpenID Connect的OAuth服务

作用域类

OpenID Connect与基本OAuth不同，其作用域对每个提供程序都是唯一的，所有OpenID C