1.认证
当客户端通过ocelot访问下游服务的时候，为了保护下游资源服务器会进行认证鉴权，这时候需要在ocelot添加认证服务。添加认证服务后，随后ocelot会基于授权密钥授权每个请求可以访问的资源。用户必须像往常一样在其startup.cs中注册身份验证服务，但是他们为每次注册提供一个方案（身份验证提供者密钥），例如：
在此ocelot认证项目示例中，testkey是已注册此提供程序的方案，然后将其映射到网关项目routes路由中：
ocelot运行时，它将查看routes.authenticationoptions.authenticationproviderkey并检查是否存在使用给定密钥注册的身份验证提供程序。如果不存在，则ocelot将不会启动，如果存在，则routes将在执行时使用该提供程序。如果对路由进行身份验证，ocelot将在执行身份验证中间件时调用与之关联的任何方案。如果请求通过身份验证失败，ocelot将返回http状态代码401。
2.jwt tokens bearer认证
json web token (jwt)，是为了在网络应用环境间传递声明而执行的一种基于json的开放标准（rfc 7519）。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（sso）场景。jwt的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
2.1jwt令牌结构
在紧凑的形式中，json web tokens由dot（.）分隔的三个部分组成，它们是：header头、payload有效载荷、signature签名。因此，jwt通常如下所示：xxxxx.yyyyy.zzzzz（header.payload.signature）。
2.1.1header头
标头通常由两部分组成：令牌的类型，即jwt，以及正在使用的签名算法，例如hmac sha256或rsa。例如：
然后，这个json被编码为base64url，形成jwt的第一部分。
2.1.2payload有效载荷
payload部分也是一个json对象，用来存放实际需要传递的数据。jwt规定了7个官方字段，供选用。
- iss (issuer)：签发人
- exp (expiration time)：过期时间
- sub (subject)：主题
- aud (audience)：受众
- nbf (not before)：生效时间
- iat (issued at)：签发时间
- jti (jwt id)：编号
除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。例如：
注意，jwt默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。这个json对象也要使用base64url算法转成字符串。
2.1.3.signature签名
signature部分是前两部分的签名，防止数据篡改。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用header里面指定的签名算法（默认是hmac sha256），按照下面的公式产生签名：
签名用于验证消息在此过程中未被更改，并且，在使用私钥签名的令牌的情况下，它还可以验证jwt的发件人是否是它所声称的人。把他们三个全部放在一起，输出是三个由点分隔的base64-url字符串，可以在html和http环境中轻松传递，而与基于xml的标准（如saml）相比更加紧凑。下面显示了一个jwt，它具有先前的头和有效负载编码，并使用机密签名：
其实一般发送用户名和密码获取token那是由identity4来完成的，包括验证用户，生成jwttoken。但是项目这里是由system.identitymodel.tokens类库来生成jwttoken。最后返回jwt令牌token给用户。jwttoken解码可以通过https://jwt.io/中进行查看。
3.项目演示
3.1apigateway项目
在该项目中启用身份认证来保护下游api服务，使用jwtbearer认证，将默认的身份验证方案设置为testkey。在appsettings.json文件中配置认证中密钥（secret）跟受众（aud）信息：
startup添加身份认证代码如下：
3.1.1identity server承载jwt token
在第二小节介绍jwt token认证时候，我们都知道一般发送用户名和密码获取token那是由identity4来完成的，包括验证用户，生成jwt token。也就是说identity server承载了jwt token认证功能。为了使用identityserver承载token，请像往常一样在configureservices中使用方案（密钥）注册identityserver服务。如果您不知道如何执行此操作，请查阅identityserver文档。
在identity4中是由authority参数指定oidc服务地址，oidc可以自动发现issuer, issuersigningkey等配置，而o.audience与x.tokenvalidationparameters = new tokenvalidationparameters { validaudience = “api” }是等效的。
3.2authserver项目
此服务主要用于客户端请求受保护的资源服务器时，认证后产生客户端需要的jwt token，生成jwt token关键代码如下：
appsettings.json文件中配置认证中密钥（secret）跟受众（aud）信息：
3.3customerapiservices项目
该项目跟apigateway项目是一样的，为了保护下游api服务，使用jwtbearer认证，将默认的身份验证方案设置为testkey。在appsettings.json文件中配置认证中密钥（secret）跟受众（aud）信息：
startup添加身份认证代码如下：
在customerscontroller下添加一个需要认证方法，一个不需要认证方法：
3.4clientapp项目
该项目是用来模拟客户端访问资源服务器整个认证流程测试项目，在program主程序可以看到如下代码：
运行项目看看测试结果：
结合代码，我们能看到当客户端通过ocelot网关访问下游服务http://localhost:9000/api/customers/get方法时候，因为该方法是需要通过认证才返回处理结果的，所以会进行jwt token认证，如果发现没有token，ocelot则返回http状态代码401拒绝访问。如果我们通过getjwt方法在authserver服务上登录认证获取到授权token，然后再访问该资源服务器接口，立即就会返回处理结果，通过跟而未加认证属性的http://localhost:9000/api/customers/get/{id}方法对比，我们就知道，ocelot认证已经成功了!
4.总结
该章节只是结合demo项目简单介绍在ocelot中如何使用jwt token认证。其实正式环境中，ocelot是应该集成identityserver认证授权的，同样的通过重写ocelot中间件我们还可以把configuration.json的配置信息存储到数据库或者缓存到redis中。
参考文献：
ocelot官网
到此这篇关于asp.net core3.1 ocelot认证的实现的文章就介绍到这了,更多相关asp.net core3.1 ocelot认证内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
