OAuth2.0和OIDC详解

Posted 2023-02-19

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了OAuth2.0和OIDC详解相关的知识，希望对你有一定的参考价值。

参考技术A

OAuth 是一个开放标准的授权框架，它为第三方应用获取资源所有者在资源所在系统或应用上的部分资源提供了一种解决方案。

也就是说，假如你在腾讯云存了一些图片，现在你想在美图秀秀上编辑这些图片；此时的 "你" 就是资源所有者，第三方应用就是美图秀秀，而资源服务器就是腾讯云；

这种情况下美图秀秀直接访问腾讯云是获取不到你的图片的，所以美图秀秀为了能获取到这些照片就需要授权服务器授权（当然，资源服务器和授权服务器有可能是同一个，也有可能是两个不同的服务）

OAuth 就是为这种类似的场景定义的一套标准，目前已经发展到了 OAuth2.0 。 OAuth2.0 在 RFC 的文档地址： https://datatracker.ietf.org/doc/html/rfc6749

下面可以通过一个场景来解释一下， OAuth2.0 的原理：一个快递员的问题

假设你住在一个大型的小区中，你经常点外卖，而小区有门禁系统，进入的时候需要输密码

为了能让快递员进入，你就需要为他提供一组密码

如果你直接把你的密码给了快递员，那么他就有了和你一样的权限，如果你想取消他的权限，那只能改密码了，这样你还要通知使用该密码的其他人

所以你打算设计一套授权机制，既能让快递员进来，又能限制他的操作并且能随时回收这个密码

于是，你想出了一套办法，完善门禁系统：

此处为什么要给他生成一个令牌，而不是直接给他开门呢？

因为从小区大门到目的地可能会有多个门禁，所以就不用一直等着给快递员开门了；同样的，如果第二天快递员再来时就不需要再获取权限了

密码和令牌都让获取第三方获取用户数据，但是相较于密码，令牌有如下的有点：

令牌能够有效的控制第三方应用的访问权限和访问时长；当然，令牌也是必须要保密的，因为泄露令牌和泄露密码一样，也会造成安全问题，因此一般令牌的有效时间都会设置的比较短

OAuth2.0 提供了四种授权方式来应对不同的应用场景，

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

上面 URL 中， response_type 参数表示要求返回授权码（ code ）， client_id 参数让 B 知道是谁在请求， redirect_uri 参数是 B 接受或拒绝请求后的跳转网址， scope 参数表示要求的授权范围（这里是只读）。

第二步，用户跳转后，B 网站会要求用户登录（如果是未登录的情况下），然后询问是否同意给予 A 网站授权；如果用户同意授权，这时 B 网站就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

上面 URL 中， code 参数就是授权码。注：这个授权码与客户端一一对应，通常只有10分钟的有效期，并且只能使用一次
第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

上面 URL 中， client_id 参数和 client_secret 参数用来让 B 确认 A 的身份（ client_secret 参数是保密的，因此只能在后端发请求）， grant_type 参数的值是 AUTHORIZATION_CODE ，表示采用的授权方式是授权码， code 参数是上一步拿到的授权码， redirect_uri 参数是令牌颁发后的回调网址。

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向 redirect_uri 指定的网址，发送一段 JSON 数据。

上面 JSON 数据中， access_token 字段就是令牌，A 网站在后端拿到了。

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。 RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

上面 URL 中， response_type 参数为 token ，表示要求直接返回令牌。

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回 redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

上面 URL 中， token 参数就是令牌，A 网站因此直接在前端拿到令牌。
注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。**

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

上面 URL 中， grant_type 参数是授权方式，这里的 password 表示"密码式"， username 和 password 是 B 的用户名和密码。

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

第一步，A 应用在命令行向 B 发出请求。

上面 URL 中， grant_type 参数等于 client_credentials 表示采用凭证式， client_id 和 client_secret 用来让 B 确认 A 的身份。

第二步，B 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。

此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个 Authorization 字段，令牌就放在这个字段里面。

上面命令中， ACCESS_TOKEN 就是拿到的令牌。

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

上面 URL 中， grant_type 参数为 refresh_token 表示要求更新令牌， client_id 参数和 client_secret 参数用于确认身份， refresh_token 参数就是用于更新令牌的令牌

