ocelot identityserver4 consul整合漫谈

记录一些这两天学习这个内容的感受。

也不太了解到底是文章的问题，还是一直不能抓到重点，经常被一些没有人碰到的问题阻挡，花费大量的时间。

ocelot整合consul

• 注意的是ocelot的GlobalConfiguration是他自己配置文件中的一个节点。需要在这个节点里，指定consul

• 另外consul有一套KV存储功能，ocelot可以利用这个功能读取配置文件。

• consul默认只在loopback端口监听，如果是为了外部查询consul的信息，需要指定client_addr

ocelot整合identityserver4

由于涉及到认证和鉴权，这里的问题遇到的比较多，

jwt 和 bearer token

bearer token是OAuth2.0中的概念，也叫access_token（我目前的理解），利用这个token，相当于被授权，可以请求资源。

而jwt是一种数据格式

两者之间的关系是bearer token可以用jwt这种格式表示，而jwt也是目前bearer token默认的一种表示格式，可以在[jwt网站](jwt.io)解析jwt格式内容。

ocelot的认证

在网上查询资料，发现有的地方，将认证功能放在ocelot后方的具体功能API上，而ocelot官方，是将认证配置在ocelot自己的服务上的。

没有找到有地方描述这两者究竟是什么关系，这点也让我想了很久，以下是我现在整理自己的思路。
如下内容建立在bearer token 机制上。

client方

client端，向ocelot发起请求时，需要携带已经认证通过的，从identityserver中获取的bearer token。

这个过程与ocelot无关，是client与identityserver之间的交互

ocelot部分

ocelot可以配置API认证要求，也就是对应ocelot官网说明。

此时ocelot 会验证传入的请求中,token是否能通过identityserver的验证，也就是说ocelot会向identityserver发起验证。

只有验证1）有效，2）满足ocelot配置的Scope和Audience等限制时，ocelot才会向下游转发，否则会报错

当然，ocelot这里的验证可以完全不配置，而由下游API验证

下游API

下游API也可以配置[Authorize]属性进行验证，同样，时通过向identityserver请求，验证token的合法性和授权情况的

补充

关于Scope/Resource

Identityserver定义两种资源

1. Identity资源，包含注入Email，OpenId，自定义资源等
2. Api资源，定义了API允许的操作

而IdentityServer注册client中，有AllowedScope资源，这里的即包含上面两种资源中的组合。
而对于OAuth仅授权而言，无法确定用户Identity，所以只能申请到API资源。
当通过OpenId认证的用户，可以获得Identity资源。

Ocelot中的ApiName限制，就代表某个请求对应一个API资源的限制，那么请求的token中，至少要包含一个该API资源的Scope才能访问。