记录一些这两天学习这个内容的感受。
也不太了解到底是文章的问题，还是一直不能抓到重点，经常被一些没有人碰到的问题阻挡，花费大量的时间。
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定义两种资源
- Identity资源，包含注入Email，OpenId，自定义资源等
- Api资源，定义了API允许的操作
而IdentityServer注册client中，有AllowedScope资源，这里的即包含上面两种资源中的组合。
而对于OAuth仅授权而言，无法确定用户Identity，所以只能申请到API资源。
当通过OpenId认证的用户，可以获得Identity资源。
Ocelot中的ApiName限制，就代表某个请求对应一个API资源的限制，那么请求的token中，至少要包含一个该API资源的Scope才能访问。