Recently at work I was tasked to build an API gateway. Now an API gateway is a rather simple thing, create a copy of the interface objects, move them to a new name space, grab automapper so you don’t have to write tedious manual mapping code then throw it out on a server.

Overall it wasn’t too bad until I started thinking about security. When looking at all the various schemes and thinking about what was going to be behind this gateway I came up with the thought that an old school API key would be the best way to authenticate users.

I have used them several times in the past. They are quick to implement, reasonably secure over an https connection if they are long and random and use to be a common way to secure endpoints. They were just as good as HTTP Basic authentication if a user could generate them and disable and were somewhat better as compromise didn’t mean your password was then toast as well. But they have fallen out of favor for things like oath or open id or a myriad of other more secure ways to authenticate in the ever evolving world.

Authentication with an API key is relatively simple, quick hit to the database asking if the key exists or not. The hard part is authorization and then validating authorization all over the web service.

That is where my decent into madness with .net core started. I wanted to add an API key to protect the gateway, nothing that would go through it could not be undone or backed out or reversed if it made changes to the system and good request logging means that something fishy should be relatively simple to spot so more complicated authentication schemes would just introduce complexity where none needed to be at this point.

However, coming from ASP.NET running on .net 4.6 to ASP.NET on .net core 2.1 (Long Term Support version of .net core when this was written) meant learning all about a new request pipeline.

Honestly the ASP.NET core request pipeline and configuration is so much nicer than .net 4.6. No more DelegateHandlers or AuthorizationAttributes or FilterAttributes (now some of the names may be the same but they work so much better in .net core) and trying to figure out where or what order things in the pipeline may run. Its all now just middleware that runs in the order it was added to the pipeline when configuring the application. There is also ASP.NET Identity and claims based authorization. This was the first time I had used claims authorization but wow is it nice.

Of course all that is to say, I figured out I wanted to use ASP.NET Identity and set out on the hunt for an API Key Identity provider. Well as I went hunting I didn’t find much and the one I did find I didn’t quite like. So I took a look at the .net source for the Json Web Token identity provider and used that as a base for my own library. It works well and I am currently working on a MySQL based storage provider for it (AWS RDS Aurora) that will handle the identity and claims generation.

Of course writing the library also gave me a lot of insight into some of the deeper parts of ASP.NET core. While I wouldn’t necessarily recommend writing your own library for this, sometimes it is really the only option. And when its the only option, my personal opinion is that you should send it out to the world so hopefully someone else running into the same issues can find your work and save some time.

Always remember, developers are the most productive lazy people on the planet.