C# 鉴权授权学习总结

木子丶鹏

已于 2023-07-19 12:25:00 修改

阅读量1.2k

点赞数 1

文章标签： c# .net

于 2023-05-10 16:26:40 首次发布

本文链接：https://blog.csdn.net/qq_38192821/article/details/130603920

版权

Session/Cookie

是什么

如果是第一次的HTTP请求，服务端就会自动给当前的HTTP请求分配一个SessionID然后返回给客户端，客户端会把SessionID存储在Cookie里面。
浏览器后面再进行HTTP请求的时候就会基于Cookie默认带上这个SessionID，服务器就会检查当前 SessionID是否有效，如果SessionID有效就会从Session对象中获取当前用户的信息，如果SessionID 失效了，就会重定向到登录页面。

为什么要Session/Cookie

HTTP协议本身不能进行用户识别，所以为了证明张三是张三，才有了Cookie和Session。

JWT

示意图

单点登录

鉴权中心根据账号和密码颁发Token，HTTP请求带着Token就可以访问API，API也认可Token，不需要再去鉴权中心进行校验，第三方的API也认可Token，这种模式就叫做SSO，Single Sign On，单点登录。

如何生成签名

描述

第一步需要调用base64UrlEncode方法把header和payload进行各自的编码，然后中间在加上一个点，最后生成data。
第二步需要调用hmacSha256方法把生成的data和sercret当作方法的参数传进去，生成hashData，如果是非对称可逆加密那么调用的是RsaSha256方法。
第三步需要调用base64UrlEncode方法把生成的hashData进行编码，生成signature。
最后需要组装JWT的格式，就是header.payload.signature。
当HTTP的请求发送到服务端时，先经过AuthorizeFilter过滤器进行鉴权，看看Token是否有效。
如果是RsaSha256，也就是非对称可逆加密，服务端会从Token里面获取公钥，能把Token成功解密，就能证明这个Token是鉴权中心颁发的。
如果是hmacSha256，也就是对称加密，使用的是相同的密钥生成的签名，那么需要根据服务端的secret 进行验签。具体的流程就是从HTTP的请求中获取到Token的header和payload，然后按照生成Token 签名的流程生成最终的signature，最后和Token中的signature进行对比，看看签名是否一致。

代码

JWT的格式是header.payload.signature。
var data = base64UrlEncode(header) + ”.” + base64UrlEncode(payload)。
var hashData = hmacSha256(data, secret)。
var signature = base64UrlEncode(hashData)。

密钥类型

第一种是RsaSha256，也就是非对称可逆加密，服务端会从Token里面获取公钥，能把Token成功解密，就能证明这个Token是鉴权中心颁发的。
第二种是hmacSha256，也就是对称加密，使用的是相同的密钥生成的签名，所以必须要确保密钥不能被泄露。

RefreshToken实现思路

RefreshToken的有效时间一定要比Token的有效时间要长。
RefreshToken可以是GUID，雪花ID，或者是时间戳，只要能保证唯一性就行。
前端每次访问API接口都会在HTTP的请求头中携带Token，如果Token失效了服务端就会返回401状态码。
前端判断如果是401状态码，就从localStorage里面获取RefreshToken，再去请求服务端获取Token的 API接口。
服务端会先检查RefreshToken的合法性。
如果RefreshToken有效，服务端就会返回一个新的Token和RefreshToken给前端。
然后前端就会更新localStorage里面的RefreshToken，同时用这个新的Token向服务端发起第三次请求。
如果RefreshToken无效，服务端还是返回401状态码，前端第二次判断如果还是401状态码，就会跳转到登陆页面。

Token泄露了怎么办

常规方案

可以把Token的过期时间设置的短一点，如果过期了就用RefreshToken去获取新的Token。
可以把生成Token的密钥换的勤一点。
用户退出登录或者关闭浏览器窗口的时候前端要及时调用注销Token的接口。
注销Token的接口就是给当前用户生成一个新的Token不返回，原有的Token自然就失效了。
还可以将HTTP请求的URL，时间戳，Token再进行合并，然后进行加盐签名。
因为盐值是保密的，其它人如果只是得到Token的话，还是无法进行正确的签名。
但是服务端可以验证HTTP请求的签名值来判断当前的HTTP请求是否有效。

IP绑定

还可以在生成Token的时候，在payload中加入当前登录用户的IP地址。
HTTP的请求到达服务端之后，获取payload中的IP地址，判断一下和发送HTTP请求的IP地址是不是同一个IP地址，如果不是同一个IP地址就直接给前端返回401状态码。