OAuth2.0 描述了授权 (Authorization) 的各种方式，但是这些方式中却没有定义如何进行认证 (Authentication)

认证 (Authentication) 和授权（Autherization 这两个表示的是不同的动作：

OpeID Connect （OIDC）对 OAuth2.0 进行了扩展，添加了用户认证的功能，并且它和 OAuth2.0 的流程是相同的。有区别的地方就是它的认证请求的字段中包含 scope=openid 如下所示：

在返回的响应中包含 ID Token ，用于获取用户身份，如下所示：

这里面有几个问题：

首先，

首先需要保证你的 OAuth2.0 请求是在 HTTPS 协议下发送的，这样可以防止暴露用户的信息。

其次就是一些钓鱼网站；比如，有一个 A 网站需要获取你在 B 网站上的资源或者数据，所以当你进入 A 网站的某个功能时，它会让你跳转到 B 网站，但是很有可能 B 网站是由 A 网站伪造跳转过来的，此时需要你的授权，当你输入账密的时候，你的账密就泄露了；这些钓鱼网站就是用来收集用户的账密信息的，所以当跳到第二个网站的时候一定要证实该网站是不是你注册过的合法的网站

参考连接：

https://datatracker.ietf.org/doc/html/rfc6749

https://auth0.com/intro-to-iam/what-is-oauth-2/

https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html

https://www.ruanyifeng.com/blog/2019/04/oauth_design.html

https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc

https://blog.runscope.com/posts/understanding-oauth-2-and-openid-connect

授权与认证OAuth 2.0 和 OIDC 的异同点

OAuth 2.0

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

OAuth 的核心就是向第三方应用颁发令牌

令牌与密码

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期，一般都设置得很短的原因。

OAuth 2.0

OAuth 即 Open Authorization ，开放授权。

OAuth 2.0 是一个授权标准协议，可以使第三方应用获得对资源服务的有限访问。

根据 OAuth 2.0 协议规范，定义了四个角色：

资源所有者（Resource Owner）：能够授予对受保护资源访问权限的实体。例如应用的用户是资源的所有者，可以授权其他人访问他的资源。当资源所有者是一个人时，它被称为最终用户。 —— 就相当于 admin，控制授予 Access Token 何种权限

资源服务器（Resource Server）：存储受保护资源的服务器，能够接受并使用访问令牌来响应受保护的资源请求。就是资源服务器接受 Access Token，然后验证它拥有的权限，最后返回对应的资源。这个资源服务器一般是应用本身。—— 验证 Access Token 和相应的权限，并返回资源

授权服务器（Authorisation Server）：服务器向客户端（即应用）颁发访问令牌来验证资源所有者并获得授权。即负责颁发 Access Token 的服务器，例如 IDaaS 就是一个授权服务器。—— 向客户端发放 Access Token

客户端（Client）：需要获取访问令牌以访问资源服务器的应用。经过授权后，授权服务器为客户端颁发 Access Token。后续客户端可以携带这个 Access Token 到资源服务器那访问用户的资源。—— 需要 Access Token 来获取资源

在 OAuth 2.0 中一个应用可能既是 Resource Server，也是 Client，具体是什么角色，取决于应用工作的场景。

概念可能有点难嚼，还请慢咽。

这四个角色一直在围绕着一个叫 Access Token 的东西在转圈圈。

Access Token 也就是访问令牌，它用于允许应用访问一个资源 API。用户认证授权成功后，授权服务器会签发 Access Token 给应用。应用后续需要携带 Access Token 访问资源 API，资源服务 API 会检验 Access Token 是否有权限访问，从而决定是否返回对应资源。

而 Access Token 本质上只是一串随机字符串，并不能从中获取到任何信息，检验 Access Token 的步骤还需要资源服务器将它转发到授权服务器上进行解析验证。

了解完 Access Token 之后，我们来关注一下客户端调用方是如何获取到它的，也就是授权模式的选择。

授权码模式（Authorization Code）：适用于具有完整前后端的传统 Web 应用以及移动或桌面端应用。

隐式模式（Implicit）：适用于没有后端的基于浏览器（JavaScript）的纯前端应用。

