这里笔者会尽力从源头上办理对付干系观点的理解，以及在项目中的实践。并且收录部分口试过程中会碰着的问题。
旨在办理干系职员对付观点的深入理解，对付项目的实践认识，对付口试的关键点阐发。单个篇幅无法做到面面俱到，尽力估计，过程中会供应 Java、C Sharp 的代码阐明。
在本篇文章中，会讲到如下内容：
在维基百科中对付 OAuth 的阐明如下：
开放授权（OAuth）是一个开放标准，许可用户让第三方运用访问该用户在某一网站上存储的私密的资源（如照片、视频、联系人列表），而无需将用户名和密码供应给第三方运用。
OAuth 许可用户供应一个令牌，而不是用户名和密码来访问他们存放在特定做事供应者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站）在特定的时段（例如，接下来的 2 小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth 让用户可以授权第三方网站访问他们存储在其余做事供应者的某些特定信息，而非所有内容。
OAuth 是 OpenID 的一个补充，但是完备不同的做事。
在百度百科中对付 OAuth 的阐明如下：
OAuth 协议为用户资源的授权供应了一个安全的、开放而又大略单纯的标准。与以往的授权办法不同之处是 OAuth 的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需利用用户的用户名与密码就可以申请得到该用户资源的授权，因此 OAuth 是安全的。OAuth 是 Open Authorization 的简写。
在 OAuth 2.0 的官方网站中的阐明如下（摘自：https://oauth.net/）：
An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
在 IETF 组织中的对付 OAuth 2.0 Authorization Framework 对应的择要描述如下：
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.
通过这几个方面的查看，可以明确的肃清对付 OAuth 的缺点认识，OAuth 不是一个技能框架，也不是一个 jar 包，也不是一个 dll 程序集，它仅仅是一个 protocol，被翻译为协议、标准、或者规则。这只是对付 OAuth 的一个宏不雅观认识。
在 oauth.net 中的简介可以理解到，OAuth 2.0 是许可通过利用大略标准的方法从 Web、移动和桌面运用程序中进行安全授权的开放协议。
OAuth 的历史版本中有 OAuth 1.0 和 OAuth 2.0，个中 OAuth 1.0 在 2010 年揭橥为 RFC5849，OAuth 2.0 为 RFC6749，并且 OAuth 2.0 不向下兼容 OAuth 1.0，目前 OAuth 2.0 被广泛利用，因此这里不再对 OAuth 1.0 进行更多的描述。
上面是对 OAuth 以及 OAuth 2.0 的宏不雅观认识，下面对于 OAuth 2.0 包括的几种办法进行先容。
（图片来自 tools.ietf.org 的截图）
如图所示，在 RFC6749 可以得到最官方的几种授权类型：
Authorization Code Grant，授权码付与类型Implicit Grant，隐私付与类型Resource Owner Password Credentials Grant，用户密码凭据付与类型Client Credentials Grant，客户端付与类型Extension Grant，其他可以根据详细情形进行扩展的类型这也是 OAuth 2.0 差异于 OAuth 1.0 的地方，OAuth 2.0 中事情组所作出的明确决定是，它不再是一个单个协议，而是一个框架。从名字上也可以看出来，1.0 是 protocol，而 2.0 的标题是 framework。
授权码付与类型授权码类型是目前 OAuth 2.0 中最常用，最安全的一种类型。通过去授权端获取授权码，利用授权码换取 token，通过利用 token 去资源做事器获取受保护资源。
以阿里云的内容协作平台 CCP 的官方文档为实例：
（图片引用 help.aliyun.com/）
隐式授权类型Implicit Grant 有的地方被翻译成大略授权，但是笔者认为翻译成大略授权有点偏离原有的意思。它只是针对授权码的环节做了一定简化，但是它的利用并不能被视为大略的授权类型。
授权码流程的不同步骤的关键之处，在于能够保持不同组件之间的分离，浏览器不知道客户端该当知道的内容，客户端无法获取到浏览器的状态。但是，如果把客户端放到浏览器中，该怎么办呢？这种情形在目前的 SPA 单页面运用程序中常常会涌现。客户端实行的所有过程，由于都是基于浏览器实现的，以是险些相称于在浏览器上裸奔。
（图片引用 OAuth 2.0 in Action）
利用这种方法，没有现实的方法来保护客户真个密码信息，由于它须要对付浏览器可用才能实行后续流程。
隐式付与流程不能用于获取刷新令牌，由于基于浏览器的运用基本上都是短时的连接，仅持续加载它们的浏览器的高下文的会话长度，因此，刷新令牌的用场非常有限。
与其他付与类型不同，可以假定资源所有者仍处于浏览器中，并在必要的时候可用于重新授权客户端。授权做事器仍能够运用首次利用信赖（TOFU）原则从而使重新认证成为无缝的用户体验。
以阿里云的内容协作平台 CCP 的官方文档为实例：
（图片引用 help.aliyun.com）
客户端凭据授权类型（图片引用 OAuth 2.0 in Action）
在 RFC 中是这么进行描述的：
（图片引用：tools.ietf.org）
实际上是一个道理，只是表现形式轻微有一点不同而已。客户端直接对它自己进行验证，然后授权做事器颁发适当的令牌。
资源所有者付与类型（图片引用 OAuth 2.0 in Action）
通过利用 Resource Owner 的用户名和密码来换取令牌，这种办法一样平常是不提倡利用的，缘故原由是当用户名和密码暴露出来的时候，就自然会导致攻击面变得更大，风险更高。
在上述几种 Grant Type 中的 Client，它并不能被大略的理解为浏览器或者桌面运用，在 OAuth 中，只要软件利用受保护资源上的 API，那么它就被视为客户端。
以上便是对付 OAuth 的解释，以及 OAuth 2.0 framework 中涉及到的几种类型的图示和描述，以及在实际场景中的运用流程。
对付代码 OAuth 2.0 的详细实现过程，由于每一个环节都涉及很多内容，不在编码过程中消化就会很难明得，后续将会在专栏中进行详细过程的阐发。这里通过观点的引入和宏不雅观的理解，肃清平时事情过程中对付观点的缺点认识。
SSO 的解释和运用SSO，single sign on 单点登录，单点登录为用户供应无缝的身份验证体验。在构建的运用程序中，一旦登录这些运用程序中的一个，当利用其他运用程序的情形下，不须要再次登录。反之，在登出的过程中，只要一个运用程序登出，那么所有运用对应的登录状态全是登出。
这便是 SSO，单点登录的基本含义。
CASCAS，Central Authentication Service，集中式身份验证。SSO 和 CAS 是密不可分的，SSO 可以理解为一个软件系统，而 CAS 是作为实现 SSO 的一种办理方案。更准确的来说，它是一个规范性子的协议。
（图片引自 apereo.github.io 截图）
对应的 C sharp 的源码可以参考如下的 GitHub 源码，地址为：
https://github.com/apereo/dotnet-cas-client
对应 Java 的源码可以参考如下 GitHub 的源码，地址为：
https://github.com/apereo/cas
JWT 和授权的关系首先要知道的可能是 JWT 是什么？这个观点在很多地方，要么是没有被阐明，要么是被结合场景利用的阐明，偏离了它本身的观点。那么参考 IETF 的解释来对 JWT 的实质进行认识：（引自：tools.ietf.org/）
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
从择要中的描述基本可以明确，JWT 仅仅是在于两个部分之间进行传输声明的一种 compact 和 url-safe 的办法。
compact 是指针对付体积上，通过 JWT 进行署名和加密的结果体积比较小，在传输过程中减少带宽的负载。
url-safe 是指针对对应的加密算法，在加密和解密的构造上，相对来说 JWT 处理的信息更加安全。
它能够防止一定程度的攻击，如下情形。
情形 1：
如果在 HTML 中一样可以轻松地植入，比如：
将上图中的某一个 img 标签对应 i 的的 src 属性进行更换就会改变实行的要求，导致如下图中的修正：
可以看到，jwt.io 在这种大略的操作中，对应的 logo 就被更换掉了，如果换得 URL 不是一个图片，而是一个关于用户/权限/或者支付的业务，那结果是很恐怖的。
有很多人对 CSRF（cross-site request forgery）没有明确的观点，上面的这个例子，就能大略的证明 CSRF 带来的危害。
情形 2：
如果写在 cookie 里，可以很容截获，比如下：
在浏览器中通过 F12 弹出的开拓者工具中，选择 Application 左侧的 Cookie 选项，双击右侧的键值对就可以修正，这种办法会导致 cookie，或者 local storage 中存入的信息被透露或者修正。
但是对付跨站脚本的攻击，依然起不到浸染，也便是 XSS（Cross-Site Scripting），通过脚本注入可以像浏览器中植入脚本对 cookie/local storage 中的信息进行获取或者修正。详细办法就不再解释（考虑到被恶意利用进行攻击，这里只须要知道会涌现这种情形）
其余对付 JWT 还有一个常见的缺点认识：
可能有些同学会认为，在 http://jwt.io 上利用的时候会认为，既然可以 encode，也可以 decode，那么这种情形下，对付署名和验签还有什么意义。
但是实际上并不是我们想象的那样，在利用 secret 署名过后，在验签的时候，secret 是无法被反向解析出来的。
如下：
1. header
{ "alg": "HS256", "typ": "JWT"}
2. payload
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022}
3. secret
test
4. encode 后的内容：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA
用点符号和换行符变成易读格式：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA
上述过程是编码的过程，下面不雅观察解码的过程：
1. 清空 decoded 下的对应信息
2. 将上述编码后的内容，放到 encoded 下的文本框
加上 secret 后才能够完成署名的验证。这种情形下意味着，如果获取到 token 的恶意用户，纵然窃取信息后再次发送，修正任何一个参数，都无法精确的进行验签。
以是很主要的一点，便是 signature 的署名，如果没有密钥的话，是无法进行可逆解析的，否则这个署名过程就没故意义了。
对付 JWT 的进一步认识可以参考如下开源代码：
https://github.com/jwt-dotnet/jwt
https://github.com/dvsekhvalnov/jose-jwt
比较于官方供应的 jose-jwt 的 .NET 版本，Jwt.Net 的封装相对来说利用起来，要轻微麻烦一点，但是它的上风在于对 .NET CORE 和 .NET OWIN 有对应的扩展。而 jose-jwt 供应的只有加密和解密的过程。
但是个人认为相对来说，官方供应的源码更加有助于对 JWT，以及干系标准进行理解。而且供应的源码不局限于 .NET。
以上便是对付 JWT 的基本信息的一些理解息争释。它和授权的关系并没有直接关系，只是在授权过程中，比如在 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens draft-ietf-oauth-access-token-jwt-03 中就将 access tokens 和 JWT 进行了却合。
（图片引用自：tools.ietf.org 的截图)
C Sharp 的 OWIN 中间件这里提到的 OWIN 中间件，是在 C# 进行 OAuth 2.0 环境的搭建过程中利用的中间件，对付它的基本先容如下：
利用 OAuth 2.0 framework，第三方运用可以得到对 HTTP 做事的有限访问权限。客户端不该用资源所有者的凭据来访问受保护的资源, 而是获取一个访问令牌（表示特定例模、生存期和其他访问属性的字符串）。授权做事器将访问令牌颁发给第三方客户端，并批准资源所有者。
OWIN 定义 .NET Web 做事器和 Web 运用程序之间的标准接口。 OWIN 接口的目标是将做事器和运用程序分离，鼓励开拓大略的 .NET Web 开拓模块，并通过作为开放标准来鼓励 .NET Web 开拓工具的开源生态系统。
来自：
https://docs.microsoft.com/zh-cn/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
在 NuGet 办理方案中搜索Microsoft.Owin.Security.OAuth
从图中右侧标注的红框部分，可以看到对应的 GitHub 上的源码，对详细的过程进行阐发。比如：
用户信息赋值的关键点，在这里对 token 进行验证，如果验证不通过的情形之下，将无法通过：
在开拓过程中可能还会碰着问题便是纵然所有的地方都配置好了，但是去世活验证不通过，缘故原由是依赖的 dll 没有引入完全，但是也没有报错，导致的。参考下面的图中对应的 dll。
口试题OAuth 2.0 是不是身份认证协议OAuth 2.0 中有哪几种授权类型授权码授权于隐式授权类型之间的差异CAS 与 SSO 之间存在什么样的关系
对付这几个问题，在上述内容中均能够找到答案。
很多知识点在总结的过程中创造，一个篇幅不能够面面俱到，尤其对付授权和认证的详细实现过程，不同实现办法的特点，为了能够有详细的可操作的办理方案，后续会总结出详细过程步骤以专栏的形式分章节列出。有不敷的地方欢迎示正。
