本文介绍了OAuth2授权协议的基本原理及其应用场景，包括四种授权模式的对比与选择流程。此外，还探讨了SSO（单点登录）的概念，以及如何使用OAuth2、OpenID Connect等技术实现SSO。
oauth2实现单点登录
电子书资源见
https://www.yuque.com/docs/share/37bd8227-eece-435a-9805-87254f4b34e9?# 《oauth2授权》
blog 地址 https://youngboy.vip
oauth2是什么？
OAuth2： OAuth2（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。
举个栗子：第三方网站登录，oschina通过gitee登录
访问oschina，点击登录可以选择使用gitee登录，gitee登录之后，oschina就能获取到登录的gitee账号相关信息
根据以上示例，可以将OAuth2分为四个角色：
- Resource Owner：资源所有者 即上述中的gitee用户
- Resource Server：资源服务器 即上述中的gitee服务器，提供gitee用户基本信息给到第三方应用
- Client：第三方应用客户端 即上述中oschina网站
- Authorication Server：授权服务器 该角色可以理解为管理其余三者关系的中间层
四种授权模式的使用场景
| 模式 | 适用场景 |
|---|---|
| 授权码模式 | 适用于网页第三方授权 |
| 密码模式 | 适用于手机等客户端使用 |
| 客户端模式 | 适用于授权接口给第三方客户端 |
| 简化模式 | 适用于web端应用 |
简化模式
客户端模式
密码模式
授权码模式
四种模式的选择流程
参考文章 http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
常见安全问题
授权码安全
open redirect 攻击
Referer 攻击
redirect_url 控制攻击
凭证安全
保证client_secret的保密性，不能在日志中输出client_secret或者用户的密码或token
csrf攻击
cross-site request forgery (CSRF)
授权码模式和简化模式都应该带上state参数，防止可能的csrf攻击
官方原文6
An opaque value used by the client to maintain state between the request and callback.
The authorization server includes this value when redirecting the user-agent back to the
client. The parameter SHOULD be used for preventing cross-site request forgery (CSRF).
安全建议
- 客户端带上state参数，登陆页面接口请求都要加上 CSRF token校验
- 日志脱敏，避免泄露凭证或token
- 全站https并开启HSTS防止请求劫持
- 禁止登陆页面被嵌入iframe
- 避免在url参数中传递token，游览器的referrer头可能会泄露token·
- 选择正确的授权模式，手机端游览器禁止使用简化模式，前端页面禁止使用密码模式（前端不能保存client_secret）
- 前端后端开启xss过滤器
- access_token有效期不应该大于通常使用时间
- 使用成熟的oauth2框架
Tips：如果您想对OAuth2.0开放标准进行扩展阅读，请参看：OAuth标准（英文） | OAuth维基百科（中文）
SSO单点登录
sso 是什么？
SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
权限控制主要分两步
- Authentication 认证 (证明自己是自己)
- Authorization 授权（证明自己是自己后能够做什么）
sso 属于 Authentication 范畴
登录系统
首先，我们要为“登录”做一个简要的定义，令后续的讲述更准确。之前的两篇文章有意无意地混淆了“登录”与“身份验证”的说法，因为在本篇之前，不少“传统Web应用”都将对身份的识别看作整个登录的过程，很少出现像企业应用环境中那样复杂的情景和需求。但从之前的文章中我们看到，现代Web应用对身份验证相关的需求已经向复杂化发展了。
我们有必要重新认识一下登录系统。 登录指的是从识别用户身份，到允许用户访问其权限相应的资源的过程。 举个例子，在网上买好了票之后去影院观影的过程就是一个典型的登录过程：我们先去取票机，输入验证码取票；接着拿到票去影厅检票进入。取票的过程即身份验证，它能够证明我们拥有这张票；而后面检票的过程，则是授权访问的过程。之所以要分成这两个过程，最直接的原因还是业务形态本身具有复杂性——如果观景过程是免费匿名的，也就免去了这些过程。
在登录的过程中，“鉴权”与“授权”是两个最关键的过程。接下来要介绍的一些技术和实践，也包含在这两个方面中。虽然现代Web应用的登录需求比较复杂，但只要处理好了鉴权和授权两个方面，其余各个方面的问题也将迎刃而解。在现代Web应用的登录工程实践中，需要结合传统Web应用的典型实践，以及一些新的思路，才能既解决好登录需求，又能符合Web的轻量级架构思路。
解析常见的登录场景
在简单的Web系统中，典型的鉴权也就是要求用户输入并比对用户名和密码的过程，而授权则是确保会话Cookie存在。而在稍微复杂的Web系统中，则需要考虑多种鉴权方式，以及多种授权场景。上一篇文章中所述的“多种登录方式”和“双因子鉴权”就是多种鉴权方式的例子。有经验的人经常调侃说，只要理解了鉴权与授权，就能清晰地理解登录系统了。不光如此，这也是安全登录系统的基础所在。
鉴权的形式丰富多彩，有传统的用户名密码对、客户端证书，有人们越来越熟悉的第三方登录、手机验证，以及新兴的扫码和指纹等方式，它们都能用于对用户的身份进行识别。在成功识别用户之后，在用户访问资源或执行操作之前，我们还需要对用户的操作进行授权。
在一些特别简单的情形中——用户一经识别，就可以无限制地访问资源、执行所有操作——系统直接对所有“已登录的人”放行。比如高速公路收费站，只要车辆有合法的号牌即可放行，不需要给驾驶员发一张用于指示“允许行驶的方向或时间”的票据。除了这类特别简单的情形之外，授权更多时候是比较复杂的工作。
在单一的传统Web应用中，授权的过程通常由会话Cookie来完成——只要服务器发现浏览器携带了对应的Cookie，即允许用户访问资源、执行操作。而在浏览器之外，例如在Web API调用、移动应用和富 Web 应用等场景中，要提供安全又不失灵活的授权方式，就需要借助令牌技术。
令牌
令牌是一个在各种介绍登录技术的文章中常被提及的概念，也是现代Web应用系统中非常关键的技术。令牌是一个非常简单的概念，它指的是在用户通过身份验证之后，为用户分配的一个临时凭证。在系统内部，各个子系统只需要以统一的方式正确识别和处理这个凭证即可完成对用户的访问和操作进行授权。在上文所提到的例子中，电影票就是一个典型的令牌。影厅门口的工作人员只需要确认来客手持印有对应场次的电影票即视为合法访问，而不需要理会客户是从何种渠道取得了电影票（比如自行购买、朋友赠予等），电影票在本场次范围内可以持续使用（比如可以中场出去休息等）、过期作废。通过电影票这样一个简单的令牌机制，电影票的出售渠道可以丰富多样，检票人员的工作却仍然简单轻松。
OAuth 2、Open ID Connect
令牌在广为使用的OAuth技术中被采用来完成授权的过程。OAuth是一种开放的授权模型，它规定了一种供资源拥有方与消费方之间简单又直观的交互方法，即从消费方向资源拥有方发起使用AccessToken（访问令牌）签名的HTTP请求。这种方式让消费方应用在无需（也无法）获得用户凭据的情况下，只要用户完成鉴权过程并同意消费方以自己的身份调用数据和操作，消费方就可以获得能够完成功能的访问令牌。OAuth简单的流程和自由的编程模型让它很好地满足了开放平台场景中授权第三方应用使用用户数据的需求。不少互联网公司建设开放平台，将它们的用户在其平台上的数据以 API 的形式开放给第三方应用来使用，从而让用户享受更丰富的服务。
OAuth在各个开放平台的成功使用，令更多开发者了解到它，并被它简单明确的流程所吸引。此外，OAuth协议规定的是授权模型，并不规定访问令牌的数据格式，也不限制在整个登录过程中需要使用的鉴权方法。人们很快发现，只要对OAuth进行合适的利用即可将其用于各种自有系统中的场景。例如，将 Web 服务视作资源拥有方，而将富Web应用或者移动应用视作消费方应用，就与开放平台的场景完全吻合。
另一个大量实践的场景是基于OAuth的单点登录。OAuth并没有对鉴权的部分做规定，也不要求在握手交互过程中包含用户的身份信息，因此它并不适合作为单点登录系统来使用。然而，由于OAuth的流程中隐含了鉴权的步骤，因而仍然有不少开发者将这一鉴权的步骤用作单点登录系统，这也俨然衍生成为一种实践模式。更有人将这个实践进行了标准化，它就是Open ID Connect——基于OAuth的身份上下文协议，通过它即可以JWT的形式安全地在多个应用中共享用户身份。接下来，只要让鉴权服务器支持较长的会话时间，就可以利用OAuth为多个业务系统提供单点登录功能了。
我们还没有讨论OAuth对鉴权系统的影响。实际上，OAuth对鉴权系统没有影响，在它的框架内，只是假设已经存在了一种可用于识别用户的有效机制，而这种机制具体是怎么工作的，OAuth并不关心。因此我们既可以使用用户名密码（大多数开放平台提供商都是这种方式），也可以使用扫码登录来识别用户，更可以提供诸如“记住密码”，或者双因子验证等其他功能。
汇总
上面罗列了大量术语和解释，那么具体到一个典型的Web系统中，又应该如何对安全系统进行设计呢？综合这些技术，从端到云，从Web门户到内部服务，本文给出如下架构方案建议：
推荐为整个应用的所有系统、子系统都部署全程的HTTPS，如果出于性能和成本考虑做不到，那么至少要保证在用户或设备直接访问的Web应用中全程使用HTTPS。
用不同的系统分别用作身份和登录，以及业务服务。当用户登录成功之后，使用OpenID Connect向业务系统颁发JWT格式的访问令牌和身份信息。如果需要，登录系统可以提供多种登录方式，或者双因子登录等增强功能。作为安全令牌服务（STS），它还负责颁发、刷新、验证和取消令牌的操作。在身份验证的整个流程的每一个步骤，都使用OAuth及JWT中内置的机制来验证数据的来源方是可信的：登录系统要确保登录请求来自受认可的业务应用，而业务在获得令牌之后也需要验证令牌的有效性。
在Web页面应用中，应该申请时效较短的令牌。将获取到的令牌向客户端页面中以httponly的方式写入会话Cookie，以用于后续请求的授权；在后绪请求到达时，验证请求中所携带的令牌，并延长其时效。基于JWT自包含的特性，辅以完备的签名认证，Web 应用无需额外地维护会话状态。
在富客户端Web应用（单页应用），或者移动端、客户端应用中，可按照应用业务形态申请时效较长的令牌，或者用较短时效的令牌、配合专用的刷新令牌使用。
在Web应用的子系统之间，调用其他子服务时，可灵活使用“应用程序身份”（如果该服务完全不直接对用户提供调用），或者将用户传入的令牌直接传递到受调用的服务，以这种方式进行授权。各个业务系统可结合基于角色的访问控制（RBAC）开发自有专用权限系统。
http://insights.thoughtworkers.org/traditional-web-app-authentication/
最低0.47元/天 解锁文章
扫一扫
779
到【灌水乐园】发言
