Authentication and Authorization

Why we chose to use OAuth2

Single Sign-On (SSO) is a complicated topic once in the weeds.  Sure, at the high level it is easy at a conceptual level.  A user logs in once and can access all of the associated applications that participate in the SSO system.  It is complicated to implement.

OAuth2 seemed to be the most current adaptation used by various vendors, including Microsoft, Twitter, Google, and Facebook.  It is an open standard that handles authorization and authentication (with OpenID Connect).  It uses JSON for its payloads.  It is less complicated than other protocols.  Being a .NET developer, IdentityServer was a good fit with it being open source (originally on .NET Framework 4.x, now on .NET Core 2.0).

Modifying IdentityServer allowed us to integrate the solution with the desired authentication back-end systems.  We could choose Microsoft ASP.NET Identity Database (already setup really) or a custom user/password system.  This gives us complete control.  There are examples of using with 3rd party authentication systems (e.g. Google).  You can integrate it with Azure Active Directory (AAD), Windows Active Directory (AD), and even home brewed systems.

The down side is that it is still complicated, especially if you aren’t fluent with OAuth2 (which was my case).  There are a lot of examples, but determining which ones were the best to use and ultimately understanding how to implement different types of clients such as CORS with JavaScript, ASP.NET .NET Framework with Webforms and MVC, ASP.NET .NET Core with MVC, and .NET Framework Winforms.  Nuget packages are often needed with various different library versions and the moving nature of software libraries and IdentityServer (.NET Core 2.0 clients and resources don’t because it is all built-in now).

Then there are cookies, back channel communications, front channel communications (and being careful what crosses into that area for security sake), tokens (and how to refresh them if applicable), etc.

Using OAuth2 for SSO made it more complicated than if we wanted to have unified login (each app requires a login but shares the same credentials).  The Windows applications (e.g. Winforms) required interaction with the default browser.

It has taken me over 8 months to get where I am today and I am still learning.  In the end, is it worth it?  Yes it is.  We are using open standards that are well supported (even if it is a jungle out there).  This solution will be used for a long time so we wanted to invest in a solution that will be well supported going forward.  Even if the technology morphs, we have a good base solution that can adjust as needed.  These technologies will also mature and change less.  They cover all sorts of devices and have good browser support.