我眼中的认证与授权

区别

OpenId: Authentication :认证
Oauth: Aurhorize :授权

输入账号密码，QQ确认输入了正确的账号密码可以登录 —>认证
下面需要勾选的复选框（获取昵称、头像、性别）----->授权

OpenID

当你需要访问A网站的时候,A网站要求你输入你的OpenId,即可跳转到你的OpenId服务网站,输入用户名和密码之后,再调回A网站，则认证成功。
OAuth2.0

OAuth是一个关于授权的开放网络协议,允许用户让第三方应用访问该用户在在某一网站上的资源，而无需提供用户名和密码给第三方。

用户打开客户端以后，客户端要求用户给予授权。
用户同意给予客户端授权。
客户端使用上一步获得的授权，向认证服务器申请令牌。
认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
客户端使用令牌，向资源服务器申请获取资源。
资源服务器确认令牌无误，同意向客户端开放资源。
客户端必须得到用户的授权，才能获取令牌。OAuth2.0定义了四种授权方式：
授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）

客户端模式（client credentials）

    **引 https://www.cnblogs.com/kaleidoscope/p/9507261.html**

OpenID --(OpenID Connect) 简称OIDC

OpenID Connect是OpenID的升级版，简称OIDC，是2014年初发布的开放标准，定义了一种基于OAuth2的可互操作的方式来来提供用户身份认证。在OIDC中，应用程序不必再为每个客户端构建不同的协议，而是可以将一个协议提供给多个客户端，它还使用了JOSN签名和加密规范，用来在传递携带签名和加密的信息，并使用简单的REST/JSON消息流来实现，和之前任何一种身份认证协议相比，开发者都可以轻松的集成。简单说 OIDC是在OAuth2.0之上的一个扩展

ID Tokens
OpenID Connect Id Token是一个签名的JSON Web Token（JWT：RFC7519），它包含一组关于用户身份的声明（claim），如：用户的标识（sub）、颁发令牌的提供程序的标识符（iss）、创建此标识的Client标识（aud），还包含token的有效期以及其他相关的上下文信息
Access Tokens
访问令牌允许访问API资源。 客户端请求访问令牌并将其转发到API。 访问令牌包含有关客户端和用户的信息（如果存在）。 API使用该信息来授权访问其数据。
UserInfo Endpoint
OIDC还提供了一个包含当前用户信息的标准的受保护的资源。UserInfo Endpoint不是身份认证的一部分，而是提供附加的标识信息，它提供了一组标准化的属性：比如profile、email、phone和address。OIDC中定义了一个特殊的openidscope，并且是必须的，它包含对Id token和UserInfo Endpoint的访问权限。
IdentityServer4

现在的应用开发层出不穷，基于浏览器的网页应用，基于微信的公众号、小程序，基于IOS、Android的App，基于Windows系统的桌面应用和UWP应用等等，这么多种类的应用，就给应用的开发带来的挑战，我们除了分别实现各个应用外，我们还要考虑各个应用之间的交互，通用模块的提炼，其中身份的认证和授权就是每个应用必不可少的的一部分。而现在的互联网，对于信息安全要求又十分苛刻，所以一套统一的身份认证和授权就至关重要。

**IdentityServer4就是这样一个框架，IdentityServer4是为ASP.NET CORE量身定制的实现了OpenId Connect和OAuth2.0协议的认证授权中间件。**

JwtBearer 认证

HTTP提供了一套标准的身份验证框架：服务器可以用来针对客户端的请求发送质询(challenge)，客户端根据质询提供身份验证凭证。质询与应答的工作流程如下：服务器端向客户端返回401（Unauthorized，未授权）状态码，并在WWW-Authenticate头中添加如何进行验证的信息，其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进行验证，其Value为身份验证的凭证信息。

Bearer认证（也叫做令牌认证）是一种HTTP认证方案，其中包含的安全令牌的叫做Bearer Token。因此Bearer认证的核心是Token。那如何确保Token的安全是重中之重。一种方式是使用Https，另一种方式就是对Token进行加密签名。而JWT就是一种比较流行的Token编码方式。
JWT（Json Web Token)

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC
7519）。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT有三部分组成：

..

https://jwt.io/

Header：由alg和typ组成，alg是algorithm的缩写，typ是type的缩写，指定token的类型。该部分使用Base64Url编码。
Payload：主要用来存储信息，包含各种声明，同样该部分也由BaseURL编码。
Signature：签名，使用服务器端的密钥进行签名。以确保Token未被篡改。
ASP.NET授权认证（OWIN、Katana）
ASP.NET

现有的的asp.net是成熟且功能丰富的运行时和开发人员编程模型,同时这个框架已整体式，各种不同逻辑的功能单元都紧密耦合在System.web.dll程序集中。作为更大的.NET Framework更新周期基本以年为单位。开发团队采用了几个进化步骤将ASP.NET作为可插入的一系列组件而不是单一框架。

为满足Mvc样式的开发需求,ASP.NET MVC发布，作为独立下载，这使得工程团队可以更频繁的交付更新。

从动态的，由服务器生产Web pages转变为通过AJAX请求方式与后端Web APi通信。随着ASP.NETMVC的发布，构建了ASP.NET WEBAPI,使其不依赖System.Web.dll,其次不依赖IIS等，包含在自定义主机中运行的功能。
**OWIN**

OWIN定义了.NET Web服务器和Web应用程序之间的标准接口。OWIN接口的目标是分离服务器和应用程序。
**Katana**

用于Microsoft服务器和框架的OWIN实现
**优势**

可移植
灵活采用模块化结构
轻型、高性能、可缩放

结构

HOST（主机）：负责应用程序的配置和启动进程，包括初始化Owin Pipeline、运行Server。
Server(服务):实际的HTTP Server。监听HTTP请求,然后将请求和响应等封装为Owin规范的字典发送到Owin Middleware 管道中。
Middleware(中间件)：中间件位于服务和应用程序质检，用来处理管道中的请求，可以是任何自定义委托的组件。例如：Logger,Web API.

**Application(应用程序):具体的应用程序代码。
Owin OAuth**