Using Identity Server 4 with .NET framework
I recently worked on migration project to upgrade a number of 4.6.2 projects to dot net core (actually it ended up being net 5 by the time the project finished).
As part of the migration we wanted to use Identity Server 4 (https://identityserver4.readthedocs.io/en/latest/) #to manage authentication. The application was a suite of web applications and APIs, having a central point to manage the authentication between each of these layers seemed to make sense.
Whilst the examples on the identity server wiki site are great if you are connecting with a dot net core client (https://identityserver4.readthedocs.io/en/latest/quickstarts/1_client_credentials.html) they are rather lacking for .NET framework examples.
The application was still being developed at the same time as the migration project, therefore we needed to try and minimise the rework. We decided to tackle the front-end client as a new dot net core project, and leave the API on full framework.
This meant we needed both .NET framework and dot net core projects to connect to the same identity server and share the tokens between the two.
Connecting the front-end client to the identity server was simple (just follow the package installs and config as described on the wiki site). However setting up the API to use the same endpoint proved to be more difficult (and not well documented).
My first step was to introduce Owin into the API project, I created a “Startup.cs” with the OwinStartup attributes in the “App_Start” folder
I then added the package “IdentityServer3.AccessTokenValidation”
I did have to make a change to the Identity Server to support this package. In the setup of the identity server:
I had to add AccessTokenJwtType to be “JWT” and EmitStaticAudienceClaim to be true
Once this was configured the front end client could connect to Identity server, get a valid token (with the appropriate scope of “api”) and call the .NET framework API.
Ultimately, once we were in a position to migrate the API to net 5 we were able to remove this, but in that interim period where we needed both full framework and core to connect it was a good bridge.