我们都在网站或者手机运用中见过“谷歌上岸”和“绑定 Facebook“这样的按钮。如果你点击这个按钮，就会有一个窗口弹出并显示“这个运用想要访问你的公共个人主页、通讯录……“，同时它会讯问你是否授权。概括而言，这便是 OAuth。对付每个软件工程师、安全专家乃至是黑客，理解这些协议都是非常主要的。
序言本文是一篇关于 OAuth 2.0 与 OpenID Connect 协议的完全指南，这两个协议是用于授权和认证的利用最广泛的的协议。OAuth 2.0 用于授权，OpenID Connect 用于认证。有两种 OAuth 2.0 授权流程最为常见：做事端运用程序的授权码流程和基于浏览器的运用程序的隐式流程。OpenID Connect 是 OAuth 2.0 协议之上的标识层，以使 OAuth 适用于认证的用例。
为了更好地理解 OAuth 出身的情由，我们须要理解一个术语：代理授权。
代理授权是一种许可第三方运用访问用户数据的方法。
两种代理授权的办法有两种代理授权的办法：一是你将账号密码供应给第三方运用，以便它们可以代表你来上岸账号并且访问数据；二是你通过 OAuth 授权第三方运用访问你的数据，而无需供应密码。（我相信我们都不会选择交出我们的密码！
）
现在，我们知道了 OAuth 的必要性和主要性，让我们更深入地研究这个协议。
什么是 OAuth？OAuth（Open Authorization，即开放授权）是一个用于代理授权的标准协议。它许可运用程序在不供应用户密码的情形下访问该用户的数据。
OAuth 2.0 术语表为理解这个协议，我们须要理解以下术语：
资源所有者（Resource Owner）：拥有客户端运用程序想要访问的数据的用户。客户端（Client）：想要访问用户数据的的运用程序授权做事端（Authorization Server）：通过用户容许，授权客户端访问用户数据的授权做事端。资源做事端（Resource Server）：存储客户端要访问的数据的系统。在某些情形下，资源做事端和授权做事端是同一个做事端。访问令牌：访问令牌是客户端可用于访问资源做事端上用户授权的数据的唯一密钥。以下是 OAuth 2.0 抽象流程图，让我们一起看看上述术语在图中的运用
OAuth2.0 抽象流程图
授权密钥（Authorization Key）或者权限（Grant）可以是授权码或者令牌的类型。下文我们将会提到不同的权限和授权密钥。现在，让我们先详细阐明授权的流程。
用户通过点击按钮启动全体授权流程。这个按钮常日类似于“谷歌上岸“、”Facebook 上岸“或者通过其他的运用上岸。然后客户端将用户重定向到授权做事端。在重定向的过程中，客户端将类似客户 ID、重定向 URI 的信息发送给授权做事端。授权做事端处理用户认证，并显示授权容许窗口，然后从用户方得到授权容许。如果你通过谷歌上岸，你必须向谷歌，而不是客户端，供应上岸证书——例如向 accounts.google.com 供应上岸证书。如果用户授权容许，则授权做事端将用户重定向到客户端，同时发送授权密钥（授权码或令牌）。客户端向资源做事端发送包含授权密钥的要求，哀求资源做事端返回用户数据。资源做事端验证授权密钥，并向客户端返回它所要求的数据。这便是用户在不供应密码的情形下，许可第三方运用访问用户数据的过程。但与此同时，有一些问题涌现了：
我们如何限定客户端只访问资源做事端上的部分数据？如果我们只希望客户端读取数据，而没有权限写入数据呢？这些问题将我们勾引至 OAuth 技能术语中另一部分很主要的观点：授权范围（Scope）。
OAuth 中的授权范围（Scope）在 OAuth 2.0 中，授权范围用于限定运用程序访问某用户的数据。这是通过发布仅限于用户授权范围的权限来实现的。
当客户端向授权做事端发起权限要求时，它同时随之发送一个授权范围列表。授权客户端根据这个列表天生一个授权容许窗口，并通过用户授权容许。如果用户赞许了其授权奉告，授权客户端将发布一个令牌或者授权码，该令牌或授权码仅限于用户授权的范围。
举个例子，如果我授权了某客户端运用访问我的谷歌通讯录，则授权做事端向该客户端发布的令牌不能用于删除我的联系人，或者查看我的谷歌日历事宜——由于它仅限于读取谷歌通讯录的范围。
OAuth 2.0 的设置在谈论 OAuth 流程之前，最好先理解一些 OAuth 的配置。当发起授权权限的要求时，客户端将一些配置数据作为查询参数发送给授权做事端。这些基本的查询参数包括：
相应类型（response_type）：我们希望从授权做事端得到的相应类型授权范围（scope）：客户端希望访问的授权范围列表。授权做事端将利用这个列表为用户产生赞许授权容许窗口。用户 ID（client_id）：由授权做事在为 OAuth 设置客户端时供应。此 ID 可帮助授权做事端确定正在发送 OAuth 流程的客户端。重定向通用资源标识符（redirect_uri）：用于奉告授权做事器当 OAuth 流程完成后重定向的地址客户密码（client_secret）：由授权做事供应，根据 OAuth 流程，这个参数可能须要也可能不须要。我们将在授权码流程中会理解到它的主要性。理解不同的 OAuth 流程两种最常用的 OAuth2.0 流程是：基于做事器的运用程序所利用的授权码流程，以及纯 JavaScript 单页运用所利用的隐式流程。
为理解释 OAuth 的各种流程，接下来我将用谷歌作为 OAuth 做事供应者。
授权码流程授权码流程，或者说授权码权限，是空想的 OAuth 流程。它被认为是非常安全的，由于它同时利用前端路子（浏览器）和后端路子（做事器）来实现 OAuth2.0 机制。
OAuth2.0 授权码流程
客户端通过将用户重定向到授权做事端来发起一个授权流程，个中，response_type需被设置成code。这奉告了授权做事端用授权码来相应。该流程的 URI 如下所示：
复制代码
https://accounts.google.com/o/oauth2/v2/auth? response_type=code& client_id=your_client_id& scope=profile%20contacts& redirect_uri=https%3A//oauth2.example.com/code
在上述要求中，客户端要求能够访问该用户公共主页和联系人的用户容许，这是在scope要求参数中设置的。这个要求的结果是授权码，客户端可以利用该授权码来交流访问令牌。一个授权码如下所示：
复制代码
4/W7q7P51a-iMsCeLvIaQc6bYrgtp9为什么用授权码来交流令牌？
访问令牌是唯一能用于访问资源做事端上的数据的东西，而不是授权码。所以为什么在客户端实际须要访问令牌的情形下，将response_type设置成授权码呢？这是由于这样做能使 OAuth 流程非常安全。
OAuth2.0 授权码流程
问题：访问令牌是我们不肯望任何人能访问的秘密信息。如果客户端直接要求访问令牌，并将其存储在浏览器里，它可能会被盗，由于浏览器并不是完备安全的。任何人都能瞥见网页的代码，或者利用开拓工具来获取访问令牌。
办理方案：未了避免将访问令牌暴露在浏览器中，客户真个前端从授权做事端得到授权码，然后发送这个授权码到客户真个后端。现在，为了用授权码交流访问令牌，我们须要一个叫做客户密码（client_secret）的东西。这个客户密码只有客户真个后端知道，然后后端向授权做事端发送一个 POST 要求，个中包含了授权码和客户密码。这个要求可能如下所示：
复制代码
POST /token HTTP/1.1Host: oauth2.googleapis.comContent-Type: application/x-www-form-urlencodedcode=4/W7q7P51a-iMsCeLvIaQc6bYrgtp9&client_id=your_client_id&client_secret=your_client_secret_only_known_by_server&redirect_uri=https%3A//oauth2.example.com/code
授权做事端会验证客户密码和授权码，然后返回一个访问令牌。后端程序存储了这个访问令牌并且可能利用此令牌来访问资源做事端。这样一来，浏览器就无法读取访问令牌了。
隐式流程当你没有后端程序，并且你的网站是一个仅利用浏览器的静态网站时，该当利用 OAuth2.0 隐式流程。在这种情形下，当你用授权码交流访问令牌时，你跳过发生在后端程序的末了一步。在隐式流程中，授权做事端直接返回访问令牌。
OAuth2.0 授权码流程
客户端将浏览看重定向到授权做事端 URI，并将response_type设置成token，以启动授权流程。授权做事端处理用户的登录和授权容许。要求的返回结果是访问令牌，客户端可以通过这个令牌访问资源做事端。
隐式流程被认为不那么安全，由于浏览器卖力管理访问令牌，因此令牌有可能被盗。只管如此，它仍旧被单页运用广泛利用。
认证与授权正如我们所知，OAuth 办理了代理授权的问题，但是它没有供应一个认证用户身份的标准方法。你可以这样认为：
OAuth2.0 用于授权OpenID Connect 用于认证如果你无法区分这些术语，则以下是它们之间的差异：
认证（Authentication）是确保通信实体是其所声称的实体。授权（Authorization）是验证通信实体是否有权访问资源的过程。换言之，认证关注的是你是谁，授权关注的是你有什么权限。
OpenID ConnectOpenID Connect 是在 OAuth2.0 协议之上的标识层。它拓展了 OAuth2.0，使得认证办法标准化。
OAuth 不会立即供应用户身份，而是会供应用于授权的访问令牌。 OpenID Connect 使客户端能够通过认证来识别用户，个中，认证在授权做事端实行。它是这样实现的：在向授权做事端发起用户登录和授权奉告的要求时，定义一个名叫openid的授权范围。在奉告授权做事器须要利用 OpenID Connect 时，openid是必须存在的范围。
客户端发起的用于 OpenID Connect 认证要求 URI 会是如下的形式：
复制代码
https://accounts.google.com/o/oauth2/v2/auth? response_type=code& client_id=your_client_id& scope=openid%20contacts& redirect_uri=https%3A//oauth2.example.com/code
该要求的返回结果是客户端可以用来交流访问令牌和 ID 令牌的授权码。如果 OAuth 流程是隐式的，那么授权做事端将直接返回访问令牌和 ID 令牌。ID 令牌是 JWT，或者又称 JSON Web Token。JWT 是一个编码令牌，它由三部分组成：头部，有效负载和署名。在得到了 ID 令牌后，客户端可以将其解码，并且得到被编码在有效负载中的用户信息，如以下例子所示：
复制代码
{ "iss": "https://accounts.google.com", "sub": "10965150351106250715113082368", "email": "johndoe@example.com", "iat": 1516239022, "exp": 1516242922}声明（Claim）
ID 令牌的有效负载包括了一些被称作声明的域。基本的声明有：
iss：令牌发布者sub：用户的唯一标识符email：用户的邮箱iat：用 Unix 韶光表示的令牌发布韶光exp：Unix 韶光表示的令牌到期韶光然而，声明不仅限于上述这些域。由授权做事器对声明进行编码。客户端可以用这些信息来认证用户。
如果客户端须要更多的用户信息，客户端可以指定标准的 OpenID Connect 范围，来奉告授权做事端将所需信息包括在 ID 令牌的有效负载中。这些范围包括个人主页（profile）、邮箱（email）、地址（address）和电话（phone）。
结语练习你所学习的内容总是好的。你可以访问 Google OAuth 2.0 Playground 来利用 OAuth2.0 的授权范围、授权码和令牌。
