Introducing FakeAuth for .NET Core

TL; DR;

Setting up OAth properly can be a pain and slows things down when you're getting started - you can skip all that (at first) by using services.UseFakeAuth();  Install from Nuget, or grab the code and samples on GitHub.

Why was this created?

With modern .NET CORE applications, you get 4 types of authentication out of the box. Most people are using the wrong one. You should be using “Microsoft identity platform” for most modern, cloud first applications.

Developing with OAuth or OIDC – takes about 30 minutes of set up work just to get going; with FakeAuth, it’s one line of code.

My friend Joe has written extensively on Microsoft Identity Platform, you should go read his posts and subscribe to his channel “Coding with Joe” – he has several episodes devoted to this topic.

What is Microsoft Identity Platform?

The short answer is this: it’s the fastest and easiest way to have your application leverage OAuth and Open ID Connect. For the remainder of this post, I will refer to Microsoft Identity Platform, OAuth, Open ID Connect (OIDC) and single sign-on collectively as OAuth or OIDC, even though OAuth and OIDC are both open standards and, as the name would imply, Microsoft Identity Platform includes a collection of open-source libraries that implement those standards.

This is what allows your application to leverage federated identities and single sign-on, without being tied to a specific organization (as you would be with Windows Auth) and without having to have a separate login for each application (as you would have with Individual Accounts – Forms Auth).

If you work at a company that has a single sign on (often called corporate login) with a separate company or anytime you’ve used a web application that your company didn’t directly host, you were likely leveraging an OAuth login. An example would be if your company uses something like Concur for travel management or expense reporting or if you’ve ever used the

Why don’t people use OIDC when they should?

OAuth is annoying to set up if you're not used to it, and time consuming even if you are.

There are a lot of reasons for this. Oath is still fairly new(‘ish). Some people are just used to Windows Auth. Other people might think, “hey, what’s wrong with Forms Auth anyways!”. Any excuse will work. Mostly though, it’s just sort of a big pain to get started. Let’s say you wanted to try out an idea, create a quick prototype, or just start a POC. If I’m going to use OAuth, there is about 30 minutes of work just to get started; with FakeAuth – it’s one line of code.

 If I'm going to use OAuth, there's about 30 minutes of work just to get started; with FakeAuth - it's one line of code.

Check out Joe’s post on Working with Microsoft Identity – setting up for local development.

To get started building an application (without FakeAuth), there are several things you need first, let’s follow along with Joe:

Have an Identity Provider that you can administer.
There are several free options for this (to get started) including Azure AD, Okta, run Identity Server locally and many more. Of course, if you are in an enterprise that already leverages OAth, you likely don’t have access to administer that instance (tenant) directly. You need to have administration access for step #2
Next you need to register your application with your identity provider
Configure your application to talk to your identity provider.
1. You’ll need the Tenant ID
2. Client ID
3. and Client Secret
4. Plus a few other details, depending on your identity provider
Start assigning roles (Claims) that your application will leverage

At this point you can get started. Yikes! By now you probably aren’t thinking about the idea, app or POC that you were going to build – now you’re fully focused on log in issues that have nothing to do with your application. You just spent the last 30 minutes (at least) getting hello world to run, and now you can’t run your application without an internet connection (so hope you weren’t planning on being productive on your flight). Now that your application is configured – you better not check it in to your source control – or your client secret won’t be so secret anymore.

This brings up another challenge. Let’s say you want to build a demo app for people to download and run, and you want your application to leverage OAuth (of course) but now, anyone that’s going to run your application first needs to repeat all of the steps above. Give me a break.

When to use FakeAuth

There are several obvious scenarios where FakeAuth is incredibly helpful.

Starting development quickly, and you want to lay the OAuth foundation, without the OAuth upfront headaches.
For POCs that might not ever go in to production. You still leverage the OAuth infrastructure, without needing to register yet another application with your org that becomes a ghost town old ideas.
Anytime you want to be able to run your application (locally) without internet access or needing to run a local Identity Server
You are creating a demo app, and you would like a download and run experience.
You don’t have access to your companies Identity provider, but you would still like to have full control over developing with custom claims.

Getting Started

Step 1: Install the FakeAuth package

Step 2: Add UseFakeAuth() to your services set up… and a using FakeAuth in that class.
- For .NET 6, the default is in the Program class file, prior to that, it would be the StartUp class.
- Comment out the boiler plate OAth config that was added for you and add FakeAuth:

    // Azure AD Auth:            
    //services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
    //   .AddAzureAD(options => Configuration.Bind("AzureAd", options));
    services.UseFakeAuth();
    services.AddAuthentication().AddFakeAuth();

Note: For FakeAuth 1.2 +, services.UseFakeAuth(); has been depreciated in favor of services.AddAuthentication().AddFakeAuth(); 

Everything else continues to work the same. This change was made to more syntactically align FakeAuth with other authentication mechanisms and idioms.

Take a look at the Samples on GitHub and the .NET 6 Program.cs example.

Advanced Configuration

Using the default options, UseFakeAuth() will make every call authenticated, with these two claims:

Name: Fake User
Email: fake@fakeuser.com

Note, this is the same as using UseFakeAuth<DefaultProfile> (), you can override this by specifying another profile, out of the box you get two. DefaultProfile or .UseFakeAuth<AzureProfile>(), which will give you these 6 claims:

preferred_username: fake@fakeuser.com
name: Fake User
NameIdentifier: FAKE
aio: fAkezxy (normally a GUID in production)
objectidentifier: FAKE
tenantid: FAKE

You can create any custom profile you would like by implementing the IFakeAuthProfile interface. This can be very handy for quickly swapping between multiple scenarios, like a manager vs non-manager roles.

You can also bypass profiles, and inline specific claims:

  services.UseFakeAuth((options) =>
  services.AddAuthentication.AddFakeAuth((options) =>
    {
      options.Claims.Add(new Claim(ClaimTypes.Name, "Fake User"));
      options.Claims.Add(new Claim(ClaimTypes.Role, "Expense_Approver"));
      options.Claims.Add(new Claim("Approval_Limit", "25.00"));
      options.Claims.Add(new Claim("Approval_Currency", "USD"));
      options.Claims.Add(new Claim("Preffered_Location", "Disney Island"));
    });

Claims are magical secret sauce that makes OAuth amazing

If you’re not familiar with OAuth Claims, they are magic.

Claims can represent anything. In the example above, there are two claims that are represented by commonly used schemas (Name and Role) the next three are custom attributes (Approval_Limit, Approval_Currency and Preffered_Location). You can use FakeAuth to inject whatever claims you want to leverage – this has the effect of ocumenting the claims your app will need within your source control.

Enjoy!

FakeAuth 1.2 is now available! Now with HttpClient extension methods for new testing scenarios!