IdentityManager is an open source project that offers a modern alternative to the ASP.NET WebSite Administration tool that used to come bundled with Visual Studio. IdentityManager offered a simple user interface that allowed developers to bootstrap a new user store with users and role data and saw considerable popularity despite never being intended for production. IdentityManager was designed for ASP.NET & OWIN, supporting ASP.NET Identity 2 and Membership Reboot, which bring us to the topic of this article.

Introducing IdentityManager2

And that’s not the usual hyped up title...

Passwords suck. People have been moaning about this for years, and it is becoming more and more apparent as we see high profile data and account breaches happen every day and the emerging necessity of services such as Have I Been Pwned and Pwned Passwords.

So, what’s the solution? FIDO2 (Fast Identity Online 2) seems a very strong candidate for a passwordless future or at the very least as a second factor, using public key cryptography to bring easy to use, unphishable credentials to the masses.

In this article, I’m going to talk through the basic ideas and concepts behind FIDO2, and then walk through a basic FIDO2 relying party proof of concept that I have created using ASP.NET Core.

Swagger is a useful tool for creating basic, on the fly API documentation via both a standard JSON format that can then be presented via a UI. These UI’s typically allow you to start making demo requests via the browser. However, once we start protecting our API using OAuth, how do we keep this Swagger documentation functional?

Swagger integration with OAuth authorization servers is relatively well documented, so in this article, we’re going to look at the basics of adding IdentityServer support to an ASP.NET Core API using Swagger and then look at the limitations of this approach and some alternatives that might be worth exploring.

This article will demo both Swashbuckle and NSwag.

A cautionary tale of reinventing the wheel and history repeating itself in the name of blockchain…

Recently, at the European Identity & Cloud Conference (EIC) 2018, I delivered a talk titled ‘Lessons Learned from Integrating with Blockchain Identity Providers”. It’s probably the only time I’m going to give this talk, and it seemed to go down well if only as a cautionary tale, and as an example of past mistakes and failed technologies repeating themselves.

You can find the original slides on SlideShare.

Why Would I Do This?

Back in November/December, this little thing called Bitcoin had a dramatic surge in value, and as a result, there was a rush to put anything and everything “onto the blockchain”. Something about Web 3.0 and ICOs.

This all sounded very exciting to me, and I wanted to get involved. Now, I’m not going to pretend to be an expert on blockchain, but I still wanted to contribute in some way...

OAuth is not authentication. It’s an authorization protocol, or, better yet, a delegation protocol. It’s for this reason that authentication protocols such as OpenID Connect exist and legacy protocols such as SAML use extension grants to link authentication and delegation.

There are articles on this subject already, but I still regularly see some confusion as to the reasons why on the internet and with new clients. So in this article, I’m going to discuss the key reasons why OAuth on its own does not provide client applications (relying parties) with user authentication.