Edition 0 Updated to asp. Net core 0

Authentication and authorization in Ocelot API Gateways 
In an Ocelot API Gateway, you can sit the authentication service, such as an ASP.NET Core Web API 
service using 
IdentityServer
 providing the auth token, either out or inside the API Gateway. 
Since eShopOnContainers is using multiple API Gateways with boundaries based on BFF and business 
areas, the Identity/Auth service is left out of the API Gateways, as highlighted in yellow in the 
following diagram. 

---

177 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-39. Position of the Identity service in eShopOnContainers 
However, Ocelot also supports sitting the Identity/Auth microservice within the API Gateway 
boundary, as in this other diagram. 
Figure 6-40. Authentication in Ocelot 
As the previous diagram shows, when the Identity microservice is beneath the API gateway (AG): 1) AG 
requests an auth token from identity microservice, 2) The identity microservice returns token to AG, 3-
4) AG requests from microservices using the auth token. Because eShopOnContainers application has 
split the API Gateway into multiple BFF (Backend for Frontend) and business areas API Gateways, 
another option would have been to create an additional API Gateway for cross-cutting concerns. That 
choice would be fair in a more complex microservice based architecture with multiple cross-cutting 
concerns microservices. Since there’s only one cross
-cutting concern in eShopOnContainers, it was 
decided to just handle the security service out 
of the API Gateway realm, for simplicity’s sake.

---

178 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
In any case, if the app is secured at the API Gateway level, the authentication module of the Ocelot 
API Gateway is visited at first when trying to use any secured microservice. That redirects the HTTP 
request to visit the Identity or auth microservice to get the access token so you can visit the protected 
services with the access_token. 
The way you secure with authentication any service at the API Gateway level is by setting the 
AuthenticationProviderKey in its related settings at the configuration.json. 
{
"DownstreamPathTemplate"
:
"/api/{version}/{everything}"
,
"DownstreamScheme"
:
"http"
,
"DownstreamHostAndPorts"
:
[
{
"Host"
:
"basket-api"
,
"Port"
:
80
}
]
,
"UpstreamPathTemplate"
:
"/api/{version}/b/{everything}"
,
"UpstreamHttpMethod"
:
[]
,
"AuthenticationOptions"
:
{
"AuthenticationProviderKey"
:
"IdentityApiKey"
,
"AllowedScopes"
:
[]
}
}
When Ocelot runs, it will look at the ReRoutes AuthenticationOptions.AuthenticationProviderKey and 
check that there is an Authentication Provider registered with the given key. If there isn’t, then Ocelot 
will not start up. If there is, then the ReRoute will use that provider when it executes. 
Because the Ocelot WebHost is configured with the 
authenticationProviderKey = 
"IdentityApiKey"
, that will require authentication whenever that service has any requests without 
any auth token.