我正在查看 OpenIDConnect 身份验证并尝试确定在身份验证或授权期间是否使用过“简单 CORS”或“复杂 CORS”。
背景
一个简单的 CORS（没有预检）包括：
HTTP方法：
和一个内容类型
将导致Access-Control-Allow-Origin响应中提供的服务器
任何其他 X-header 或 Method 都将导致preflightOPTIONS 请求。
问题
任何形式的 OAuth 是否以使用飞行前请求的方式利用 CORS？（首选 OpenID Connect 信息，但 OAuth 的任何实现都很有趣）
是否有任何形式的 OAuth 利用缺少飞行前请求的 CORS？
哪种 CORS 配置会导致 OAuth 身份提供者或依赖方/资源出现安全漏洞？
我不确定 OpenID，但对于 OAuth，实际身份验证部分不涉及 CORS，尽管根据连接的客户端类型，资源服务器可能需要它。
在定义 OAuth 2 框架的RFC 6749中，为应用程序定义了四种不同的方法来获得授权（这里，客户端是指想要访问数据的服务器，资源所有者和最终用户是指数据的人，谁授予访问权限，主机是指提供授权和 API 端点的实体）：
使用授权码方法时，身份验证流程的高级概述是客户端将用户重定向到主机上的授权页面。当最终用户授予访问权限时，他们将被重定向回客户端的站点。收到请求后，客户端的服务器将向主机发出请求，将临时令牌交换为永久令牌，然后他们使用该永久令牌从服务器发出 API 请求。
使用这种方法，所有请求都是从客户端的服务器向主机服务器发出的，因此不需要 CORS。在最终用户的浏览器中发出的唯一请求是重定向，它们不受 CORS 的影响。
使用隐式方法时，当最终用户在授予访问权限后被重定向时，将通过在客户端网站上的最终用户浏览器中运行的 (javascript) 脚本从 URL 中检索永久代码。然后，在浏览器中运行的 javascript 脚本会使用此代码来访问 API。
CORS 需要用于使用此方法的实际 API 端点（如果请求无论如何都需要 CORS - 使用 OAuth 对其进行身份验证并没有什么特别之处，因此 GET 请求不需要 CORS 但 DELETE 请求需要），因为它们正在从用户的浏览器中访问。但是，身份验证流程不需要 CORS，因为再次使用重定向而不是跨域请求来处理它。