单点登录授权认证必知必会
1 OAuth2.0
1.1 什么是 OAuth2.0
OAuth 2.0授权框架使第三方的应用程序，以获得有限的访问一个 HTTP 服务，无论是在通过编排审批交互来代表资源所有者资源所有者和 HTTP 服务，或者通过允许第三方应用程序，以自己的名义获得访问权。
在传统的客户端—服务器身份验证模型中，客户端请求访问限制资源（受保护资源）服务器，通过与服务器进行身份验证使用资源所有者的认证凭据。为了提供第三方应用程序访问受限制的资源时，资源所有者将其凭据共享给第三方，这会造成了几个严重的问题：
需要第三方应用程序来存储资源所有者的凭据，以供将来使用，通常密码明文可见。
第三方应用程序对资源的访问范围过大，使资源所有者没有任何能够限制访问时的间或范围。
资源所有者不能有针对性的撤销第三方的访问权，并且必须通过更改第三方的密码。
服务器都需要支持密码认证。
下面我们将看看，OAuth 是怎么通过引入授权认证层来解决这些问题。
（注意区分“授权”和“认证”：OAuth 全称为 Open Authorization，授权表示“你能干什么”；而区别于下面要介绍的 OpenId Connect 协议，它是一种基于 OAuth2 的身份认证协议，认证表示“你是谁”。）
1.2 OAuth2.0 基本流程
Resource Owner
能够授予对受保护资源的访问权限的实体，当资源所有者是个人时，它被称为最终用户。
Resource Server
托管受保护资源的服务器，能够接受以及响应携带访问令牌的资源请求。
Client
代表资源所有者发出受保护资源请求的应用程序或者客户端（比如浏览器）。
Authorization Server
验证资源所有者身份并颁发授权认证的服务器。（可以和受保护资源在同一个服务器，也可以单独部署）
1.3 四种授权类型
Authorization Grant 表示获取访问令牌的过程，规范定义了四个授权类型——授权码、隐式、资源所有者密码凭据和客户端凭据。
1.3.1 Authorization Code
授权码方式适用于前后端分离的情况下，其认证授权所有过程都在服务器端完成，安全性高。
通过使用第三方（第三方是相对于资源服务器而言的的）客户端应用程序将所有者重定向到授权服务器，并将授权码返回给客户端应用程序。
授权码的重要作用是对客户端进行身份验证并直接获取访问令牌，而不将其传递给所有者的用户代理（避免将 Access Token 暴露给 User Agent，这里的 Agent 如浏览器等第三方用户代理程序）。
最佳实践 第三方应用（如 CSDN、Bilibili 等）微信登录
网站应用微信登录是基于 OAuth2.0 协议标准构建的微信 OAuth2.0 授权登录系统。（ 前置条件：在进行微信 OAuth2.0 授权登录接入之前，在微信开放平台注册开发者帐号，并拥有一个已审核通过的网站应用，并获得相应的 AppID 和 AppSecret，申请微信登录且通过审核后，可开始接入流程。）
在此场景中，协议中的四个角色如下：
Resource Owner => 用户
Client => 第三方应用
Resource Server/Authorization Server=>微信开放平台
1.3.2 Implicit
隐式授权方式（Implicit）相对授权码授权方式简单很多，它适用于一些纯前端应用（此时令牌只能储存在前端）。用户登录并对第三方应用进行授权时，直接返回 Access Token。RFC6749 规范就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"。
1.3.3 Password Credentials
密码授权方式（Password Credentials）要求第三方应用和资源所有者之间高度信任。RFC6749 允许用户把用户名和密码，直接告诉该第三方应用，应用则可以使用密码请求访问令牌。
1.3.4 Client Credentials
客户端凭据模式（Client Credentials）主要应用于后端系统之间需要直接通信，但是没有用户参与的场景。比如某些开放平台，允许注册应用获取一些平台公共资源，比如平台的介绍信息，注册应用本身的信息，这些理论上是不需要用户进行授权的，而且也跟用户没有归属关系，这个时候就可以使用此模式。
1、由 Authorization Server 提供给各业务系统一个 clientID 和 clientSecret；
2、通过 clientID 和 clientSecret 获取 accessToken。
1.4 令牌刷新机制
一般我们通过授权服务器授权时，授权服务器会颁发两个 Token，一个是访问令牌——Access Token，用于访问被保护的资源，与此同时，Access Token 会有一个过期时间；另外，还有一个刷新令牌——Refresh Token，当 Access Token 过期时，用其去从新获取新的 Access Token。
为什么要用这样的机制？试想，如果 Access Token 为长期有效，则一旦访问令牌被泄露，这将是一个很严重的数据安全问题。因此，可以通过设置令牌过期时间（根据业务以及受保护资源的安全级别可设置不同的时长的过期时间），一旦 Access Token 过期，则需要通过 Refresh Token 去从新获取新的访问令牌，过期的令牌则在授权服务器验证不通过，从而增强其安全性。当然，这里 Refresh Token 的安全级别和 Access Token 一样，Refresh Token 一般也有过期时间，需要存在服务端。
以下是获取 Access Token 响应示例。
以下是通过 Refresh Token 刷新 Access Token 请求示例:
对刷新令牌授予的响应与颁发访问令牌时的响应相同。可以选择在响应中颁发新的刷新令牌，或者如果不包括新的刷新令牌，则客户端假定当前刷新令牌将继续有效。
2 OpenID Connect
2.1 什么是 OIDC
OpenID Connect（OIDC）是一种建立在 OAuth 2.0 协议之上的身份验证和授权协议。它提供了一种安全的方式来验证用户的身份，并允许客户端应用程序以授权的方式访问用户的受保护资源。
OIDC 使用 JSON Web Token（JWT）作为身份验证和授权令牌。它通过在认证服务器和客户端之间进行交互来实现身份验证和授权流程。以下是 OIDC 的一些关键概念：
客户端（Client）：代表用户与认证服务器进行交互的应用程序。客户端可以是 Web 应用程序、移动应用程序或其他类型的应用程序。
认证服务器（Authorization Server）：负责验证用户的身份，并颁发令牌给客户端。认证服务器通常与身份提供者（Identity Provider）关联，例如 Google、Microsoft 等。
用户（End User）：使用客户端应用程序的实际用户。
令牌（Token）：OIDC 使用 JWT 作为身份验证和授权令牌。令牌包含有关用户身份和授权的信息。
2.2 OIDC 基本流程
OIDC 的工作流程如下：
客户端向认证服务器发起身份验证请求，并重定向用户到认证服务器的登录页面。
用户在认证服务器上进行身份验证，并授权客户端应用程序访问其受保护的资源。
认证服务器验证用户的身份，并颁发一个身份验证令牌（ID Token）和一个访问令牌（Access Token）给客户端。
客户端使用 ID Token 验证用户的身份，并使用 Access Token 来访问受保护的资源。
OIDC 提供了一种安全且开放的方式来实现身份验证和授权，使得用户可以使用其现有的身份提供者进行登录，并让客户端应用程序以授权的方式访问用户的受保护资源。它广泛应用于各种类型的应用程序，包括 Web 应用程序、移动应用程序和 API 服务。
2.3 JWT
JWT（JSON Web Token）是一种用于在网络应用间安全传输信息的开放标准（RFC 7519）。它是一种基于 JSON 的令牌，由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。
头部（Header）包含了关于令牌的元数据和加密算法的信息，通常是由两部分组成：令牌的类型（即 JWT）和所使用的加密算法（例如 HMAC SHA256 或 RSA）。
载荷（Payload）包含了有关用户或实体的声明（Claim），以及其他需要传输的数据。载荷中的声明可以是预定义的标准声明，例如 iss（发布者）、exp（过期时间）和 sub（主题），也可以是自定义的声明。
签名（Signature）是对头部和载荷进行签名的结果，以确保令牌的完整性和验证令牌的来源。签名使用头部中指定的加密算法和密钥进行计算。
JWT 的主要优点是它是自包含的，即令牌本身包含了所有必要的信息，不需要在服务器端存储会话状态。这使得 JWT 非常适用于分布式系统和无状态的 API 认证。
在使用 JWT 进行身份验证时，当用户进行登录或进行身份验证时，服务器会生成一个 JWT 并将其返回给客户端。客户端将在每个后续请求中将 JWT 包含在请求头或请求参数中。服务器可以通过验证 JWT 的签名和有效期来验证请求的合法性，并从令牌的载荷中获取有关用户或实体的信息。
总结起来，JWT 是一种用于在网络应用间安全传输信息的令牌，它包含了头部、载荷和签名，可以用于身份验证和授权等场景。
3 Identity Server 4
3.1 什么是 Identity Server 4
Identity Server 4 （Demo）是一个开源的身份和访问控制解决方案，用于构建安全的认证和授权系统。它基于 OpenID Connect 和 OAuth 2.0 协议，并提供了完整的身份验证和授权流程。
Identity Server 4 具有以下特点和功能：
身份验证和授权：Identity Server 4 充当认证服务器和授权服务器，负责验证用户的身份和颁发访问令牌。它支持多种身份验证方式，包括用户名密码、外部身份提供者（如 Google、Facebook 等）和多因素身份验证。
单点登录（SSO）：Identity Server 4 支持单点登录，允许用户在通过身份验证后访问多个受保护的资源，而无需再次输入用户名和密码。
客户端管理：Identity Server 4 提供了一个管理界面，用于管理客户端应用程序和其访问权限。管理员可以配置客户端的访问范围、重定向 URI 和授权类型等。
用户管理：Identity Server 4 允许管理员管理用户和用户组，包括创建、删除和编辑用户的属性。它还提供了用户注册和密码重置的功能。
API 保护：Identity Server 4 可以用于保护 API 资源，只允许经过身份验证和授权的客户端访问。它支持基于角色和声明的访问控制。
扩展性和定制化：Identity Server 4 具有良好的扩展性，可以通过插件和扩展点来自定义和扩展其功能。开发人员可以根据自己的需求添加自定义逻辑和业务规则。
Identity Server 4 是一个功能强大且灵活的身份和访问控制解决方案，适用于各种类型的应用程序和系统，包括 Web 应用程序、移动应用程序和 API 服务。它提供了一种安全且可扩展的方式来实现身份验证和授权，保护应用程序和资源的安全性。
3.2 Ids4 不同模式
Identity Server 4 提供了多种模式和使用场景，以满足不同类型的应用程序和系统的需求。以下是一些常见的模式和对应的使用场景：
单页应用程序（Single-Page Application，SPA）模式：适用于使用 JavaScript 框架（如 Angular、React、Vue.js 等）构建的前端应用程序。SPA 模式通过使用 OpenID Connect 和 OAuth 2.0 协议，将认证和授权逻辑移到前端，以提供更流畅的用户体验。
传统 Web 应用程序模式：适用于传统的服务器端渲染的 Web 应用程序。在这种模式下，Identity Server 4 负责处理用户的身份验证和授权请求，并生成认证和授权令牌。Web 应用程序可以使用这些令牌来保护受限资源。
移动应用程序模式：适用于移动应用程序，如 iOS 和 Android 应用程序。在这种模式下，移动应用程序通过 OAuth 2.0 协议进行身份验证和授权，并使用访问令牌来访问受限资源。Identity Server 4 提供了适用于移动应用程序的安全性最佳实践和指南。
API 保护模式：适用于保护 API 资源的场景。在这种模式下，Identity Server 4 充当授权服务器，为客户端应用程序颁发访问令牌，并验证这些令牌以授权对受限资源的访问。API 保护模式可用于构建微服务架构和提供 API 访问控制。
混合模式：适用于需要同时支持多种应用程序类型的场景，如 Web 应用程序、移动应用程序和 API。混合模式结合了不同的身份验证和授权流程，以满足不同类型的客户端应用程序的需求。
以上只是一些常见的模式和使用场景，Identity Server 4 还提供了许多其他功能和扩展点，以满足更复杂和特定的需求。开发人员可以根据自己的具体情况选择适合的模式和配置。
4（Ids4 详细介绍及 DEMO 未完待更......）
5 SSO（单点登录）
版权声明: 本文为 InfoQ 作者【青柚1943】的原创文章。
原文链接:【http://xie.infoq.cn/article/212a3f65eee817d7e371e55b8】。文章转载请联系作者。
生命不息，代码不止。 2020-08-04 加入
老街坊，小弄堂，是属于那年代白墙黑瓦的淡淡的忧伤。
评论