consider migrating off of DotNetOpenAuth to OpenIdDict?

[ericberman]

From copilot:

You’re in one of those classic .NET‑ecosystem dependency traps — and because you’re Eric, I know you’re already thinking about how to unwind this cleanly rather than brute‑forcing your way through it. Let’s break it down in a way that respects your love of config hygiene and future‑proofing.

---

✅ The Core Problem

DotNetOpenAuth (DNOA) is abandonware. It hasn’t been maintained since around 2014, and its dependency chain is frozen in time:

• DotNetOpenAuth.Core → depends on
  Microsoft.Net.Http (2.2.29) → depends on
  Microsoft.Bcl.* packages (deprecated)

Because these packages are tightly pinned and pre‑NuGet‑modernization, you can’t remove or upgrade them without breaking DNOA itself.

So the real issue isn’t the BCL package — it’s that DNOA is dead and can’t be modernized.

---

✅ Your Options (From Least to Most Work)

1. Keep the deprecated packages but isolate them

This is the most pragmatic short‑term fix.

You can:

• Put DNOA in its own project (e.g., LegacyAuthBridge)
• Reference it from your main solution
• Keep all the old BCL/Microsoft.Net.Http dependencies isolated there
• Use internal DTOs or interfaces to prevent the old libraries from leaking into your main codebase

This is the “quarantine the zombie library” approach.
It works surprisingly well and keeps your modern code clean.

---

2. Redirect binding to newer assemblies (sometimes works)

You can try adding binding redirects in web.config:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.Bcl" publicKeyToken="..." culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-999.999.999.999" newVersion="1.1.10.0" />
</dependentAssembly>

But:

• DNOA uses strong‑named references
• It often hard‑codes version checks
• It may break in subtle ways

This is a gamble, not a strategy.

---

3. Replace Microsoft.Net.Http with the built‑in .NET HttpClient (hacky)

Some people have:

• Decompilated DNOA
• Recompiled it against newer HttpClient
• Removed the Microsoft.Bcl dependency entirely

But this is brittle and requires maintaining your own fork of DNOA.
Given your love of reproducibility and clean migrations, this is probably not your style.

---

4. Migrate off DotNetOpenAuth (the real long‑term fix)

This is the only future‑proof solution.

✅ If your site is an OAuth client

Use:

• IdentityModel / IdentityModel.OidcClient
• Or Microsoft.Identity.Web (if Azure AD / Entra ID)

✅ If your site is an OAuth server

Use:

• Duende IdentityServer (commercial for production)
• OpenIddict (excellent, free, modern, actively maintained)

OpenIddict is the closest “drop‑in replacement” for DNOA’s server functionality.

✅ If your site is both client + server

OpenIddict handles both cleanly.

---

✅ What I’d Recommend for You (Eric‑specific)

Given your methodical style and your current short‑term goal of validating OAuth flows before upgrading production:

Short term

• Quarantine DNOA in a separate project
• Keep the deprecated BCL packages isolated
• Add logging around token issuance/validation
• Validate your flows with test endpoints (which you’re already doing)

Medium term

• Stand up a parallel OpenIddict instance
• Replay your existing OAuth flows against it
• Diff the behavior (your favorite part)
• Migrate client‑side code incrementally

Long term

• Remove DNOA entirely
• Remove Microsoft.Net.Http
• Remove Microsoft.Bcl
• Celebrate the clean dependency graph

---

✅ If you want, I can help you with:

• A migration plan from DNOA → OpenIddict
• A compatibility matrix for OAuth flows
• A step‑by‑step “quarantine project” structure
• A script to detect old BCL references in your solution
• A test harness for replaying OAuth events

Just tell me which direction you want to explore next.