第八节：理解认证和授权、Oauth2.0及四种授权模式、OpenId Connect

一. 认证和授权

1. 身份验证

　　指当客户端访问服务端资源时，验证客户端是否合法的一种机制. eg: Core MVC中通过 app.UseAuthentication() 开启。最常见的是通过 用户名和密码，来验证您的身份。

2. 授权

　　指当客户端经过身份认证后，能够有限的访问服务端资源的一种机制. eg: Core MVC中通过 app.UseAuthorization() 开启。授权发生在系统成功验证您的身份后，最终会授予您访问资源（如信息，文件，数据库，资金，位置，几乎任何内容）的完全权限。简单来说，授权决定了您访问系统的能力以及达到的程度。验证成功后，系统验证您的身份后，即可授权您访问系统资源。

二者比较：

举一个容易理解的例子：

　　用户ypf要去博客网站发帖子，要通过输入账号：admin 密码：123456，进行登录，博客系统后台验证 admin 123456的账号和密码的合法性， 验证账号和密码合法后，然后要赋予该账号权限，比如：可以发博客，查看博客，但不能删除博客，这个过程就是“身份认证”； 然后该用户去删除博客，系统要判断该用户是否有这个权限，这就是“授权”。

3. 常见的身份认证和授权方式

(1). Base认证

　　Base64编码认证,Base64是可编译的.

(2). Digest认证

　　MD5加密

(3). Bearer认证

　　就是基于token认证，将用户信息等其他信息转换成为token，然后以token进行认证，token认证是一种无状态的认证方式，能够无限扩展，特别适合做单点登录。基于Token的主流方式有两种：A. OAuth 2.0  ，B. JWT身份认证 

Token分两种类型：

　①. 引用类型的token(OAuth 2.0),不包含任何用户信息

　②. 自包含token(jwt)，包含用户信息,但不要在里面存储一些敏感的信息哦

　　在实际微服务项目中,为了保证系统统一登录(SSO),使用OpenID协议标准来规范身份认证功能,同时使用OAuth 2.0协议标准来规范权限访问,为了将身份认证和授权结合起来，诞生了OpenID Connect协议标准。

OpenID Connect = OpenID + OAuth 2.0， 而IDS4恰恰是基于OpenID Connect协议标准的身份认证和授权程序。

 

二. Oauth2.0简介

1. 生活中的例子

(1). 背景

　　每个小区都有门禁系统，小区业主进入的时候可以：【刷卡】【人脸识别】【输入密码】等方式，现在很多年轻人喜欢点外卖，因为门禁的存在，外卖骑手是不能进入小区的，这个时候业主还不想出去拿，但是如果告诉骑手密码，以后骑手都能进入了小区，很不安全，除非业主主动改密码。

　　这个时候我们迫切的需要改进一下门禁系统，可以给外卖骑手进行临时授权。

(2). 解决方案

　A. 骑手在门禁系统上，呼叫业主，报备基本信息，供业主确认。

　B. 业主在App上授权骑手的授权申请，点击同意，会产生一个令牌，即一串数字，把这个数字告诉骑手。

　C. 骑手在门禁系统中输入这个令牌，即可进入小区。

PS. 令牌是有有效期的，而且业主可以随时取消。

分析：这里小区相当于【资源服务器】，外卖骑手相当于【第三方应用】，【我】授权【外卖骑手】一个令牌，【外卖骑手】通过令牌可以进入【小区】。

2. 互联网例子

经典例子：某博客网站支持用户使用QQ登录。

　　用户：也就是资源持有者，也就是我，比如：ypf

　　第三方应用：博客网站。

　　服务器提供商：QQ

QQ登录的时候，该【博客网站】希望得到关于【我】的一些【QQ信息(比如：昵称和头像)】，这个时候【我】不能直接把用户名和密码给【第三方应用(博客网站)】，这个时候我要授权【博客网站】到【QQ认证服务器】拿令牌，拿到令牌以后，向【QQ资源服务器】申请获取昵称和头像等信息。

PS：

(1). QQ认证服务器 和 QQ资源服务器 可能是同一台服务器，也可能是不同服务器。

(2). 用户在授权第三方应用拿信息的时候通常是需要自己输入账号和密码的，这个不是给第三方应用的。

 

3. Oauth 2.0的相关概念

(1). 含义

　　OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，“第三方应用"无需知道用户的账号及密码，就可获取到用户的授权信息，OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。

(2). 专用名词：

　A.Third-party application：第三方应用程序，本文中又称"客户端"（client），即上面的【博客网站】。

　B.HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上面的 【QQ服务】。

　C.Resource Owner：资源所有者，本文中又称"用户"（user）。

　D.User Agent：用户代理，比如：浏览器。

　E. Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器，即上面的【QQ认证服务器】。

　F. Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器，即上面的【QQ资源服务器】。

 

4. Oauth 2.0的思路和运行流程

(1). 思路　　

