Oauth2系列2：授权码模式
Posted kobe_t
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Oauth2系列2：授权码模式相关的知识，希望对你有一定的参考价值。
目录
传送门
在前面一节，对oauth2有了一个初步概念。这里重点讨论下授权码模式
再次重申oauth2的定义
定义
前面对oauth2的定义有过百科的引用，英文好的也可以看看官方定义：OAuth 2.0。这里不是要对定义做过多理解，而是重点放在下面的场景下的讨论中
作用
oauth2通常是用来做第三方应用授权的，比如前面的微信例子：网站应用微信登录开发指南
多读几遍上面的一句话，会不会发现有一些矛盾？
oauth2不是用来做授权吗，为什么微信用它来做第三方登录呢？带着这个疑问，再次回顾一下下面这个微信登录时序图
再看一下微信官方给出的步骤解释
1. 第三方发起微信授权登录请求，微信用户允许授权第三方应用后，微信会拉起应用或重定向到第三方网站，并且带上授权临时票据 code 参数； 2. 通过 code 参数加上 AppID 和AppSecret等，通过 API 换取access_token； 3. 通过access_token进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。
通过上面的时序图，及步骤解释，都提到了"微信用户"，就是说要应用微信登录第三方应用，前提是用户必须是微信用户！
这个要求也是顺理成章的，用户都不是微信的，微信怎么对用户主体做属性授权呢？
但是需要思考一个问题，对于第三方网站来说，如果是微信用户，并且依赖微信的开放平台做了授权登录，那么对应三方应用来说，它自己到底存不存储用户相关信息呢？如果没有自己的用户信息，如果网站需要自己的权限管理，该怎么办？
微信授权登录，三方应用能获取的信息是有限的，可能只有用户相关的一点可怜的用户昵称，性别，头像等。其它一些信息，需要依赖开放平台的支持，这多少也有些受制于人！
所以，我个人觉得，对于三方网站的不同定位，如果需要自己做一些权限管控，或者是后续基于用户维度的功能，是需要有一套自己的账户体系的，只不过在用户使用方式止，可以做成是高阶功能再认证或补全身份信息的流程。此时的流程，大致如下
这个流程跟微信标准相比，就是加了后面几个步骤（第7步之后），主要就是第三方应用的账户处理
- 当用户通过微信oauth2协议登录成功之后，会拿到access_token，这个时候可以通过token获取用户授权的信息
- 拿到授权信息之后，可以采用生成临时游客账号的方式，将用户的vx_id与当前用户的临时游客账号绑定起来
- 这样，后续如果用户还是通过微信授权登录，也在第三方系统有了自己的账号，只不过这一步用户可能（也不一定需要感知）没有感知
- 等到用户要用到系统的高阶功能，比如一些增值服务，要付费或者实名认证这种，再让用户来补全身份信息或者进行实名认证
标准授权码流程
4个参与角色
上面我们看到微信第三方授权登录的时序图，一共有3个参与方：用户，第三方应用，vx开放平台。
其实严格意义来讲，标准的oauth2协议，总共有4个角色
资源拥有者
就是拥有资源的主体，在上面的登录场景中就是指微信用户，所有的用户信息都是属于他的。当然，资源不一定是只有用户信息，也可能是任何能授权的数据（一切皆数据）。通常拥有者都是一个人，这个人才拥有数据
客户端
客户端，在上面的登录场景中就是指第三方应用，是需要申请资源权限的第三方应用
授权服务
授权服务就是对资源进行授权的系统，在上面的登录场景中就是指微信开放平台。在上面，大部分的核心逻辑都是在它在负责处理的：第三方应用身份检验，授权管理（生成授权页面，权限列表检验），生成授权码code及返回授权码code给第三方应用等，以及最终的令牌颁发等
受保护资源
受保护资源就是指可以用来授权的信息或数据，上面的登录场景中就是指用户的信息，比如姓名，性别，头像等
但是在微信登录的场景中，只有三个角色，并没有把受保护资源单独列出。因为微信开放平台本身就拥有用户的信息，所以是可以视为一体的。
但是在有些场景，受保护资源有可能是单独服务，是可以跟授权服务分开的。比如，在一些微服务架构中，授权服务有可能是放到网关来做的，而资源是在业务服务中的
授权码流程
OAuth 诞生之初就是为了解决 Web 浏览器场景下的授权问题，上面第三方微信登录，有可能是发生在PC端的浏览器，也有可能是移动端的APP应用上，而移动端的APP应用其实也可以视为一种浏览器。
而通常现在的客户端，一般是有前端界面与后端应用的，前端一般也是让用户在浏览器上面操作。
现在假设是在浏览器的场景下，一般授权码流程到底是怎么样的呢？来看一个更细致的流程
引导授权
正常来说，第三方业务系统都有自己的会话管理，就像在前面提到的传统session会话
对于java开发的系统，一般常用的会有server的过滤器Filter，通过session来判断用户会话是否过期，过期会引导用到登录界面进行登录认证。
对于ouath2这种协议作微信第三方登录认证，也是需要业务系统做会话管理的。就是用户第一次访问业务系统时，如果发现用户是未登录，则调用认证服务的接口，这个接口最终会生授权登录界面，让用户授权
第一步：请求CODE
第三方使用网站应用授权登录前请注意已获取相应网页授权作用域（scope=snsapi_login），则可以通过在 PC 端打开以下链接： https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect 若提示“该链接无法访问”，请检查参数是否填写错误，如redirect_uri的域名与审核时填写的授权域名不一致或 scope 不为snsapi_login。
当第三方系统请求这个接口时，微信会跳转到微信的一个标准授权界面。这就是时序图中的第一次重定向。这里要特别说明的是，业务系统一般也是通过重定向的方式请求这个接口的。可以前端js或者后端跳转：
- 前端：window.location.href='请求code的接口';
- 后端：response.sendRedirect("请求code的接口");
而其中的参数也是有讲究的
参数说明
| 参数 | 是否必须 | 说明 |
|---|---|---|
| appid | 是 | 应用唯一标识 |
| redirect_uri | 是 | 请使用 urlEncode 对链接进行处理 |
| response_type | 是 | 填code |
| scope | 是 | 应用授权作用域，拥有多个作用域用逗号（,）分隔，网页应用目前仅填写snsapi_login |
| state | 否 | 用于保持请求和回调的状态，授权请求后原样带回给第三方。该参数可用于防止 csrf 攻击（跨站请求伪造攻击），建议第三方带上该参数，可设置为简单的随机数加 session 进行校验 |
| lang | 否 | 界面语言，支持cn（中文简体）与en（英文），默认为cn |
- appid是应用的唯一标识，即要接入oauth2做授权登录，必须要先在微信开放平台进行注册，这一部分属于准备工作，会放到下一节里面介绍
- redirect_uri是在注册的填入的回调地址，也属于准备工作，会放到下一节里面介绍。这个地址，主要是用于微信开放平台生成授权码之后，会通过重定向的方式跳转到这个地址，所以必须跟业务系统一致
获取code
用户允许授权后，将会重定向到redirect_uri的网址上，并且带上 code 和state参数
redirect_uri?code=CODE&state=STATE- 所以上面配置的redirect_uri相当重要，理论上它就是第三方业务系统里面的一个接口，用来接收微信回传的code，而state是防csrf攻击的参数，业务系统可以通过它判断是否是自己发出的请求，如果不是，则可以拒绝此次访问
用授权码code换取令牌token
通过 code 获取access_token
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
如果第三方业务系统拿到授权码code，这个时候就可以通过code换取令牌了。如果令牌获取成功，就表示用户认证完成，可以登录了
注意，这个接口严格来说，必须是后端发起调用，因为这里面的参数除了appid之外，还需要secret参数，这个参数是不能暴露到浏览器的。
1、Appsecret 是应用接口使用密钥，泄漏后将可能导致应用数据泄漏、应用的用户数据泄漏等高风险后果；存储在客户端，极有可能被恶意窃取（如反编译获取Appsecret）； 2、access_token 为用户授权第三方应用发起接口调用的凭证（相当于用户登录态），存储在客户端，可能出现恶意获取access_token 后导致的用户数据泄漏、用户微信相关接口功能被恶意发起等行为； 3、refresh_token 为用户授权第三方应用的长效凭证，仅用于刷新access_token，但泄漏后相当于access_token 泄漏，风险同上。 建议将secret、用户数据（如access_token）放在 App 云端服务器，由云端中转接口调用请求。
参数说明
| 参数 | 是否必须 | 说明 |
|---|---|---|
| appid | 是 | 应用唯一标识，在微信开放平台提交应用审核通过后获得 |
| secret | 是 | 应用密钥AppSecret，在微信开放平台提交应用审核通过后获得 |
| code | 是 | 填写第一步获取的 code 参数 |
| grant_type | 是 | 填authorization_code |
- appid同上，后续会详细说明如何产生及设计
- secret是应用的密钥，理论上不能暴露出去的，它跟appid是一一对应的
- grant_type是授权码类型，这里默认定authorization_code，表示授权码类型。顾名思义，还有其它类型，后面会讨论其它类型
返回令牌格式
最后，看一下，返回令牌的格式
返回说明
正确的返回：
"access_token":"ACCESS_TOKEN", "expires_in":7200, "refresh_token":"REFRESH_TOKEN", "openid":"OPENID", "scope":"SCOPE", "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
在这里，会发现，除了刚才讨论的访问令牌access_token之外，还多了其它几个参数
| 参数 | 说明 |
|---|---|
| access_token | 接口调用凭证 |
| expires_in | access_token接口调用凭证超时时间，单位（秒） |
| refresh_token | 用户刷新access_token |
| openid | 授权用户唯一标识 |
| scope | 用户授权的作用域，使用逗号（,）分隔 |
| unionid | 当且仅当该网站应用已获得该用户的 userinfo 授权时，才会出现该字段。 |
- 其中，openid，跟unionid并不是oauth2协议的标准字段，而是不同开放平台单独的设计
- 而refresh_token，如果场景中不涉及续期这种，也可以不用到它。但是对于很多应用，尤其是APP端来说，用户基本都是长效登录，就是用户登录之后，可能一个月都是在线的，不需要重复登录，这时候就是极需要刷新令牌的
令牌续期
access_token是调用授权关系接口的调用凭证，由于access_token有效期（目前为2个小时）较短，当access_token超时后，可以使用refresh_token进行刷新，access_token刷新结果有两种：
1. 若access_token已超时，那么进行refresh_token会获取一个新的access_token，新的超时时间；
2. 若access_token未超时，那么进行refresh_token不会改变access_token，但超时时间会刷新，相当于续期access_token。
refresh_token拥有较长的有效期（30天），当refresh_token失效的后，需要用户重新授权。
请求方法
获取第一步的 code 后，请求以下链接进行refresh_token：
https://api.weixin.qq.com/sns/oauth2/refresh_token?appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
参数说明
| 参数 | 是否必须 | 说明 |
|---|---|---|
| appid | 是 | 应用唯一标识 |
| grant_type | 是 | 填refresh_token |
| refresh_token | 是 | 填写通过access_token获取到的refresh_token参数 |
- 可以看到在刷新令牌这里，grant_type填的是refresh_token；而在上面获取token接口，填入的是authorization_code。
- 这刷新令牌接口调用成功之后，对于访问令牌的处理，其它有不同的实现，有的开放平台是一定会生成一个新的access_token，有的会对它做续期，直到达到刷新令牌的生命周期。甚至有的平台会，生成一个新的刷新令牌。这个没有统一的做法，取决于不同的实现
预告
这一节主要讨论了授权码流程，但是各大开放平台，在使用第三方登录的oauth2协议时，都基本有一个准备工作，即要先进行注册。
下一节，会结合阿里云开放平台，看一下注册流程如何操作及背后的设计
IdentityServer4系列 | 授权码模式
一、前言
在上一篇关于简化模式中，通过客户端以浏览器的形式请求IdentityServer服务获取访问令牌，从而请求获取受保护的资源，但由于token携带在url中，安全性方面不能保证。因此，我们可以考虑通过其他方式来解决这个问题。
我们通过Oauth2.0的授权码模式了解，这种模式不同于简化模式，在于授权码模式不直接返回token，而是先返回一个授权码，然后再根据这个授权码去请求token。这显得更为安全。
所以在这一篇中，我们将通过多种授权模式中的授权码模式进行说明，主要针对介绍IdentityServer保护API的资源，授权码访问API资源。
二、初识
(图片来源网络)
指的是第三方应用先申请一个授权码，然后再用该码获取令牌，实现与资源服务器的通信。
看一个常见的QQ登陆第三方网站的流程如下图所示：
2.1 适用范围
授权码模式(authorization code)是功能最完整、流程最严密的授权模式。
授权码模式适用于有后端的应用，因为客户端根据授权码去请求token时是需要把客户端密码转进来的，为了避免客户端密码被暴露，所以请求token这个过程需要放在后台。
2.2 授权流程：
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------\' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------\'
+---------+ (w/ Optional Refresh Token)
授权码授权流程描述
（A）用户访问第三方应用，第三方应用将用户导向认证服务器；
（B）用户选择是否给予第三方应用授权；
（C）假设用户给予授权，认证服务器将用户导向第三方应用事先指定的重定向URI，同时带上一个授权码；
（D）第三方应用收到授权码，带上上一步时的重定向URI，向认证服务器申请访问令牌。这一步是在第三方应用的后台的服务器上完成的，对用户不可见；
（E）认证服务器核对了授权码和重定向URI，确认无误后，向第三方应用发送访问令牌(Access Token)和更新令牌(Refresh token)；
（F）访问令牌过期后，刷新访问令牌；
2.2.1 过程详解
访问令牌请求
（1）用户访问第三方应用，第三方应用将用户导向认证服务器
(用户的操作：用户访问https://client.example.com/cb跳转到登录地址，选择授权服务器方式登录)
在授权开始之前，它首先生成state参数(随机字符串)。client端将需要存储这个（cookie，会话或其他方式），以便在下一步中使用。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
HTTP/1.1 Host: server.example.com
生成的授权URL如上所述（如上），请求这个地址后重定向访问授权服务器，其中 response_type参数为code,表示授权类型，返回code授权码。
| 参数 | 是否必须 | 含义 |
|---|---|---|
| response_type | 必需 | 表示授权类型，此处的值固定为"code" |
| client_id | 必需 | 客户端ID |
| redirect_uri | 可选 | 表示重定向的URI |
| scope | 可选 | 表示授权范围。 |
| state | 可选 | 表示随机字符串,可指定任意值，认证服务器会返回这个值 |
（2）假设用户给予授权，认证服务器将用户导向第三方应用事先指定的重定向URI，同时带上一个授权码
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
| 参数 | 含义 |
|---|---|
| code | 表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。 |
| state | 如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。 |
（3）第三方应用收到授权码，带上上一步时的重定向URI，向认证服务器申请访问令牌。这一步是在第三方应用的后台的服务器上完成的，对用户不可见。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
| 参数 | 含义 |
|---|---|
| grant_type | 表示使用的授权模式，必选项，此处的值固定为"authorization_code"。 |
| code | 表示上一步获得的授权码，必选项。 |
| redirect_uri | 表示重定向URI，必选项，且必须与步骤1中的该参数值保持一致。 |
| client_id | 表示客户端ID，必选项。 |
（4）认证服务器核对了授权码和重定向URI，确认无误后，向第三方应用发送访问令牌(Access Token)和更新令牌(Refresh token)
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
| 参数 | 含义 |
|---|---|
| access_token | 表示访问令牌，必选项。 |
| token_type | 表示令牌类型，该值大小写不敏感，必选项，可以是Bearer类型或mac类型。 |
| expires_in | 表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 |
| refresh_token | 表示更新令牌，用来获取下一次的访问令牌，可选项。 |
| scope | 表示权限范围，如果与客户端申请的范围一致，此项可省略。 |
(5) 访问令牌过期后，刷新访问令牌
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
| 参数 | 含义 |
|---|---|
| granttype | 表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。 |
| refresh_token | 表示早前收到的更新令牌，必选项。 |
| scope | 表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。 |
三、实践
在示例实践中，我们将创建一个授权访问服务，定义一个MVC客户端，MVC客户端通过IdentityServer上请求访问令牌，并使用它来访问API。
3.1 搭建 Authorization Server 服务
搭建认证授权服务
3.1.1 安装Nuget包
IdentityServer4程序包
3.1.2 配置内容
建立配置内容文件Config.cs
public static class Config
{
public static IEnumerable<IdentityResource> IdentityResources =>
new IdentityResource[]
{
new IdentityResources.OpenId(),
new IdentityResources.Profile(),
};
public static IEnumerable<ApiScope> ApiScopes =>
new ApiScope[]
{
new ApiScope("code_scope1")
};
public static IEnumerable<ApiResource> ApiResources =>
new ApiResource[]
{
new ApiResource("api1","api1")
{
Scopes={ "code_scope1" },
UserClaims={JwtClaimTypes.Role}, //添加Cliam 角色类型
ApiSecrets={new Secret("apipwd".Sha256())}
}
};
public static IEnumerable<Client> Clients =>
new Client[]
{
new Client
{
ClientId = "code_client",
ClientName = "code Auth",
AllowedGrantTypes = GrantTypes.Code,
RedirectUris ={
"http://localhost:5002/signin-oidc", //跳转登录到的客户端的地址
},
// RedirectUris = {"http://localhost:5002/auth.html" }, //跳转登出到的客户端的地址
PostLogoutRedirectUris ={
"http://localhost:5002/signout-callback-oidc",
},
ClientSecrets = { new Secret("511536EF-F270-4058-80CA-1C89C192F69A".Sha256()) },
AllowedScopes = {
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"code_scope1"
},
//允许将token通过浏览器传递
AllowAccessTokensViaBrowser=true,
// 是否需要同意授权 （默认是false）
RequireConsent=true
}
};
}
RedirectUris: 登录成功回调处理的客户端地址，处理回调返回的数据，可以有多个。
PostLogoutRedirectUris：跳转登出到的客户端的地址。这两个都是配置的客户端的地址，且是identityserver4组件里面封装好的地址，作用分别是登录，注销的回调
因为是授权码授权的方式，所以我们通过代码的方式来创建几个测试用户。
新建测试用户文件TestUsers.cs
public class TestUsers
{
public static List<TestUser> Users
{
get
{
var address = new
{
street_address = "One Hacker Way",
locality = "Heidelberg",
postal_code = 69118,
country = "Germany"
};
return new List<TestUser>
{
new TestUser
{
SubjectId = "1",
Username = "i3yuan",
Password = "123456",
Claims =
{
new Claim(JwtClaimTypes.Name, "i3yuan Smith"),
new Claim(JwtClaimTypes.GivenName, "i3yuan"),
new Claim(JwtClaimTypes.FamilyName, "Smith"),
new Claim(JwtClaimTypes.Email, "i3yuan@email.com"),
new Claim(JwtClaimTypes.EmailVerified, "true", ClaimValueTypes.Boolean),
new Claim(JwtClaimTypes.WebSite, "http://i3yuan.top"),
new Claim(JwtClaimTypes.Address, JsonSerializer.Serialize(address), IdentityServerConstants.ClaimValueTypes.Json)
}
}
};
}
}
}
返回一个TestUser的集合。
通过以上添加好配置和测试用户后，我们需要将用户注册到IdentityServer4服务中，接下来继续介绍。
3.1.3 注册服务
在startup.cs中ConfigureServices方法添加如下代码：
public void ConfigureServices(IServiceCollection services)
{
var builder = services.AddIdentityServer()
.AddTestUsers(TestUsers.Users); //添加测试用户
// in-memory, code config
builder.AddInMemoryIdentityResources(Config.IdentityResources);
builder.AddInMemoryApiScopes(Config.ApiScopes);
builder.AddInMemoryApiResources(Config.ApiResources);
builder.AddInMemoryClients(Config.Clients);
// not recommended for production - you need to store your key material somewhere secure
builder.AddDeveloperSigningCredential();
services.ConfigureNonBreakingSameSiteCookies();
}
3.1.4 配置管道
在startup.cs中Configure方法添加如下代码：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseStaticFiles();
app.UseRouting();
app.UseCookiePolicy();
app.UseAuthentication();
app.UseAuthorization();
app.UseIdentityServer();
app.UseEndpoints(endpoints =>
{
endpoints.MapDefaultControllerRoute();
});
}
以上内容是快速搭建简易IdentityServer项目服务的方式。
这搭建 Authorization Server 服务跟上一篇简化模式有何不同之处呢？
- 在Config中配置客户端(client)中定义了一个
AllowedGrantTypes的属性，这个属性决定了Client可以被哪种模式被访问，GrantTypes.Code为授权码模式。所以在本文中我们需要添加一个Client用于支持授权码模式(Authorization Code)。
3.2 搭建API资源
实现对API资源进行保护
3.2.1 快速搭建一个API项目
3.2.2 安装Nuget包
IdentityServer4.AccessTokenValidation 包
3.2.3 注册服务
在startup.cs中ConfigureServices方法添加如下代码：
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews();
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = "http://localhost:5001";
options.RequireHttpsMetadata = false;
options.ApiName = "api1";
options.ApiSecret = "apipwd"; //对应ApiResources中的密钥
});
}
AddAuthentication把Bearer配置成默认模式，将身份认证服务添加到DI中。
AddIdentityServerAuthentication把IdentityServer的access token添加到DI中，供身份认证服务使用。
3.2.4 配置管道
在startup.cs中Configure方法添加如下代码：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapDefaultControllerRoute();
});
}
UseAuthentication将身份验证中间件添加到管道中；
UseAuthorization 将启动授权中间件添加到管道中，以便在每次调用主机时执行身份验证授权功能。
3.2.5 添加API资源接口
[Route("api/[Controller]")]
[ApiController]
public class IdentityController:ControllerBase
{
[HttpGet("getUserClaims")]
[Authorize]
public IActionResult GetUserClaims()
{
return new JsonResult(from c in User.Claims select new { c.Type, c.Value });
}
}
在IdentityController 控制器中添加 [Authorize] , 在进行请求资源的时候，需进行认证授权通过后，才能进行访问。
3.3 搭建MVC 客户端
实现对客户端认证授权访问资源
3.3.1 快速搭建一个MVC项目
3.3.2 安装Nuget包
IdentityServer4.AccessTokenValidation 包
3.3.3 注册服务
要将对 OpenID Connect 身份认证的支持添加到MVC应用程序中。
在startup.cs中ConfigureServices方法添加如下代码：
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews();
services.AddAuthorization();
services.AddAuthentication(options =>
{
options.DefaultScheme = "Cookies";
options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies") //使用Cookie作为验证用户的首选方式
.AddOpenIdConnect("oidc", options =>
{
options.Authority = "http://localhost:5001"; //授权服务器地址
options.RequireHttpsMetadata = false; //暂时不用https
options.ClientId = "code_client";
options.ClientSecret = "511536EF-F270-4058-80CA-1C89C192F69A";
options.ResponseType = "code"; //代表Authorization Code
options.Scope.Add("code_scope1"); //添加授权资源
options.SaveTokens = true; //表示把获取的Token存到Cookie中
options.GetClaimsFromUserInfoEndpoint = true;
});
services.ConfigureNonBreakingSameSiteCookies();
}
AddAuthentication注入添加认证授权，当需要用户登录时，使用cookie来本地登录用户（通过“Cookies”作为DefaultScheme），并将DefaultChallengeScheme设置为“oidc”，使用
AddCookie添加可以处理 cookie 的处理程序。在
AddOpenIdConnect用于配置执行OpenID Connect协议的处理程序和相关参数。Authority表明之前搭建的 IdentityServer 授权服务地址。然后我们通过ClientId、ClientSecret,识别这个客户端。SaveTokens用于保存从IdentityServer获取的token至cookie,ture标识ASP.NETCore将会自动存储身份认证session的access和refresh token。
3.3.4 配置管道
然后要确保认证服务执行对每个请求的验证，加入UseAuthentication和UseAuthorization到Configure中,在startup.cs中Configure方法添加如下代码：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseRouting();
app.UseCookiePolicy();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
}
UseAuthentication将身份验证中间件添加到管道中；
UseAuthorization 将启动授权中间件添加到管道中，以便在每次调用主机时执行身份验证授权功能。
3.3.5 添加授权
在HomeController控制器并添加[Authorize]特性到其中一个方法。在进行请求的时候，需进行认证授权通过后，才能进行访问。
[Authorize]
public IActionResult Privacy()
{
ViewData["Message"] = "Secure page.";
return View();
}
还要修改主视图以显示用户的Claim以及cookie属性。
@using Microsoft.AspNetCore.Authentication
<h2>Claims</h2>
<dl>
@foreach (var claim in User.Claims)
{
<dt>@claim.Type</dt>
<dd>@claim.Value</dd>
}
</dl>
<h2>Properties</h2>
<dl>
@foreach (var prop in (await Context.AuthenticateAsync()).Properties.Items)
{
<dt>@prop.Key</dt>
<dd>@prop.Value</dd>
}
</dl>
访问 Privacy 页面，跳转到认证服务地址，进行账号密码登录，Logout 用于用户的注销操作。
3.3.6 添加资源访问
在HomeController控制器添加对API资源访问的接口方法。在进行请求的时候，访问API受保护资源。
/// <summary>
/// 测试请求API资源(api1)
/// </summary>
/// <returns></returns>
public async Task<IActionResult> getApi()
{
var client = new HttpClient();
var accessToken = await HttpContext.GetTokenAsync(OpenIdConnectParameterNames.AccessToken);
if (string.IsNullOrEmpty(accessToken))
{
return Json(new { msg = "accesstoken 获取失败" });
}
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
var httpResponse = await client.GetAsync("http://localhost:5003/api/identity/GetUserClaims");
var result = await httpResponse.Content.ReadAsStringAsync();
if (!httpResponse.IsSuccessStatusCode)
{
return Json(new { msg = "请求 api1 失败。", error = result });
}
return Json(new
{
msg = "成功",
data = JsonConvert.DeserializeObject(result)
});
}
测试这里通过获取accessToken之后，设置client请求头的认证，访问API资源受保护的地址，获取资源。
3.4 效果
3.4.1 动图
3.4.2 过程
在用户访问MVC程序时候，将用户导向认证服务器，
在客户端向授权服务器Authorization Endpoint进行验证的时候，我们可以发现，向授权服务器发送的请求附带的那些参数就是我们之前说到的数据(clientid,redirect_url,type等)
继续往下看，发现在用户给予授权完成登录之后，可以看到在登录后，授权服务器向重定向URL地址同时带上一个授权码数据带给MVC程序。
随后MVC向授权客户端的Token终结点发送请求，从下图可以看到这次请求包含了client_id，client_secret，code，grant_type和redirect_uri，向授权服务器申请访问令牌token, 并且在响应中可以看到授权服务器核对了授权码和重定向地址URI，确认无误后，向第三方应用发送访问令牌(Access Token)和更新令牌(Refresh token)
完成获取令牌后，访问受保护资源的时候，带上令牌请求访问，可以成功响应获取用户信息资源。
四、总结
- 本篇主要阐述以授权码授权，编写一个MVC客户端，并通过客户端以浏览器的形式请求IdentityServer上请求获取访问令牌，从而访问受保护的API资源。
- 授权码模式解决了简化模式由于token携带在url中，安全性方面不能保证问题，而通过授权码的模式不直接返回token，而是先返回一个授权码，然后再根据这个授权码去请求token，这个请求token这个过程需要放在后台，这种方式也更为安全。适用于有后端的应用。
- 在后续会对这方面进行介绍继续说明，数据库持久化问题，以及如何应用在API资源服务器中和配置在客户端中，会进一步说明。
- 如果有不对的或不理解的地方，希望大家可以多多指正，提出问题，一起讨论,不断学习,共同进步。
- 项目地址
本文来自博客园，作者：可乐加冰-Mr-Wang，转载请注明原文链接：https://www.cnblogs.com/helloworld-wang/p/15208437.html
以上是关于Oauth2系列2：授权码模式的主要内容，如果未能解决你的问题，请参考以下文章