特殊场景无解

如果有人获取了Token去访问API接口，但是Token这个时候没有过期，而且HTTP请求的IP地址也没有任何变化，这个时候使用JWT是无解的，没有解决方案，可以考虑使用LDAP协议来进行认证。
我目前对LDAP协议没有进行深入的研究，因为目前做的这些项目安全程度还没有那么高。

OAuth2.0

是什么

OAuth2.0是一种委托协议，它允许应用也就是WPF，WinForm，MVC，也叫受保护资源的消费者，来代表用户访问受保护的资源。

理解

用户通过浏览器访问一个应用，需要登录才能使用更多的功能，点击登录，应用收到登录请求以后，会向授权服务器发送授权码请求。
假设授权服务器就是IdentityServer4，ids4接受到请求以后会响应登录页面给用户，如果用户没有注册过ids4就需要注册账户，如果已经注册了就需要输入账号和密码进行登录，也有可能已经登录过ids4，直接点击登录。
反正只要确认了登录信息，并且授权同意应用取得对应的资源，就会发送到ids4那里，ids4认证没问题以后，就会把授权码发送给应用，应用拿到授权码以后再发送请求给ids4，ids4就会返回访问token，也就是access_token，简单来说就是用授权码交换访问token。
应用使用这个访问token向资源服务器获取对应的资源，资源服务器看到访问token就返回对应的资源，这就是常见的OAuth授权码模式。
用户点击登录的时候，应用会发送访问ids4的请求，这条请求会带有一些参数，因为是授权码模式，因此会有response_type=code这样的键值对，毕竟在请求授权码。
还有一个可选的redirect_uri参数，意思就是用户认证完，浏览器要重定向的地址。换句话说，授权码也会一起返回到浏览器，用户和应用都能看到授权码。
如果不用授权码来换取访问token，而是用授权码直接访问资源服务器的话，那么出现在前端的授权码可能会被其他人发现，导致安全问题。
为了把接下来的处理移交到后端，此时应用的前端需要把授权码发送到应用的后端，这样处于明处的前端就不会暴露访问token。
应用需要提前到授权服务器那里注册，就是要先到ids4的OAuth服务里进行注册，注册的时候就要注明回调的URL，因为ids4会把授权的信息通过这个URL进行发送，也就是redirect_uri参数。
注册成功以后应用会得到对应的client_id和client_secret，client_id会在请求授权码那一步一起发送，这样ids4就知道该处理哪个应用的请求。
在用授权码来交换访问token这一步的时候，应用需要把client_id，client_secret和授权码一起发送到 ids4，这样才能换取到访问token。
当然访问token不会长期有效的，而是要考虑到一些安全，因此可以设置refresh_token来刷新 access_token。
OAuth其实做的是授权，不是认证，用户授权应用去访问对应的资源。
OpenID Connect基于OAuth进行了延伸，在一开始发送请求的时候，还有一个参数scope表示授权的范围，有了这个声明以后，在拿到访问token的时候，会看到多了一个id_token，这个id_token 就是JWT，JWT经过解码以后可以得到用户的信息，比方说用户的标识符和邮箱，这样就更清楚用户是谁。
授权码模式比较适合有前端和后端的场景。
隐式模式比较适合SPA这种单页应用。
客户端凭据模式比较适合服务器对服务器的场景。
资源拥有者密码模式基本上也只在后端使用。

示意图

授权/身份认证

授权(Authorization)表示你能干什么。
身份认证(Authentication)是OpenID Connect，就是看看你是谁。

授权类型

Authorization Code是授权码，代表资源所有者委托给客户端应用的权限。
Implicit Flow是授权码的简化模式，可以直接把AccessToken发送过去。这种模式通常用于”公共”的客户端。最好是客户端应该可以直接从浏览器访问资源。也没有显式的客户端身份认证。
Resource Owner Password Credentials是密码模式。客户端将用户名和密码发送给认证服务器获取令牌。资源所有者的密码凭证，比如用户名和密码会直接被用来请求AccessToken。这种模式通常用于一些遗留的应用。资源所有者和客户端应用之间必须高度信任。其它授权方式不可用的时候才使用这种模式，所以能不用就不用。
Client Credentials是客户端模式。客户端直接从认证服务器获取令牌。客户端应用不代表用户，客户端应用本身就相当于是资源的所有者。这种模式通常用于机器和机器之间的通信。所以这种模式的客户端也需要进行身份认证。而且这种模式没有资源所有者对资源负责，但是客户端还得访问资源。