密码模式（Resource Owner Password Credentials）：适用于资源服务器和客户端之间高度信任的情况下，例如自家应用使用自家的资源。

客户端凭证模式（Client Credentials）：适用于没有前端参与，纯后端交互的情况，期间没有用户的参与，客户端自己就是资源所有者。
…

我们重点关注授权码模式和客户端凭证模式，这两个是最常用的。

流程

OAuth2.0协议流程描述了四种角色之间的交互过程，如下图所示。

上面的序列图一共分为以下6个步骤：

（1）第三方应用请求资源所有者授权。

（2）资源所有者同意给第三方应用授权。

（3）第三方应用使用步骤2中获得的授权，向授权服务器申请令牌。

（4）授权服务器对第三方应用进行认证并确认无误后，同意发放令牌。

（5）第三方应用使用步骤4中发放的令牌向资源服务器申请获取资源。

（6）资源服务器确认令牌无误后，向第三方应用开放资源访问。

四种模式

OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权类型（authorization grant），即四种颁发令牌的方式，适用于不同的互联网场景。

1. 隐式授权模式（Implicit Grant）

第一步：用户访问页面时，重定向到认证服务器。
第二步：认证服务器给用户一个认证页面，等待用户授权。
第三步：用户授权，认证服务器想应用页面返回Token
第四步：验证Token，访问真正的资源页面

2. 授权码授权模式（Authorization code Grant）

示例见开发者谈 | OAuth 2.0 和 OIDC 协议的关系？（内含必看案例）

第一步：用户访问页面
第二步：访问的页面将请求重定向到认证服务器
第三步：认证服务器向用户展示授权页面，等待用户授权
第四步：用户授权，认证服务器生成一个code和带上client_id发送给应用服务器
然后，应用服务器拿到code，并用client_id去后台查询对应的client_secret
第五步：将code、client_id、client_secret传给认证服务器换取access_token和
refresh_token
第六步：将access_token和refresh_token传给应用服务器
第七步：验证token，访问真正的资源页面

3. 密码模式（Resource Owner Password Credentials Grant）

第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)
第二步：应用页面那种这个信息去认证服务器授权
第三步：认证服务器授权通过，拿到token，访问真正的资源页面

优点：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。(都拿到账号密码了)

缺点：局限性，认证服务器和应用方必须有超高的信赖。(比如亲兄弟？)

应用场景：自家公司搭建的认证服务器

4. 客户端凭证模式（Client Credentials Grant）

第一步：用户访问应用客户端
第二步：通过客户端定义的验证方法，拿到token，无需授权
第三步：访问资源服务器A
第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。

因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。

OpenID Connect

讲完 OAuth 2.0 授权，来到 OIDC 认证协议。

如标题，OIDC 全称是 OpenID Connect，是一个基于 OAuth 2.0 的认证 + 授权（OAuth 2.0 提供的能力）协议。

OIDC 可以理解为 OAuth 2.0 的超集，在 OAuth 2.0 之上实现了更多的标准，例如定义了一系列的 EndPoint 。还有一些规范诸如 Session Management，Front-Channel Logout，Back-Channel Logout 等。

OIDC 之所以有认证的功能，是因为在 OAuth 2.0 颁发 Access Token 的基础上，多颁发了一个 ID Token（用户的身份凭证），和 Access Token 是一个随机字符串不同的是，ID Token 是一个 JWT Token 。

ID Token 自身包含了一些用户的基本信息，而且由于 JWT 的防篡改性，让客户端不需要再向授权服务器进行身份验证，就能直接用 ID Token 来进行身份验证。即使 ID Token 包含的用户信息不够，也可以调用 OIDC 定义的 UserInfo EndPoint（用户信息接口）来获取更多的用户信息。

OIDC 协议定义的名词和 OAuth 2.0 协议定义的稍微有些出入：

OpenID Provider ，简称 OP ：相当于 OAuth 2.0 中的授权服务器，除了负责颁发 Access Token ，还会颁发 ID Token 。例如 IDaaS 就是一个 OP 。
Relying Party ，简称 RP ：代指 OAuth 2.0 中的客户端。
End User ，简称 EU ：即用户。

最后， OIDC 的授权流程与 OAuth 2.0 是一样的，主要区别在于 OIDC 授权流程中会额外返回 ID Token。