iOS 用 ASWebAuthenticationSession 实现 OAuth 登录

你是否需要通过第三方APP对用户授权？可能你的客户已经要求你使用OAuth标准实现这样的机制？

如果您在企业环境中工作，你的客户用 Active Directory 来管理用户，并且使用 Okta 或 Ping Federate 来控制第三方 APP 和受保护的资源进行交互，应该怎么办？

该指南中，你会创建第三方的 GitHub APP，可以通过使用 ASWebAuthenticationSession 的 OAuth 标准进行授权并展示用户拥有的仓库列表。在该过程中，你会学习到：

开始

在使用服务器授权的传统客户端 APP 中，服务器存储用户名和密码来授权用户并允许用户访问。不需要第三方介入时这样是可以的。

但是，当 APP 如 GitHub 想要为第三方 APP 添加支持时会发生什么呢？

这时事情就会变得棘手，并会出现一些缺点。不使用 OAuth ，会遇到以下几种问题：

如何能使 GitHub （服务器应用）允许你（第三方 APP）访问受保护的资源，而不需要给予完整不受限制的权限？这就是需要 OAuth 的地方。

在互联网工程任务组（IETF）的官方网站上，有 OAuth 2.0 标准的定义：

The OAuth 2.0 授权框架可通过在资源所有者和 HTTP 服务之间编排审批交互或允许第三方APP获得基于自身行为的访问来允许第三方 APP 受限访问某个 HTTP 服务或代表资源的所有者。

注： OAuth 1.0 标准已被废弃并已被 OAuth 2.0 代替，该指南表述的内容也是 OAuth 2.0 的内容。

你的第三方 APP 不会存储用户凭证或直接授权用户。这时你会更希望 GitHub 强大的基础设施和安全性为你做这些。

你希望你的第三方 APP 要做的是允许用户使用他们的 GitHub 凭证登录以访问 GitHub 中指定的资源。

另一个场景是使用 GitHub 实现用户授权 - 而无需在具体实现和安全细节上花费太多时间 - 但是不会在未验证用户ID的情况下访问 GitHub 的资源。

这也是 APP 和网站通常使用 第三方登录 按钮用于使用 FaceBook 、Apple 或 Google 之类的服务登录。它们会让这些第三方服务进行服务器安全和登录基础设施的处理。

OAuth 通过将认证处理和授权处理分开以提供帮助。

但是，它们之间的明确区别是啥呢？它们不一样吗？你可能会惊讶，在互换使用两种处理很多年后得出的结论是，它们不一样。

该指向中，GitHub 会给你的 APP 特定的访问和权限：授权。但是，验证用户并通过 GitHub 确认身份取决于用户：认证。

至今为至，你已经了解了 OAuth 相关的内容，还有认证和授权的区别。在幕后，OAuth 还有一些其它重要概念需要学习一下。首先就是角色。

OAuth 定义了四种角色：

OAuth 标准如下定义了第三方 APP 的典型流程。这是在本指南中你要实现的：

APP 请求 访问令牌，一个短期存活的令牌，可作为资源所有者的请求中使用。要这样做，它必须向授权服务器提供一个客户端ID，并允许用户使用他们的的凭证验证身份。
授权服务器验证客户端，给用户返回一个 访问令牌 和一个 刷新令牌，它们只能在你的 APP 中使用。前提是所有处理都合法且顺利。
你的 APP 、客户端，向受资源所有者保护的资源发起请求。该客户端必须要提供用户的访问令牌，否则就请求就会失败。
资源所有者验证用户的访问令牌。如果是有效的，就会返回被访问的资源。
你的 APP 会继续代表用户发起请求，直到访问令牌过期。当访问令牌过期后，对于接下来的请求，资源所有者会产生一个非法的令牌错误。
你的 APP 可使用刷新令牌，通常是长期存活的令牌，向授权服务器请求新的访问令牌。与之前的范围和限制一样。
如果刷新令牌还有效，授权服务器会为你的 APP 生成一个新的访问令牌。如果刷新令牌过期了，用户必须再次使用他们的凭证进行验证。

注：还有一些其它方式可以验证，包括在两个客户端之间的无浏览器选项，或者无法访问手动用户输入时。这不属于本指南的讨论范围。

OAuth 是重度依赖于网络的，这意味着大多数的实现会展现一些Web视图使用户输入他们的凭证。在幕后，会有一些重定向和回调来替换和使事情生效。不用担心，该指南会帮你搞定。

至今为止介绍了很多理论，现在你会对 OAuth 和它的机制有了更好的理解。