　　OAuth2.0 在【第三方应用】与【服务提供商】之间，设置了一个授权层（authorization layer）。【第三方应用】不能直接登录【服务提供商】，只能登录授权层，以此将【用户】与【第三方应用】区分开来。【第三方应用】登录授权层所用的令牌（token），与【用户】的密码不同。【用户】可以在登录的时候，指定授权层令牌的权限范围和有效期。

　【第三方应用】登录授权层以后，【服务提供商】根据令牌的权限范围和有效期，向【第三方应用】开放用户储存的资料。

(2). 运行流程

 

步骤：

（A）用户打开【第三方应用】以后，【第三方应用】要求用户给予授权。

（B）用户同意给予【第三方应用】授权。

（C）【第三方应用】使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对【第三方应用】进行认证以后，确认无误，同意发放令牌。

（E）【第三方应用】使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向【第三方应用】开放资源。

PS. 上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

 

5. Oauth2.0的四种授权模式

　(1). 客户端模式

　(2). 密码模式

　(3). 简化模式（也叫：隐式模式）

　(4). 授权码模式 

其中，其中授权码模式是步骤流程最为详细严谨的一种模式，而网络上大部分的第三方Oauth2实现都是基于授权码模式的。

 

三. Oauth2.0的四种授权模式

 这里也可以放在后面结合IDS4的每个章节代码来详细介绍。

 

 

四. OpenId Connect简介

1. 简介　

　　OpenID Connect是基于Oauth 2.0规范族的可互操作的身份验证协议。它使用简单的REST / JSON消息流来实现，和之前任何一种身份认证协议相比，开发者可以轻松集成。OpenID Connect允许开发者验证跨网站和应用的用户，而无需拥有和管理密码文件。OpenID Connect允许所有类型的客户，包括基于浏览器的JavaScript和本机移动应用程序，启动登录流动和接收可验证断言对登录用户的身份。

2. 历史　

　　OpenID Connect是OpenID的第三代技术。首先是原始的OpenID，它不是商业应用，但让行业领导者思考什么是可能的。OpenID 2.0设计更为完善，提供良好的安全性保证。然而，其自身存在一些设计上的局限性，最致命的是其中依赖方必须是网页，但不能是本机应用程序；此外它还要依赖XML，这些都会导致一些应用问题。

　　OpenID Connect的目标是让更多的开发者使用，并扩大其使用范围。幸运的是，这个目标并不遥远，现在有很好的商业和开源库来帮助实现身份验证机制。

3. OIDC基础

　　OIDC是一种安全机制，用于应用连接到身份认证服务器（Identity Service）获取用户信息，并将这些信息以安全可靠的方法返回给应用。在最初，因为OpenID1、OpenID2经常和OAuth协议（一种授权协议）一起提及，所以二者经常被搞混，这里澄清解释一下：

(1). OpenID: 是Authentication，即认证，对用户的身份进行认证，判断其身份是否有效，也就是让网站知道“你是你所声称的那个用户.

(2). OAuth:是Authorization，即授权，在已知用户身份合法的情况下，经用户授权来允许某些操作，也就是让网站知道“你能被允许做那些事情”。 由此可知，授权要在认证之后进行，只有确定用户身份只有才能授权。

　　OpenID Connect是“认证”和“授权”的结合，因为其基于OAuth协议，所以OpenID-Connect协议中也包含了client_id、client_secret还有redirect_uri等字段标识。这些信息被保存在“身份认证服务器”，以确保特定的客户端收到的信息只来自于合法的应用平台。这样做是目的是为了防止client_id泄露而造成的恶意网站发起的OIDC流程。

(OpenID+ OAuth 2.0 = OpenID Connect)

4. OIDC流程

　　Oauth2.0 提供了Access Token来解决授权第三方客户端访问受保护资源的问题；相似的，OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。OIDC的核心在于在OAuth2.0 的授权流程中，一并提供用户的身份认证信息（ID-Token）给到第三方客户端，ID-Token使用JWT格式来包装，得益于JWT的自包含性，紧凑性以及防篡改机制，使得ID-Token可以安全的传递给第三方客户端程序并且容易被验证。应有服务器，在验证ID-Token正确只有，使用Access-Token向UserInfo的接口换取用户的更多的信息。

　　有上述可知，OIDC是遵循OAuth协议流程，在申请Access-Token的同时，也返回了ID-Token来验证用户身份。

5. 三种流程

(1). 如果是JS应用，其所有的代码都会被加载到浏览器而暴露出来，没有后端可以保证client_secret的安全性，则需要是使用默认模式流程(Implicit Flow)。

(2). 如果是传统的客户端应用，后端代码和用户是隔离的，能保证client_secret的不被泄露，就可以使用授权码模式流程（Authentication Flow）。

(3). 此外还有混合模式流程(Hybrid Flow)，简而言之就是以上二者的融合。

 (PS: 未完，待补充)

 

 

 

　　参考文章：http://www.ruanyifeng.com/blog/2019/04/oauth_design.html     

　　　　　　　https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

                 

 

 

 

!

• 作       者 : Yaopengfei(姚鹏飞)
• 博客地址 : http://www.cnblogs.com/yaopengfei/
• 声     明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
• 声     明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。