Microsoft Servers forgetting developers?

I do development using a Hyper-V guest with Server 2016 (and 2012R2).  These Virtual Machines (VMs) are hosted on Windows 10 Professional.  This is a requirement for SharePoint development.  This is desirable for web-based development to work in a similar environment that will host these applications (even if hosted in Azure).  Windows 10 is too far removed.

So when Microsoft released Server 2016 without UWP or Microsoft Store support, that was  bit of a surprise.  That meant no Edge browser support, so we cannot test our applications against their premiere browser.  We cannot develop and test UWP applications.  So we don’t support them.

Microsoft Windows Server 1709 is Server 2016 on Build 1709 but without an GUI.  So that isn’t very useful for running Visual Studio.  That means our developers (myself included) are using Server 2016 Build 1607 because we need a GUI for our development tools.  This means we can’t take advantage of 1709 features available in Windows 10.  This includes OneDrive Files On-Demand.  Why is this feature so OS-specific anyway?  It should be a product feature that we can install anywhere.  This makes no sense.

At the end of the day, Microsoft is making it hard to support OneDrive and Edge browser.  And UWP applications.  Okay, I am better about not supporting UWP applications if Progressive Web Apps (PWA) becomes a first class development platform in Visual Studio.  But think of all of the developers who program in C# and don’t want to learn JavaScript, HTML5, etc.  They are desktop developers, not web developers.

So they have created a set of really inconsistent platforms (read: fractured) and confusion with developers on how best to support various platforms.  Or not support them because it is too hard for us.  Developers help make the platform because the ecosystem cannot survive without them.

I will take a look at moving to Windows 10 Pro VMs as a development platform.  Maybe that is the way to go, with the exception of SharePoint development (unless such can be done with the upcoming SharePoint 2019).  In years past, it was too painful to do DevOps on a desktop OS while support a server OS.  That is why we developed on server OSes.  Time will tell.

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.