Not so long ago I wrote an article on how we can create our own API gateways using the Ocelot open source library. Since then, I received some questions on how to integrate Ocelot with Identity Server 4 so I thought to share how I managed to achieve this using the Ocelot documentation and some basic Identity Server 4 knowledge. Please note that following these steps I was able to successfully build an API gateway using Ocelot, that used Identity Server 4 JWT tokens to authorize requests and redirect them to the desired downstream path.
To achieve this, the first thing we need is a working Identity Server 4 application. Since this is out of scope for the current article I won’t spend any time on this topic. Please consult the Identity Server 4 documentation and use some code samples to create a working application as soon as possible.
The second thing you need is a working API application. You could use the default ASP.Net Core Web API template in Visual Studio to get starting. For testing purposes the standard ValuesController that you’ll get out of the box would do it.
Last but not least, what we need is a working and configured Ocelot application. If you want to get started fast please refer to the previous article, where you’ll find some instructions on how to configure Ocelot. You can configure a ReRoute in Ocelot for the Values API that I mentioned earlier and test if everything is working as expected.
Once everything is set up, integrating with Identity Server 4 is really easy. I’ve spent personally more time on configuring Ocelot and understanding how it works than on integrating with Identity Server 4. Since Ocelot is a library for ASP.Net Core 2.x applications, adding identity is really similar to how you would do it in all Asp.net Core applications. We just need to add the appropriate service in the ConfigureServices() method on Startup.cs. And it will look similar to this:
public void ConfigureServices(IServiceCollection services)
var authenticationProviderKey = “TestKey”;
var options = o =>
o.Authority = “https://whereyouridentityserverlives.com”;
o.ApiName = “api”;
o.SupportedTokens = SupportedTokens.Both;
o.ApiSecret = “secret”;
The authentication provider key is very important, since you’ll have to provide the key in the ReRoute configuration. Basically you have to add this provider key to each re-route on which you want to authenticate/authorize with Identity Server 4. The re-route configuration would look similar to this code:
“UpstreamHttpMethod”: [ “Get”, “Post” ],
Further o.Authority, o.ApiName, o.ApiSecret are bits of information that you retrieve on your Identity Server 4 project. When you register an API with Identity Server 4 you basically get all these details. So you just have to provide them as authentication options for Identity Server 4.
And that’s basically it! If all components are wired up correctly, if you run all your projects and make a requeust to the API gate way, to the /values URI, Ocelot will authenticate/authorize the request by looking if an AuthenticationProviderKey is specified on the re-rout configuration. If one is present, it will look up the authentication services that matches with the key. If none is found, you will get an “Unauthorized” response. If everything is Ok, you will get the response from the values API.
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
Latest posts by Dan Patrascu-Baba (see all)
- Configuration and environments in ASP.NET Core - 25/11/2019
- GraphQL in the .NET ecosystem - 19/11/2019
- A common use case of delegating handlers in ASP.NET API - 12/11/2019
8 thoughts on “How to integrate Ocelot with Identity Server 4”
How you could access identityserver discovery endpoint through ocelot?
I’m not sure I fully understand your question and the desired scenario. Could you please elaborate a little bit?
What is the difference between the providerkey and secret?
Thank you for your question. The provider key is simply a string that you can define by yourself which helps to identify an authentication provider. This is useful because you could use several such providers: Google, Facebook and so on.
The client secret (I assume you refer to this concept) is a well defined part of the OAuth 2.0 authorization client credentials flow. The client secret is something you receive upon registering an application somewhere (like Azure AD, Auth0). Hence it cannot be defined by you.
In the above example the client secret would be part of the “options” code block.
To clarify, when a request comes in from a client into Ocelot and looks at my re-route configuration, it will use the “authentication configuration” for that downstream route and and match it with the middleware auth keys I have defined? Am I correct?
I have something similar to your setup above but I get; “Unable to retrieve document from: ‘[PII is hidden]'”. Any ideas?
BTW, thanks a bunch for this post. Learned a lot from it.
I see. Any idea why I am getting “Unable to retrieve document from: ‘[PII is hidden]'”?
Check your callback url is correct. The default is …/signin-oidc but this can be configured using the authentication option in Startup.cs
I am new to this and requesting you to please explain “o.ApiName” & “o.ApiSecret”.
Which api we are talking about here… Suppose I have 10 microservices + 1 identity service for authentication and authorisation?